CLI vs MCP vs App for Outbound: Which Fits Which Job

TL;DR: Pick the surface by two questions: who is in the loop, and will the job repeat. Use the app when a person is deciding, MCP when a person and an agent are working it out together, and the CLI when the job must run the same way without anyone watching.

#Why this question keeps coming up

FirstSales can be driven in three ways today. You can click through the app, you can run the firstsales command-line tool, and you can connect an agent such as Claude Code over MCP.

Teams new to agent-driven outbound ask the same thing within a week. Which one should we use?

The usual answers are tribal. Engineers say the CLI because they like terminals. Sales leaders say the app because they like screens. Agent enthusiasts say MCP because it is new.

Each answer is right for someone, and wrong as a rule. The better question is what the job needs.

A job that runs every Monday at seven needs something a scheduler can call. A job where a manager picks between two sender mailboxes needs a screen. A job where you want to ask "why did replies dip" needs a conversation with data behind it.

This post gives you a way to sort jobs by those needs. It also keeps you honest about what each surface does not do, so you do not build on a promise the product has not made.

If you want the full terminal workflow once you have chosen, read running outbound from the terminal. If you want the MCP route, start with the FirstSales MCP setup for Claude Code.

#The point of view: choose by who is in the loop

The position of this post is simple. The right surface depends on who is in the loop, and not on which one is most capable.

Capability overlaps heavily. Most things you can do in one surface you can do, or soon will do, in another.

What differs is the interaction pattern. A person in the loop wants to see and choose. An agent and a person together want to ask and refine. A script alone wants to run and report.

Choose the surface that matches the loop, and the rest falls into place. Fight the pattern and you will feel friction every day.

There is a second axis, and it is repetition. A one-off task is cheap to do on any surface, so pick the most comfortable. A task you will run fifty times deserves to be written down once, in the form a machine can repeat.

Put those two together and you get a small matrix. We build it in the next sections.

#The three surfaces in plain terms

Before the matrix, a clear picture of each surface.

#The app

The app is the FirstSales web interface. It is built for people to look at campaigns, read replies, edit sequences and approve things.

Its strengths are visibility and judgment. You see the whole picture, you click through context, and you decide.

Its weakness is repeatability. A task done by clicking is hard to hand to a machine, and hard to audit exactly.

#The CLI

The CLI is a package, @firstsales.io/cli, installed with npm i -g @firstsales.io/cli, with the binary firstsales. Its README calls it a thin, JSON-first layer over the public Developer API.

It prints compact JSON by default, returns stable exit codes, and offers guards like --dry-run, --confirm and --idempotency-key. These features make it good for scripts, scheduled jobs and coding agents that have a shell.

Its weakness is that it does not hold your hand. You get exact output and exact errors, and you decide what to do with them.

#MCP

MCP is the Model Context Protocol, an open standard for connecting agents to tools and data. The specification describes it.

FirstSales runs a product MCP server named firstsales-product, reachable at https://api.app.firstsales.io/mcp over streamable HTTP. A client such as Claude Code connects to it and gets tools it can call during a conversation.

Its strength is conversation. You ask in plain language, the agent calls tools, and you see data and reasoning together.

Its limits are real. The tool list depends on your tenant and your grant, and the live tools/list call is the authority. The released tool set has been read-oriented, with some confirmed writes, and campaign creation through MCP is not confirmed.

For an explainer, see what MCP is for sales.

#How each surface authenticates

The surfaces use different credentials, and that shapes who can use what.

For the CLI, auth resolves in this order: the --api-key flag, then FIRSTSALES_API_KEY, then a saved profile. The README prefers environment variables for automation.

The product MCP does not accept developer API keys or cookies. You sign in through your client, for example with the /mcp command in Claude Code, and approve a grant.

#Why this matters for the choice

A script that runs at night has no person to sign in. It needs a key, so it needs the CLI.

An exploratory chat has a person present. OAuth fits, and the access follows the person.

For key design, read API keys for outbound agents. For MCP permissions, read MCP tool permissions in sales.

#The two questions that decide it

Ask these two questions about any job, in this order.

#Question 1: who is in the loop?

Pick one of three answers.

• A person decides. They look at the situation and choose. Examples are approving a draft, picking a campaign to pause, or deciding a new offer.
• A person and an agent work it out together. The person asks and steers, and the agent fetches and explains. Examples are diagnosing a reply dip or drafting a workflow edit.
• Nobody is watching. A scheduler or a trigger runs it. Examples are a weekly report or a nightly import.

#Question 2: does it repeat?

Pick one.

