MCP vs CLI: what an agent should use to act

When an agent stops only answering and starts acting inside your product, the question is no longer "do we use MCP?" It becomes which surface will touch the system: a bounded command in a controlled environment, or a catalog of tools the runtime discovers and calls by contract. APIs still sit underneath; they are usually what the CLI wraps or what the MCP server exposes. This article compares MCP and CLI, not a slide with three acronyms.

In demos everything looks like an API: the model calls an endpoint, returns JSON, and the committee applauds. In production, the cost of stuffing the full schema into every turn, the noise it adds to context, and the difficulty of auditing "which verb ran" push teams toward other ways to expose the same action. A well-designed CLI compresses the action into few tokens and returns structured output. MCP standardizes how an agent client discovers those actions without every integration becoming a custom project. Both coexist; the mistake is choosing by hype instead of by contract, permissions, and where the code runs.

This article does not repeat the layer map or replace identity and permissions. It assumes you already know a tool needs a name, narrow arguments, and limits. Here we teach you to read two different wrappers for that same tool.

The question is not the protocol, it is the surface

For years integration meant "document your REST and the agent will improvise." That works in a pilot with three endpoints. With twenty resources, versions, and tenants (a customer account in your SaaS), the model starts picking the wrong verb, filling fields that did not apply, and burning context on OpenAPI nobody read end to end. The API is not bad: the agent does not need your full map to perform one concrete action.

The surface is how the runtime invokes that action. It can be a narrow POST, a binary with flags, or a server that publishes a tool catalog. Underneath, all three usually call the same product API. The decision is not "do we drop the API?" but "how do we wrap it so an agent can use it without burning context or losing auditability?"

Anthropic argues for treating the agent-tool interface with the same rigor as a human UI: clear names, arguments that do not invite mistakes, predictable output. Many teams express that rigor as small commands, not schema dumps on every turn. Others use a common protocol so Cursor, Claude Desktop, and your harness read the same catalog without rewriting connectors. That is why we scope this article to MCP versus CLI.

What a CLI is when the actor is an agent

CLI (command-line interface) is not terminal nostalgia. For an agent it is a compressed contract: one line that states what can happen, on which resource, and in what response shape.

Imagine support with a copilot that searches tickets. Instead of handing it a hundred REST routes, you register an allowlisted command:

support search --tenant acme --q "duplicate invoice" --limit 5 --format json

That line fixes the tenant, bounds the search, caps rows, and forces JSON. The agent does not browse a menu of endpoints: it runs a verb you defined. If the command always returns the same schema, the model does not interpret HTML or generic error pages, and later you can reconstruct the run from command, arguments, and exit code.

CLI wins when the action is bounded, repeatable, and should cost few tokens per call. It fits pipelines, flags, and limits (--dry-run, --max-rows) in a sandbox: no open network, with timeout and an allowlist of binaries. It is the "code interpreter" pattern done right, because the model is not running whatever it wants, but a runtime that can only invoke commands you registered. It also fits operations you already had as scripts (migrations, exports, heavy reports): the agent triggers the script and the script calls your API with service credentials, not the other way around.

The risk is on the other side. A CLI without a sandbox is a shell with credentials. If the agent can run rm, read /etc, or call arbitrary curl, you do not have integration: you have excessive agency with no guardrails. CLI teaches well when the enclosure exists before the command.

What MCP is and what problem it solves

MCP (Model Context Protocol) is the contract between an agent client and a tool server. The server publishes which tools exist, with description and input schema; the client lists them without rewriting the connector for every IDE or runtime. The MCP specification does not replace your product API: it is the agent-oriented plug when that catalog must be portable across many clients.

Picture a SaaS that sells "connect your systems to agents." Every week a new CRM, drive, or ticketing system appears. Without a common contract, each runtime (the developer IDE, the embedded copilot, the eval harness) asks for its own connector. MCP reduces that friction: one server per external system, many agent clients reading the same catalog. Devic uses MCP as an integration layer for that reason; the use case and domain tools remain yours.

MCP wins when you need dynamic discovery and a standard contract between many clients and many servers, not when you need a single product verb. If the catalog changes (new connector, new version), the client can list again without redeploying the whole prompt. If the agent runs on the user's laptop, it can talk to an MCP server in your infra without you passing the tenant API key in the prompt: the server applies permissions and scopes server-side and the client only sees allowed tools.

