CLI vs MCP

"Should I use a CLI agent or MCP?" is the wrong question, and it is asked constantly. One is a program that runs in your terminal. The other is a protocol for connecting a program to things outside it. They are not alternatives, and every major CLI agent is itself an MCP client.

What MCP actually is

MCP is a wire protocol: an agreed format for how an AI application asks an external system for data or actions. It is not software you run and not a product. The useful analogy is USB-C, a shared connector so every device does not need its own plug.

Three roles. The host is the app you use. The client is the connector inside it, one per server. The server is a small program exposing tools, resources and prompts.

The word server misleads people. In practice it is almost always a Node or Python package launched as a local subprocess on your own machine. Anthropic's quickstart example is literally npx -y @playwright/mcp@latest. There is no server room. Server is a protocol role.

In December 2025 Anthropic donated MCP to the Linux Foundation, anchoring the new Agentic AI Foundation alongside Block's goose and OpenAI's AGENTS.md, with AWS, Bloomberg, Cloudflare, Google and Microsoft among the founding members. At donation it reported more than 10,000 active public servers and 97 million monthly SDK downloads. Independent trackers count fewer, so treat any specific server count as disputed.

What a CLI agent is

A program that runs in your terminal and works in a loop: read the request, decide on an action, run a command or read a file, look at the result, decide again. Its native tools are the shell and the filesystem.

That is the part worth internalising if you run a production operation: a CLI agent already has the whole computer. ffmpeg, exiftool, rsync, Python, every command-line tool you have installed. No integration work required, because the model already knows their syntax.

How they compose

This is provable from the vendor documentation rather than argued. Claude Code, Codex CLI, Kiro CLI, Copilot CLI, goose, OpenCode and Qwen Code are all MCP clients. Adding a server is one shell command. The relationship is containment:

• The CLI agent is the host, with native shell and filesystem tools.
• MCP clients inside it reach out to MCP servers.
• Those servers are how it touches anything that is not on your machine.

MCP does not replace the CLI, and the CLI does not replace MCP. The decision is made per integration, not once for the whole system.

Which to reach for

The rule that holds up: use the shell when the tool is local, a mature command-line tool already exists and authentication is already handled. Use an MCP server when there is no useful CLI, when auth is OAuth per user, or when the operation is stateful across services.

Applied to production work:

• Rename 400 clips from embedded metadata. CLI agent. Local files, exiftool exists, no auth. MCP would add a layer for nothing.
• Transcode a delivery folder to three ratios. CLI agent. ffmpeg is already installed and the model knows it.
• Sort two terabytes of rushes into a date and camera tree. CLI agent. Pure filesystem work.
• Pull this week's shot list from Notion or Linear. MCP server. OAuth per user, structured records, no useful CLI.
• Read a Figma file's components. MCP server. Figma publishes one and uses it internally.
• The whole pipeline at once, pulling a brief from a tracker, rendering variants locally, pushing a status back. Both, in one session. That is the composition point made concrete.

What MCP costs you

Context, before any work happens. Anthropic's own engineering team put it plainly: most clients load all tool definitions upfront into context, so agents process hundreds of thousands of tokens before reading your request. Their code-execution approach cut one worked example from 150,000 tokens to 2,000.

The context bill, in one example

Tokens processed in one worked example, before and with Anthropic's code-execution approach

The context bill, in one example

Case	Tokens
Before	150,000
With code execution	2,000

Their own documentation tells users to remove servers they are not using, because each one consumes context in every session. The mitigation they shipped, a tool-search step that discovers tools on demand, reports an 85% token reduction. The size of the fix tells you the size of the problem.

So a dozen MCP servers connected out of enthusiasm is not free. It is a standing tax on every request you make.

The security part, which is the part to actually read

Tool poisoning was named and demonstrated in April 2025: malicious instructions hidden in a tool's description, text the model reads and you never see. In the published demonstration a poisoned tool leaked a config file and SSH keys, and a shadowing attack silently redirected email sent through a different, trusted server.

The peer-reviewed benchmark that followed tested 45 live MCP servers and 353 real tools against 20 models. Attack success reached 72.8% against the most susceptible model, and the most resistant model refused less than 3% of the time.

Tool poisoning, measured

MCPTox: 45 live MCP servers, 353 real tools, 20 models

72.8%

attack success against the most susceptible model

<3%

how often the most resistant model refused

The story that needs no technical background: in September 2025 a package called postmark-mcp appeared on npm, an unofficial clone of a mailer. Version 1.0.16 added one line that blind-copied every email sent through it to a stranger's address. It had been downloaded 1,643 times before anyone noticed.

Named vulnerabilities followed the same shape. CurXecute let a prompt injection arriving through a connected server rewrite an editor's global config, and the editor executed the injected commands with no approval prompt. A 2026 Amazon Q flaw auto-loaded an MCP config from any workspace you opened, spawning processes that inherited your cloud credentials.

The NSA published MCP security guidance in May 2026 with the principle worth writing on the wall: outputs from tools and models should never be treated as implicitly trusted.

The conflation worth correcting

The largest agent security incident of 2026 was not an MCP incident, and it is routinely filed as one.

The Miasma worm compromised 73 Microsoft repositories and 57 npm packages by planting auto-execution hooks in AI coding agent config files. Clone the repo, open it in an agent, and a session-start hook ran a dropper. No MCP involved. That is a CLI-agent-autonomy failure, and the mitigation is different: never open an untrusted repository in an agent, and do not click past the trust prompt.

Practical position

• Default to the shell for anything local. It is cheaper, faster and the model already knows the tools.
• Add an MCP server when there is genuinely no command-line path, and remove it when the job is done.
• Treat every MCP server as software installed with your full privileges, because that is what it is.
• Never open a repository or folder you do not trust inside a CLI agent.
• Keep credentials out of the agent's ambient environment. The worst 2026 vulnerabilities were severe precisely because spawned processes inherited everything.