• Once, or rarely. A one-time cleanup, a setup, an experiment.
• Often, the same way. A routine that should behave identically each time.

#What the answers imply

A person deciding, once, belongs in the app. There is no reason to script a decision.

A person and agent together, once or occasionally, belong on MCP. You get fast exploration with no setup beyond the connection.

Nobody watching, repeating, belongs on the CLI. It is the only surface built to be scheduled and to return exit codes.

The mixed cases are the interesting ones, and we cover them below. A job that starts as exploration on MCP and proves useful should graduate to a CLI script.

#A decision flow

Here is the flow as a diagram. Follow it for any new job.

graph TD
  A[New outbound job] --> B{Will a person watch each run}
  B -->|no, it runs alone| C[CLI with a scoped key]
  B -->|yes| D{Is it a decision with context to see}
  D -->|yes| E[App]
  D -->|no, it is a question or an edit| F{Does it repeat unchanged}
  F -->|yes| G[Prototype on MCP, then move to CLI]
  F -->|no| H[MCP with Claude Code]
  C --> I[Add readiness and test email before any start]
  G --> I
  H --> I

Notice the last box. Every path that could lead to a campaign start passes through the same safety step: run campaigns readiness and campaigns send-test-email before campaigns start. The surface changes, and the rule does not.

#Jobs and the surface that fits them

This section sorts common outbound jobs. Treat it as a starting point, and adjust for your team.

#Reading and reporting

A morning check on what happened is a repeating job, with a person reading the result. The daily outbound standup prompt shows the CLI path and the MCP path for it.

For a weekly record that must be reproducible, use the CLI with cron. See weekly campaign reports with cron and the CLI. The numbers come from a script, and no agent touches them.

For a quick question like "which campaign has the most bounces this week", use MCP. A conversation is faster than building a report you will run once. The post on campaign analytics in Claude covers this.

#Building and editing campaigns

Creating a campaign is a CLI job today. Use firstsales campaigns create. MCP campaign creation is not confirmed, so do not plan around it.

Editing a campaign workflow suits MCP well. The product MCP has campaign workflow get and update tools in the sessions we have confirmed. See editing a campaign workflow with Claude.

For the choices that shape a campaign, such as audience and offer, the app is better. You want to see the whole picture and decide.

#Launching

Starting a campaign is where care matters most. Do it with the CLI or the app, and never from an unattended agent.

The CLI start command needs a JSON body with savedVersionId, readinessVersion, idempotencyKey and confirmation. Preview it with --dry-run first.

The sequence is in start, pause and resume campaigns from the CLI. The readiness step has its own post: the campaign readiness check from the CLI.

#Lead intake

A one-off CSV is a fine app task. A recurring import, or contacts arriving from your own systems, belongs to the CLI.

See import leads from the terminal for batch work. For events that arrive on their own, see start a campaign when a buying signal fires, which uses the CLI behind a small receiver.

#Inbox and replies

Reading replies is a person-and-agent job. An agent can summarize and suggest, and a person approves.

The CLI has inbox threads, inbox thread, approve-draft, reject-draft and reply. Reply text is written by strangers, so keep write power away from any agent that reads it. The reply handling playbook and reply inbox with Claude Code cover safe patterns.

#Suppression and blocked domains

Checking suppression is a CLI job, since it can take up to 100 values per call. Adding a blocked domain is a deliberate act, and it needs an idempotency key on the CLI.

For the MCP side, the product MCP has blocked domain list and add tools in confirmed sessions. See do-not-contact list with MCP.

#Access and billing

Creating and revoking API keys is a CLI job, and a human-led one. Credits and usage can be read in any surface.

The app is the best place to change plans and payment details, since those need a person.

#Where the app wins and always will

It is tempting to treat the app as the thing you graduate from. That is a mistake.

#Judgment with context

When a decision depends on seeing a lot at once, a screen beats text. Looking at a sequence, a thread and a lead's history together is faster in the app.

#Anything involving other people

Inviting teammates, setting roles and approving access are best done where the people are. The app gives them a shared place.

#Rare, high-stakes actions

If you do something twice a year, scripting it is wasted effort. Clicking it, slowly, with the screen in front of you, is the safest approach.

#First-time setup

The first time you connect a mailbox or set up a sending domain, use the app. You learn what the pieces are, which makes every later automation better.

There is a post on sending domains from the CLI for when you add domains in bulk. For the first domain, click.

#Where MCP wins

MCP is the right tool when you do not yet know exactly what you want.

#Exploration

You can ask a question, look at the answer, and ask a better one. There is no script to write and no command to remember.

This suits diagnosis. "Why did replies drop on the Berlin campaign" is a question that unfolds as you read.

