MCP or CLI? Which servers to keep, and which to replace with a CLI call

Over the last few months I have quietly removed more MCP servers than I have added. Most of the work they did moved to a plain CLI call, and the agents got faster, cheaper, and easier to audit.

This is not a "MCP is dead" post. The Model Context Protocol solves real problems, and for some of them nothing else comes close. But the MCP vs CLI question deserves a sharper answer than "add every server you can find". The honest framing is a decision rule: which MCP servers earn their place, and which you should replace with a scriptable CLI call. After running both in production, here is where I draw the line.

The hidden cost of MCP: the context tax

The problem with MCP is not the protocol. It is what it does to your context window.

Every time an MCP server is connected, its full tool definitions get injected into the model's context on every single turn. Tool names, descriptions, complete parameter schemas. You pay for that on every message, whether or not you ever call the tool.

The numbers are blunt. A single MCP server can add roughly 770 tokens of standing schema per turn. That sounds small until you scale it: a 93-tool GitHub MCP server consumes around 55,000 tokens at initialization, Jira adds another 17,000, and a typical enterprise stack of five to ten servers burns 100,000 to 200,000 tokens before the user types a single character. In practice MCP can eat 40 to 50 percent of the available context window before the agent does any real work.

A CLI binary costs zero standing tokens. It sits on disk and consumes nothing until you call it. When you do, you pay for one command, not for a permanent schema dump.

This is why I am not alone in this shift. In early 2026 Perplexity's CTO Denis Yarats said publicly that they were moving away from MCP toward plain APIs and CLI tools, citing exactly these two issues: context consumption and clunky auth flows.

Where the CLI wins

For most of what an agent does, a CLI call is simply the better tool.

• Token efficiency. A CLI command averages a couple of hundred tokens. The equivalent MCP operation, with its schema overhead, runs from thousands of tokens per call up to tens of thousands of standing schema across a full server set. One measured agent-search comparison found the MCP path used about 17 times more tokens per call. Spend those tokens on the actual problem instead.
• Determinism. A CLI call is the same every time. Same input, same flags, same output. You can pin it, version it, and diff it. That is the foundation of a system you can trust.
• Auditability. A command is a line you can log. I can show you exactly what ran, with which arguments, and when. For governance that is gold.
• A smaller attack surface. Fewer always-on connections, fewer tool definitions sitting in context for a prompt injection to hijack.

This is the core of how I run my own orchestration. It is CLI-driven by design, open source on GitHub, and it never depended on OAuth. That choice is also why it survived the OAuth ban that broke other tools. I wrote that story up in the best OpenClaw alternative after the OAuth ban and in how to orchestrate Claude Code without OAuth.

Where MCP still earns its place

Now the fair half. There are jobs where a CLI call is the wrong answer, and MCP is exactly right.

• The service has no CLI. If a vendor only ships an API and you do not want to hand-roll a client, an MCP server is the clean wrapper.
• OAuth and dynamic, multi-user auth. If you need per-user tokens, refresh flows, and scopes across many users, MCP gives you that without building it yourself.
• Stateful, multi-step sessions. When a workflow holds a connection open and carries state across steps, the protocol earns its overhead.
• Built-in schemas, RBAC, and audit logs. For a multi-tenant enterprise tool, the standardization MCP provides is worth the tokens.

The pattern is clear. MCP wins when you need auth you do not want to build, state you cannot easily script, or an integration that has no command line of its own.

The decision table

Strip away the debate and it comes down to matching the task to the tool. This is the table I actually use.

The rough split I land on in practice: CLI for the roughly 80 percent of tasks built on tools the model already knows, and MCP for the 20 percent where you genuinely need auth, state, or a missing command line.

The token gap closes if you build the server right

One honest caveat. The token tax is not a law of nature, it is a default. A well-built MCP server that uses code execution and on-demand tool discovery, instead of dumping every schema upfront, can match a CLI on token efficiency while keeping the auth, the audit trail, and the multi-tenant support a raw CLI cannot give you.

So the rule is not "always CLI". It is "do not pay the context tax for nothing". If a server gives you auth and state you would otherwise have to build, it earns its tokens. If it is wrapping a tool that already has a perfectly good command line, it does not.

The security angle you should not skip

There is a reason I weigh the attack surface, not just the token count. MCP's always-on tool definitions are a target. Security researchers have documented prompt injection through tool descriptions, lookalike tools that silently replace trusted ones, and tool combinations that can exfiltrate files. Adding more tokens to context does not just cost money, it dilutes your instructions and widens the surface an attacker can manipulate.

A CLI call does not remove that risk, but it shrinks it. Fewer standing definitions, deterministic commands, and a log of exactly what ran. I went deeper on this in why I don't install most MCP servers.

What I would do

Audit what you have connected right now. For each MCP server, ask one question: does this give me auth or state I cannot easily script? If yes, keep it. If it is wrapping a tool with a real CLI, replace it and reclaim the context.

Then measure. Look at how many tokens are spent before the agent does anything useful. That number is your context tax, and most teams are paying far more of it than they realize.

The architecture beats the protocol, the same lesson I drew in architecture beats models. Match the task to the tool, keep the line auditable, and stop loading schemas you never call. This is how I design AI systems for production, and the orchestration behind it is open source if you want to see how: github.com/Vinix24/vnx-orchestration.