The CLI vs. MCP Thing Is a Restaurant Problem

Every couple of years the programming world picks a fight that isn't really a fight. Tabs vs. spaces. Monoliths vs. microservices. And now: CLI vs. MCP.

In February 2026, Eric Holmes wrote MCP is dead, long live the CLI and it shot to the top of Hacker News. At the exact same time, seven enterprise MCP governance frameworks launched for regulated industries, VentureBeat was running alarmed headlines about MCP adoption outpacing security controls, and Gartner projected 40% of enterprise apps would embed task-specific AI agents by end of 2026, up from under 5% the year before.

Both camps have evidence. Neither camp can explain why the other camp also has evidence. And that, my friends, is the tell.

Let me explain with a restaurant analogy, because I have never met a technical argument that couldn't be improved by thinking about food.

The Restaurant

Imagine you're cooking dinner at home. You've got a nice kitchen. You know where the knives are. You know which burner runs hot. You don't need a menu, you don't need a waiter, you don't need a reservation system. You just... cook.

That's CLI.

Now imagine you're running a restaurant. Forty covers a night. Multiple cooks. Customers with allergies. Health inspectors. You need tickets, you need a POS system, you need to track who ordered what and whether the sous chef actually fired table six's entrée or just thought about it.

That's MCP.

Here is the thing people keep getting wrong: almost everybody reading this essay is cooking at home. The restaurant case is real, but it is a lot rarer than the MCP pitch decks want you to believe.

Why the Home Cook Is Right (Almost All of the Time)

The CLI argument is straightforward, and it is correct for the overwhelming majority of real-world agent workflows today.

LLMs already know how to use git, gh, curl, kubectl, and docker. They've seen millions of examples in training data. When an agent calls these tools through the shell, it pays zero extra tokens for schema definitions. The LLM already knows the menu.

MCP works differently. A typical MCP server announces its capabilities by injecting every tool definition into every conversation at the start, whether those tools get used or not. It's like handing someone a 200-page Cheesecake Factory menu when all they wanted was a glass of water.

ScaleKit measured this directly. For the query "what language is this repo?", CLI consumed 1,365 tokens. The equivalent MCP call consumed 44,026 tokens. That's a 32x difference, almost entirely explained by 43 tool schemas loaded into context whether they were needed or not. MCP also failed 7 out of 25 times due to connection timeouts. CLI worked every single time.

32x! That's not a rounding error. That's the difference between a text message and a novella. And this is not some cherry-picked worst case. Isaac Flath benchmarked a popular GitHub MCP server and found 93 tool definitions consuming 55,000 tokens before the first question was even asked. His conclusion was exactly right: the protocol is plumbing; tool design is what matters. And right now, most MCP tool design is terrible.

Mario Zechner's independent benchmark found CLI winning by 10-22% on simpler tasks, consistent with ScaleKit. On complex multi-step analysis tasks, MCP's structured output gave it a roughly 39% cost advantage over tmux-based CLI, because structured results cut the back-and-forth round-trips that drain token budgets on longer workflows. Fair enough. But ask yourself: what percentage of your actual agent tasks are "complex multi-step analysis" versus "run this command and tell me what happened"? For most developers, most of the time, it's the latter.

Thoughtworks put "naive API-to-MCP conversion" in their Technology Radar Hold ring, which is Thoughtworks-speak for "please stop doing this." The problem isn't MCP as a protocol. The problem is that the most natural thing to do with MCP is the wrong thing: take every granular API endpoint you have and expose them wholesale to agents, like photocopying your entire internal wiki and handing it to a new hire on their first day instead of just showing them where the bathroom is.

"But what about unfamiliar tools?" I hear the MCP camp say. "LLMs don't know your internal APIs!"

They don't need to. You can pair any CLI tool with a SKILL.md, a README excerpt, a man page summary, and inject it into context right before the agent needs it. This is exactly how Claude Code works with its skill system: read the docs, then run the command. No MCP server, no schema registry, no 43-tool payload on every conversation. Just documentation and a shell. It works surprisingly well, and it works without the 32x token tax.

So the CLI advocates aren't just right in some narrow edge case. They are right for the vast majority of developers building agent workflows today.

Now, in fairness, the MCP camp is aware of the token problem and is actively working on it. In November 2025, Anthropic published Code execution with MCP, an engineering guide that basically says: stop loading all tool definitions upfront. Instead, let the agent write code that calls MCP tools through a filesystem of typed modules. The agent browses a directory tree, loads only the definitions it needs, and intermediate results stay in the execution environment instead of flowing back through the model. Anthropic claims this takes a 150,000-token workflow down to 2,000 tokens, a 98.7% reduction. A production implementation for GitHub with 112 tools confirmed similar numbers.

That's impressive. It also proves my point.