#Editing with explanation

When an agent edits a workflow, it can tell you what it changed and why. You review the change in a conversation, which is natural.

#Low setup cost

Connect once with

#What MCP does not give you

MCP sessions are conversational and vary from run to run. Two runs of the same question can differ in wording and in which tools get called.

That is fine for exploring and wrong for a report you must reproduce. It is also a reason not to let a conversational agent hold a start-the-campaign tool unattended.

#Keep the tool list small

Connect only what the session needs. A long tool list hurts accuracy and raises risk, as covered in too many MCP tools.

#Untrusted text still applies

Anything an agent reads over MCP, such as reply bodies, can carry hostile instructions. Read MCP security for outbound before you give an agent both inbox access and any write tool.

#Where the CLI wins

The CLI is the right tool when the job must be exact and repeatable.

#Scheduling

A scheduler can call a command, read its exit code and alert on failure. The CLI returns documented exit codes: 0 ok, 1 runtime, 2 usage, 3 auth, 4 not found and 5 rate limited.

#Reproducibility

The same command with the same inputs does the same thing. That is the property reports, imports and audits need.

#Guards

The CLI has built-in protections. --dry-run previews a request with no auth and no network call. --confirm is required for destructive commands. --idempotency-key makes retried writes safe.

#Narrow credentials

A script gets an API key sized to its job. If it misbehaves, the key limits the damage. See API keys for outbound agents.

#Coding agents with a shell

A coding agent that can run commands can use the CLI directly. The package ships Claude Code skills named firstsales-cli, firstsales-product-mcp and firstsales-developer-api.

The CLI skill gives the agent a short rulebook: verify identity first, read state before mutating, prefer JSON, use dry runs, and stop on unsupported_operation. Those rules make an agent with a shell safer.

#Honest limits

The CLI does not cover everything. Signals and webhooks return unsupported_operation until public API support exists.

The README tells you not to work around that by calling app-private routes. If a capability is missing, use the app or wait.

#The escape hatch

For a public endpoint that has no dedicated command, the CLI has firstsales api GET /api/v1/.... It stays on the public surface and gives you JSON back.

#Where Copilot fits

FirstSales also has Copilot, an assistant inside the product. It is a fourth way in, and it is worth placing on the map.

From the CLI, firstsales copilot ask "<prompt>" runs non-interactively and prints only the reply text on standard output. Progress and approval prompts go to standard error, so it is safe to pipe.

Use Copilot when you want the product's own assistant to answer from live data. Use Claude Code over MCP when you want your own agent, your own instructions and your own other tools in the same session.

The post on Copilot vs Claude Code with MCP compares them in detail.

#A caution on narration

Copilot answers come from live state, so they may not match a saved snapshot. For a report where numbers must match an archive, produce the numbers with the CLI and narrate afterwards.

#Mixing surfaces in one workflow

Real work crosses surfaces. The skill is moving between them without losing safety.

#Pattern 1: explore, then script

Start on MCP to understand a problem. Once you know the question you keep asking, turn it into a CLI script that a scheduler runs.

The standup job often grows this way. A manager asks the same four questions each morning, and eventually the questions become a script.

#Pattern 2: script reads, human decides in the app

A cron job produces the report. A person reads it, then opens the app to act on one finding.

This keeps the repeating part machine-made and the judging part human.

#Pattern 3: CLI creates, MCP edits and watches

Campaigns are created with firstsales campaigns create. After that, MCP can edit the workflow and watch progress in conversation.

This matches the product as it stands. It also keeps the highest-stakes steps, creation and start, on surfaces with guards.

#Pattern 4: receiver fills, human starts

A small receiver on the CLI fills a list from your signals. A person reviews the list in the app and starts the campaign after readiness and a test email.

This is the design in the signal-triggered campaign post.

#Pattern 5: agent proposes, person approves

An agent on MCP drafts an edit and shows the change. The person approves it, and either applies it in the app or lets the agent apply it with a key limited to workflow edits.

#One identity check at the start

Whenever you switch surfaces, confirm who you are acting as. On the CLI, run firstsales whoami --json. On MCP, check the connected account.

A wrong workspace is the quietest way to do the right thing in the wrong place.

#Safety is not the same on all three

Each surface has different safety properties. Knowing them helps you assign the risky steps well.

#The app

The app shows you what you are about to do. Confirmation dialogs, previews and visible state are your guards.

The risk is hurry. A tired person clicks through a prompt.

#The CLI

The CLI has structured guards: dry runs, confirmation flags and idempotency keys. It has the narrowest credentials.