MCP does not win when your SaaS's critical action is already a stable endpoint and you want absolute determinism (same input, same effect, no middle layer). A narrow HTTP tool or internal CLI is often enough. MCP also does not fix poorly defined tools: if the schema is vague, you only standardized the confusion.

How to read the choice without dogma

There is no universal winner. Production teams combine surfaces when they can name three things: what action the agent takes, where the code runs, and who audits the effect.

The same choice on two axes: where the runtime runs and whether the domain is your product or an external catalog.

The first table answers "what situation are we in?" The second adds where the runtime runs, because the same product verb can go through the server (centralized permissions) or through a sandbox (bounded execution with measurable output). If a cell feels wrong, it usually means a piece of the map is missing (sandbox, agent identity, or an owner for the tool contract), not that you need "more protocol."

Three questions before you commit to a surface:

1. Does the action already exist as a stable product verb? If yes, wrap it; you do not need a portable catalog for a single flow. 2. How many agent clients will consume the same integration? One: CLI or HTTP is often enough. Several distinct runtimes: MCP starts to pay off. 3. Where do credentials live? If the agent runs on the user's laptop, credentials do not go in the prompt; they live on an MCP server or in a sandbox that calls your API with its own identity.

Putting forty MCP tools with long descriptions in every turn has a context cost. A CLI with subcommands documented in that flow's system prompt, or discovered in a single help, is often cheaper when the use case is one. That is not "anti-MCP": it is not paying for dynamic discovery where you do not need it.

A mature SaaS does not pick one: it stacks responsibilities

What you see in a mature SaaS is not "MCP only" or "CLI only." It is a stack with clear responsibilities, because different actions carry different risk and different context cost.

Your API remains the source of truth for product effects. On top of it you mount narrow verbs: endpoints or commands an agent can call without inventing SQL or routes. Third-party integrations go as MCP servers (or equivalent connectors) with credentials on the server, not in the prompt. If the agent needs heavy logic or data transforms, that runs in a sandbox with registered CLIs; the model does not write free Python toward production.

A generic example: support wants the copilot to search articles, propose a reply, and only after approval update the ticket. Search can be an MCP server to the knowledge base or a kb search CLI in a sandbox, because reading is not the same risk as writing. Updating the ticket is a narrow HTTP tool with tickets:write scope and human confirmation, because the product effect must stay bounded by identity and tenant. The same agent uses two surfaces not from indecision, but because two tasks need different controls.

Before adding a third protocol, ask whether the action already exists as a stable verb. If it is an external catalog, MCP. If it is bounded execution with measurable output, CLI in an enclosure. If it is a critical effect in your domain with idempotency already solved, a narrow HTTP tool on your API still makes sense.

Permissions and audit: the protocol does not change the rules

MCP and CLI change how you call; they do not change who can do what. If the agent acts on customer data, treat it as a service with its own identity, scopes, and default-deny, just as if it called your API by hand.

With CLI, the log should record command, arguments (no secrets), agent identity, tenant, and exit code. With MCP, tool name, validated input, server that responded, and correlation with a run_id. In both cases you need the same minimum as in traceability: rebuild the chain without opening the chat.

An MCP server with broad scopes is an API key in disguise. A CLI on the user's laptop with the admin session is impersonation. The protocol does not fix that: agent identity, allowlist, and revocation without kicking out the human do.

What no interface fixes on its own

If you only have three internal actions and one agent client, an MCP server may be extra layer. Start with HTTP tools or CLIs documented in the flow; add MCP when the catalog or clients justify the standard. A CLI without a sandbox does not scale to multi-tenant production: fine for a local spike, not for a copilot that touches customer data.

Neither replaces the domain contract. "Search tickets for the current tenant, max 5, no raw HTML" is the same requirement wrapped in MCP, CLI, or POST. If the contract is vague, the protocol only organizes the chaos. MCP and CLI are wrappers for agents, not a substitute for product design.

If the team can answer which surface each pilot action uses, with which identity and what lands in the log, the MCP versus CLI choice stops being theological. If it cannot, the problem is not the protocol: you are still in demo mode. We covered that jump in a demo is not a production agent.