Look at what the "code execution pattern" actually is: the agent reads documentation on demand from a filesystem and then runs code through a shell-like execution environment. Sound familiar? It's CLI with extra steps. The MCP camp's own solution to MCP's biggest weakness is to make MCP behave more like CLI. They reinvented SKILL.md + bash, added a TypeScript wrapper, and called it a breakthrough.

Two Narrow Cases Where CLI Actually Falls Short

Now, I am not going to pretend CLI is perfect for literally every scenario. There are exactly two situations where it hits a real wall. Two. Not the seventeen that MCP vendors will try to sell you.

Other people's credentials.

CLI agents carry your credentials. Your token. Your SSH key. Your environment variables. This is fine when you're cooking for yourself. It is emphatically not fine when you're cooking for forty people with different dietary restrictions.

To make CLI work across multiple users, you need a token vault, per-request credential swapping, and tenant isolation logic that lives entirely outside the CLI layer. Any bug in that code, and Customer A sees Customer B's data. This is not theoretical. The Asana Confused Deputy bug (June 2025) was a real production incident where exactly this happened, and it happened on an MCP server that botched the implementation. (Even MCP gets this wrong!) But what MCP gives you is OAuth delegation at the protocol level: per-request scoped credentials, contextual constraints, a clear line between "agent identity" and "user identity." CLI's ambient credential model makes this distinction impossible to enforce at the protocol layer. You can build workarounds, but you'll be building them from scratch, outside the protocol, in exactly the place where bugs hide until they become headlines.

If you are building a multi-tenant product where an agent acts on behalf of many different users, this matters. If you're not, it doesn't.

"Who did what and why?"

Shell history logs commands. Great. It does not log who authorized them, on whose behalf, with what scope, or what came back. In a SOX audit or a HIPAA review, that's not a log. That's creative writing.

MCP's typed tool-call records are structured, queryable, and attributable to a specific user and tenant. Compliance teams can actually work with them. If you are in a regulated industry and an auditor will eventually ask you what your AI agents did and why, MCP gives you an answer. CLI gives you a bash history file and a prayer.

But let's be honest about how many developers are actually in this situation. If you're building fintech or healthcare software under regulatory scrutiny, yes, you probably need structured audit trails. If you're a dev team automating your CI/CD pipeline, deploying to staging, or querying your own databases, nobody from compliance is ever going to look at your agent logs. You don't need MCP. You need bash.

The Heuristic (It Fits on a Post-it)

Default to CLI unless one of these is true:

1. Your agent acts on behalf of many users, not just you.
2. A regulator will audit what your agent did.

That's it. Two conditions. And for the overwhelming majority of teams today, neither one applies. Default to CLI. Graduate to MCP when the evidence forces you, not when a conference talk persuades you.

CircleCI calls this the inner-loop/outer-loop split: CLI belongs in the inner loop where speed matters, MCP in the outer loop where authenticated multi-user access is required. I'd add: for most teams, the outer loop is a lot smaller than they think.

The Mistake That Costs More

Both mistakes are real, but they are not equally expensive.

Solo developers adopt MCP too early. Autodock launched their provisioning agent as MCP-first. Adoption stalled outside a few early adopters. They eventually pivoted to a hybrid model and reached more users after reducing the abstraction surface. They paid the restaurant tax before they had any customers.

Growing teams stay with CLI too long. StackOne's production audit documents teams that built multi-user SaaS agent features on CLI architectures, hit the multi-tenancy wall, and had to rebuild from scratch. The integration debt accumulated silently until it became a rewrite.

Both mistakes are bad. But there's an important asymmetry: adopting MCP too early costs you every single day in token overhead, development friction, and debugging complexity. Staying with CLI too long costs you once, when you hit the wall and have to refactor. And you might never hit that wall at all. Most projects don't grow into multi-tenant regulated platforms. Most projects stay in the kitchen.

If you're going to be wrong, be wrong on the CLI side. The daily cost of premature MCP adoption is higher than the one-time cost of a late migration.

The Sorting

Here's what I think actually happened. MCP didn't die. It got sorted. And when the sorting happened, CLI won most of the rooms.

The developers who declared MCP broken were not wrong about the friction. They were wrong about what caused it. They adopted MCP for solo workflows, paid the complexity tax for a problem they didn't have, and then blamed the protocol for being expensive. That's like complaining that your restaurant POS system is overkill when you're making a sandwich for yourself. You're right! It is overkill! That doesn't mean the POS system is broken. It means you don't need a POS system.

Meanwhile, the small number of use cases that genuinely need multi-tenant auth and structured audit trails are quietly implementing MCP with less noise and more compliance documentation. Good for them. They have a real problem and MCP is a reasonable solution to it.

But for most of us? For the vast majority of developers building agent-powered tools today? The shell is right there. It works. It's fast. It's cheap. It's battle-tested. And your LLM already knows how to use it.

Stop installing restaurant equipment in your kitchen.