The risk is automation. A script does a wrong thing quickly and repeatedly, so keep scripts read-only unless a write is needed, and keep delete out of routine jobs.

#MCP

MCP has the broadest interaction surface for an agent. The agent chooses tools based on text it reads.

The risk is untrusted input. Simon Willison describes the lethal trifecta: private data, untrusted content and a way to communicate externally. An agent with all three can be steered by a stranger.

Remove one leg. For outbound, the simplest is to deny the agent any send or approve capability while it reads replies.

#Shared rules on every surface

Some rules hold everywhere.

• Run campaigns readiness and campaigns send-test-email before campaigns start.
• Never paste an API key into a prompt. Use api-keys create with the least access needed.
• contacts delete and other delete commands cannot be undone.
• An email sent through an API key waits for Send Approval, so a person remains in the path for email sends.

The last point comes from the CLI documentation on emails send, schedule and draft. It is a useful backstop, but do not rely on it alone.

For more on agent behavior limits, read email agent guardrails.

#Cost, speed and context size

Each surface has different costs, and not only in money.

#Tokens and context

An agent over MCP pulls tool results into its context. Large results fill the context and slow reasoning.

The CLI lets you filter before the agent sees anything. You can pipe output through jq to keep only what you need, and use --output tsv for compact tables. Smaller input means cheaper, steadier runs.

#Speed

For a single question, MCP is the fastest to start: connect, ask, read. For the fiftieth time, the CLI is faster because nothing needs re-explaining.

#Attention

The app costs human attention for each task. That is expensive for repeating work and cheap for judgment.

#Maintenance

A CLI script is code, and code needs maintenance. When the CLI changes, you may need to update your script.

Check the output fields once with --pretty and avoid hard-coding more than needed. The weekly report post shows a field-agnostic diff that survives changes.

#Failure visibility

A CLI job that fails returns a non-zero code, and you can alert on it. An agent conversation that goes wrong may look fine until you read it closely.

For repeating work, prefer the surface that fails loudly.

#Common mistakes

Here are the patterns that cause the most trouble.

#Using MCP for a reproducible report

A report built by asking an agent each week will drift. Wording changes, tool calls change, and nobody can say what was run.

Fix it by moving the numbers to a CLI script and keeping the agent for prose.

#Scripting a decision

Teams automate things that need judgment, like choosing which leads deserve a human touch. The script encodes a guess, and nobody revisits it.

Fix it by keeping the decision in the app, with the script preparing the options.

#Giving one key to every tool

A single broad key shared by scripts and agents makes every leak a full incident. Create a key per job instead.

#Planning on MCP campaign creation

Do not build a workflow that assumes MCP can create campaigns. It is not confirmed. Create with the CLI.

#Trusting a cached tool list

The MCP tool list is per tenant and per grant. Tools can appear or disappear. Check tools/list live when a workflow depends on a tool.

#Skipping the identity check

Running a script against the wrong workspace is easy when you manage several. Run whoami first, every time, and stop on a mismatch.

#Letting an agent start campaigns

An unattended agent should never run campaigns start. The mistake costs sent email, and it is not reversible.

#A worked week

Here is a sample week for a small outbound team, with the surface chosen for each task. The team has three campaigns live.

#Monday

At 07:00, a cron job on the CLI collects snapshots and diffs them against last week. This is repeating work with nobody watching.

At 09:00, the manager reads the diff over coffee. A bounce count rose on one campaign.

She opens Claude Code over MCP and asks which senders and segments account for the rise. This is exploration with a person and an agent.

#Tuesday

The agent suggests the problem is one segment with stale addresses. The manager opens the app, looks at the segment with her own eyes, and decides to pause that part.

She makes the pause herself in the app. A decision with context belongs to a person.

#Wednesday

A developer writes a CLI script that checks suppression on a new list before import. It is a repeating job, so it becomes code with a narrow key.

He tests it with --dry-run and fake addresses first.

#Thursday

The team prepares a new campaign. The developer creates it with firstsales campaigns create, and then the manager uses MCP to edit the workflow and read progress.

Before the start, they run campaigns readiness and campaigns send-test-email, read the test email, preview the start with --dry-run, and then the manager starts it.

#Friday

The daily standup runs from a read-only key, as in the standup prompt post. The team scans it and leaves by noon.

In this week, no surface did a job it was bad at. The app handled judgment, MCP handled questions, and the CLI handled repetition.

#Comparing the surfaces

The table compares the surfaces on the properties that decide most choices.

The n/a cells mean the row is about public API surfaces, which the app does not use.

The last row says MCP is not safe to hand to an unattended agent. It is a statement about the current pattern, where tool access follows conversation text. It does not call MCP unsafe in general.

