MCP vs CLI: Two Ways to Give AI Access to Your Systems
Build MCP when the connection has to outlive the agent. Give the agent a shell when the agent is the connection.
MCP and CLI are two ways to give an AI agent access to your systems. MCP is a structured protocol: typed tools, governed access, a list any compatible client can look up. CLI is shell access, bash plus the same commands a developer already uses. MCP scales across teams. CLI is cheaper in tokens. Most deployments use both.
The choice that gets skipped
Every AI implementation eventually hits the same fork: how does the model actually touch the systems it needs to work with.
Most write-ups jump straight to MCP, because the protocol is new and the marketing is louder. The other route, giving the agent a shell and the same command-line tools your engineers already use, is older, has no campaign behind it, and is frequently better. Anthropic itself shipped Claude Code on that principle. The built-in tool catalog is Read, Write, Edit, Bash, Glob, Grep, plus a handful of others (Anthropic engineering, "Building agents with the Claude Agent SDK"). No MCP required to ship.
If you only know one option, you will over-engineer or under-govern. Pick per integration instead.
What MCP actually is
MCP (Model Context Protocol) is a typed layer between an agent and a system. The system's operations become named tools with defined inputs and outputs.
You build an MCP server once for your CRM or your document store, register it with any MCP-compatible client (Claude, ChatGPT, Gemini, Cursor, VS Code), and the agent gets a discoverable list of operations. Each tool has a schema. The protocol handles auth, transport and discovery, so the model does not have to.
We wrote the primer earlier, in our article on what MCP is. For this comparison, what matters is the shape. MCP is the route you take when an integration needs to be governed, reused across teams, or exposed to clients that know nothing about your environment.
What "give the AI a CLI" means
CLI access means the agent runs shell commands directly: bash, curl, grep, git, gh, psql, the same vocabulary a developer uses on a laptop.
There is no schema. The agent reads man pages, runs --help, makes a call, parses the output. If a tool does not exist, the agent installs it. If a workflow needs three tools chained together, the agent pipes them. Anthropic's framing in the Claude Agent SDK post: "Claude needs the same tools that programmers use every day." The filesystem itself becomes context. Logs get inspected with grep and tail instead of dumped into the model.
This is closer to how people work than to how APIs were designed. That is the whole pitch.
Where MCP wins
MCP wins when the integration crosses team boundaries, needs governance, or has to survive an agent rewriting itself.
Three concrete cases. Distribution: an MCP server installed once gets used by everyone on the team, from every supported client, with no per-developer setup (systemprompt.io's Claude Code guidance). Stateful operations: database connection pools, OAuth sessions with refresh tokens, WebSocket subscriptions. Shell calls are stateless by default. MCP can hold a session open. Security: typed inputs and outputs make permission scoping legible. You can say "this agent gets read on these three tools and write on none", then audit it later.
Bloomberg, Block and Amazon went MCP-first internally for exactly these reasons. Block alone built 60 internal MCP servers (per Anthropic's own write-ups). When the same data has to reach many agents across many teams, MCP is the cheaper route in year two, even if it is the slower one in week one.
Where CLI wins
CLI wins when the tool already exists, the agent has a shell, and you need no governance beyond what the shell already enforces.
Token cost is the headline. In a side-by-side test by developer Mario Zechner in August 2025, the GitHub CLI consumed dramatically less context than the GitHub MCP server for the same task. Practitioner Armin Ronacher ran the same comparison and reached the same conclusion. gh got to the answer faster, used less context, and was easier to debug than the MCP equivalent. His follow-up post argued that an MCP exposing thirty tools should usually be one tool that runs code.
Anthropic published a version of that argument in November 2025. The post "Code execution with MCP" describes a workflow that consumed roughly 150,000 tokens when the tools were called directly, then dropped to about 2,000 tokens once the agent was given a filesystem and asked to write the code that called the same MCP servers. A 98.7% reduction (Anthropic, November 4, 2025).
- tokens when the agent called the tools directly150,000
- tokens for the same workflow written as code2,000
- less context for the same result98.7%
The lesson is not that MCP was wrong. The lesson is that pushing work down into code, often shell code, usually beats round-tripping every intermediate result through the model.
CLI also wins the short one-shots: curl an endpoint, grep a log, run a git operation, read a file. Building an MCP server for any of those is overhead a five-person team should never pay.
The trade-off in one sentence
MCP is what you build when you want the integration to outlive the agent. CLI is what you reach for when the agent is the integration.
That is the line we use at Ellypsis when a client asks. If the same connection has to be available to a sales agent today, a support agent next quarter and a procurement agent next year, build MCP. If a single agent needs to talk to one system in one workflow, and the system already has a working command-line tool, give it the shell.
A second test works well too. If the engineer building the integration cannot describe in one sentence what governance is enforced, MCP is the safer route even if it is slower.
What this looks like in an SME implementation
In a Danish company with 50 to 200 employees, the practical answer is rarely pure MCP or pure CLI. It is usually both, with a clear split.
Agents that only work internally run in a scoped environment, and the tools they need mostly exist already as command-line tools: git, psql, curl, vendor tools, the company's own scripts. We give the agent a shell, scope the directory, and let it work. Time to first useful output is hours.
Cross-team or vendor-exposed integrations go through MCP. The CRM. The ERP. The document store. These are the systems where seven different agents will eventually want access, where audit logs matter, and where a typed layer is worth the build cost. We build the MCP server once, register it in every relevant client, and treat it as infrastructure meant to last.
One thing is worth saying out loud: the question is rarely "MCP or CLI" in the abstract. It is which integrations earn the MCP investment, and which are fine as a shell call. Most implementations get that wrong by defaulting to one extreme.
If you want the foundation first: our article on what MCP is
Is MCP replacing CLIs for AI agents?
No. MCP and CLIs solve overlapping but different problems. MCP gives typed, governed, cross-client access to systems. CLIs give an agent immediate, composable shell access using tools that already exist. Anthropic's own Claude Code ships with bash and a small built-in toolkit alongside MCP support. Most production deployments use both.
When should a small company build an MCP server instead of using a CLI?
Build MCP when the same integration will serve multiple agents, multiple teams, or AI clients outside your environment, and when governance matters: typed permissions, audit logs, OAuth. Use CLI when one agent needs a connection to a system that already has a working command-line tool. For most first deployments, CLI is faster to value.
Why does Anthropic publish posts that seem to argue against MCP?
Anthropic's November 2025 post 'Code execution with MCP' is not against MCP. It argues that loading every tool definition into context and routing every result through the model is wasteful. In their example, a workflow dropped from 150,000 tokens to 2,000 when the agent wrote code that called the MCP servers instead.
Is giving an AI shell access dangerous?
Shell access carries risk and demands scoping. The agent can run anything the shell can run. Good practice: sandbox the agent in a container, a VM or an isolated workspace, grant least-privilege filesystem access, require approval for destructive commands, and log every command. Claude Code works this way by default. MCP moves some of that into typed permissions, but the discipline is identical.
Does MCP always use more tokens than CLI?
Often, but not always, and the gap is closing. A multi-server MCP setup loads tool definitions upfront and pays a context cost before the agent starts. CLIs avoid that upfront cost. Anthropic's Tool Search, released in beta in November 2025, loads tool definitions on demand and cuts that cost substantially. Compare per workflow, not per protocol.