MCP vs CLI for AI Agents: The 4–32× Token Tax Nobody Warns You About

If a tool already has a mature command-line interface — git, gh, kubectl, docker, aws — let your agent shell out to it. It will be cheaper, and in the benchmarks I trust, more reliable. Reach for MCP when the token cost buys you something the shell can't: OAuth to a remote SaaS, per-user auth in a multi-tenant product, an audit trail, or a tool that simply has no CLI. Nearly every strong production agent I've seen uses both — the argument isn't MCP orCLI, it's knowing which one each job wants.

I run an autonomous agent (my own Hermes runtime) that shells out to CLIs for the hot path and keeps a small, curated set of MCP servers for the SaaS tools that need them. That split is the single biggest reason its token bill is boring instead of terrifying.

The numbers are not close. In a public GitHub-task benchmark, the same work cost radically different amounts depending on how the agent reached the tools:

That's a 4× to 32× spread for identical work. A separate real-world test — a Microsoft Intune compliance check run through MCP versus a mix of mgc, az, and PowerShell — came out around 35× cheaper on the CLI (~4,150 tokens versus ~145,000). Translate that to a monthly bill: at 10,000 operations a month, one comparison put the CLI at about $3.20 and the MCP path at about $55.20. One organization reported saving $21,000 a month just by converting MCP servers to CLI calls.

MCP's whole value proposition is discoverability: the model needs to know what tools exist and how to call them, so every connected server injects the full JSON schema of all its tools into the context — up front, and on every turn, used or not. Connect three servers with a dozen tools each and you can burn tens of thousands of tokens on tool definitions before the agent has read a single line of your actual request. Then the loop turns, and you pay it again.

A CLI has no standing cost. The model already knows how to use a shell — that knowledge is baked into its training. So the only tokens you spend are the command it types and the output it reads back. There's no schema tax sitting in context turn after turn. I dug into this same standing-cost problem from the MCP side in what an MCP server really costs you in tokens, and it's the same lesson as the 45× gap between computer-use agents and structured APIs: the expensive part is almost never the work, it's the overhead you carry to reach it.

I expected the CLI to be cheaper. I didn't expect it to be more reliable. In a 75-run benchmark, the CLI path finished 100% of runs and the MCP path finished 72%— and the failures weren't the model making mistakes. They were mostly TCP timeouts on MCP's long-lived connection.

That's the trade hiding inside the architecture. A CLI spins up a fresh process per command — about 200ms of overhead each time — and there's nothing to time out between calls. MCP keeps a persistent session, which is roughly 5ms per call and genuinely better for tight, stateful, low-latency loops. But a persistent connection is one more thing that can drop silently in the middle of a long unattended run. If you've read my take on agents failing silently in n8n, this is the same category of bug: the failure isn't loud, it just quietly ends the work.

This is a decision, not a religion. Here's the split I actually use:

One warning on the MCP side: don't auto-convert a whole OpenAPI spec into an MCP server. That's how you end up carrying 60 tool definitions the agent uses twice a week. Curate hard — expose the five tools the agent actually needs, not everything the API can do. Same discipline I apply when deciding Claude Skills versus MCP: the cheapest tool is the one you never had to load.

In practice a single user request might shell out to a CLI, call one curated MCP server, validate internally with a function call, and hit a direct API for a status check. That's not messy — that's correct. Combined setups like this have hit 96.3% task pass rates using 63% fewer tokensthan prompting alone. The point isn't to pick a winner; it's to stop paying MCP's context tax on the 80% of calls that never needed it.

There's a third option that beats both for high-volume fan-out: let the model write codethat calls the tools instead of calling each one as its own turn. Anthropic's programmatic tool calling and Cloudflare's Code Mode both do this — the model emits a small script that orchestrates many calls, and only the final result comes back into context. The intermediate schemas and results never touch the context window, so the savings are absurd:

• Programmatic tool calling: one example dropped from 150,000 tokens to 2,000 — a 98.7% cut.
• Cloudflare Code Mode: a workflow went from 1.17 million tokens to roughly 1,000 — about 99.9%.

This is the same “let the agent write and run code” instinct behind building dynamic workflows in Claude Code, and it's the natural endgame of the cost work in how I cut my Claude API bill by 73%. If you want the official version, Anthropic's own Model Context Protocol docs are the canonical reference for when MCP is the right layer.

• For identical work, a CLI ran 4–32× cheaper than MCP in benchmarks — and one Intune test was ~35× cheaper.
• The reason is structural: MCP injects every tool schema into every turn; a CLI carries no standing cost.
• CLI was also more reliable in one test — 100% vs 72% of runs — mostly because MCP's persistent connection times out.
• Use a CLI when a mature one exists and you own the box; use MCP for OAuth SaaS, multi-tenant auth, governance, and tools with no CLI.
• Don't auto-convert an OpenAPI spec into MCP — curate to the few tools the agent truly uses.
• For high-volume fan-out, let the model write code that calls the tools (programmatic tool calling / code mode) — 98–99% fewer tokens.
• Measure tokens per completed task, not per call. The best agents mix all three.