#How to use the table

Do not pick the column with the most ticks. Pick the column whose ticks match your job.

If your job needs a schedule, reproducibility and a narrow key, the CLI column is the only fit. If your job needs judgment, the app column is.

#Revisit the choice quarterly

The surfaces change. Tools get added to MCP, and commands get added to the CLI. Re-check the table every quarter, and check the live tools/list and firstsales commands --json before you assume a gap remains.

#FAQs

#Should I use the CLI, MCP or the app for outbound?

Choose by who is in the loop and whether the job repeats. Use the app for decisions, MCP for open questions and edits with an agent, and the CLI for repeating work with nobody watching.

#What is the easiest way to start?

Connect Claude Code to the product MCP and ask questions. It has the lowest setup cost, and it teaches you what data exists before you script anything.

#When should I move from MCP to the CLI?

When you ask the same question the same way more than a few times. At that point, write it as a script with a scoped key so it runs on a schedule and fails loudly.

#Can MCP create a campaign?

No, creation through MCP is not confirmed. Create campaigns with firstsales campaigns create, then use MCP to edit and watch them.

#Can the CLI run on a schedule?

Yes. It prints JSON, returns stable exit codes and reads its key from an environment variable, which suits cron and CI. See the weekly report post for a full example.

#What exit codes does the CLI return?

0 ok, 1 runtime error, 2 usage error, 3 auth error, 4 not found and 5 rate limited. Scripts should handle 3 and 5 on purpose.

#How does MCP authenticate?

With OAuth and PKCE through your client. The product MCP does not accept developer API keys or cookies.

#How does the CLI authenticate?

In this order: the --api-key flag, the FIRSTSALES_API_KEY environment variable, then a saved profile. Prefer the environment variable for automation.

#Which surface is safest for an unattended job?

The CLI with a narrow, job-specific key. It has dry runs, confirmation flags and idempotency keys, and the key limits the damage of a mistake.

#Which surface is riskiest for agents?

MCP in a session that reads untrusted text and can also act. Remove the ability to send or approve, so a hostile reply cannot cause an action.

#Do I still need the app?

Yes. Judgment with context, setup, billing and people management are best done there. The app does not go away as you automate.

#What about Signals and webhooks?

The CLI returns unsupported_operation for them until public API support exists. Build your own receiver and use the CLI for contacts and lists.

#How many tools does the MCP server have?

It depends on your tenant and your grant. Use the live tools/list call as the authority, and connect only what a session needs.

#Can I use the CLI inside a coding agent?

Yes. A coding agent with a shell can run firstsales directly, and the package ships Claude Code skills that give it a safe rulebook.

#What does --dry-run do?

It previews the HTTP request, with redacted headers and the body, without auth or network calls. Use it before risky writes.

#Is --confirm enough to protect against deletes?

No. It stops accidents, but an agent can pass it too. Keep delete commands off routine keys and behind a person, since deletes cannot be undone.

#Where does Copilot fit?

Copilot is the product's own assistant. Use firstsales copilot ask for a piped reply, and use Claude Code over MCP when you want your own agent and instructions.

#Can I mix surfaces in one workflow?

Yes, and most real work does. Explore on MCP, repeat on the CLI, and decide in the app, and confirm your identity each time you switch.

#What must I do before starting any campaign?

Run campaigns readiness and campaigns send-test-email, read the test email, and preview the start with --dry-run. This applies on every surface.

#How often should I revisit this choice?

Once a quarter. Surfaces gain tools and commands over time, so check the live tool list and the CLI command registry.

#Conclusion

The three surfaces are not rivals. They are three answers to three loops: a person deciding, a person and an agent exploring, and a script running alone.

Here are the takeaways.

• Ask who is in the loop and whether the job repeats. Those two answers pick the surface for most jobs.
• Use the app for judgment, setup and people. Use MCP for questions and edits. Use the CLI for repeating work with a narrow key.
• Create campaigns with firstsales campaigns create, and then use MCP to edit and watch. Do not plan around MCP creation.
• Treat MCP sessions that read untrusted text as risky. Remove any send or approve power from them.
• On every surface, run campaigns readiness and campaigns send-test-email before campaigns start, and remember that delete commands cannot be undone.
• Never paste an API key into a prompt. Use api-keys create with the least access the job needs.

Take your three most frequent outbound tasks this week and place each one in the matrix. Move the repeating ones to the CLI first.

Then read running outbound from the terminal for the daily workflow, and API keys for outbound agents for the credentials. To try all three surfaces on one platform, start with FirstSales.