MCP Is Dead? What's Actually Broken — and What Survives

“MCP is garbage.” That was Garry Tan, CEO of Y Combinator.

MCP stands for Model Context Protocol — the standard Anthropic designed for Claude Code to connect AI to external tools like Gmail, GitHub, and databases. It shipped in late 2024 and spread through the AI developer world almost overnight. OpenAI, Google, Microsoft, and AWS all adopted it. It moved under the Linux Foundation. For a moment it looked like the obvious industry standard.

Then 2026 arrived, and the wind changed.

“MCP is dead. Long live the CLI,” declared developer Eric Holmes. Across the community, a quieter consensus has been forming: MCP was never the silver bullet.

I run Claude Code with more than ten MCP servers connected at once, every day — serena for code analysis, Playwright for browser automation, Gmail, Google Analytics, context7 for docs lookup. This very article grew out of a topic my MCP-powered automation pipeline surfaced for me.

That daily use is exactly why I can tell you what’s actually broken about MCP — and what survives anyway.

Problem 1: Token Bloat — the Real Damage

MCP’s most serious problem is that simply using it eats into the model’s capacity to think.

Every model has a context window — roughly, the ceiling on how much it can hold in mind at once. When you connect an MCP server, the schema describing that server’s tools gets injected into the conversation automatically. Connect Gmail’s MCP server, and definitions for “search mail,” “get message,” “list labels” are embedded in the conversation before you’ve used a single one. One server is no big deal. Connect four, and you’ve burned 67,000 tokens — about the length of a short novel — before the model has started thinking about your actual problem.

A study called MCPGAUGE found that using MCP servers inflates input tokens by 3.25× to as much as 236.5×, while dropping the model’s accuracy by an average of 9.5%. Claude Code’s own repository logged the same complaint: “MCP tools consume 50% of the context” (Issue #13717).

Anthropic later added a Tool Search feature, cutting one measured case from 51,000 to 8,500 tokens — a 46.9% reduction. The improvements are real. But the underlying structure — connect a server and its schema is injected — hasn’t changed.

I’d added a rule to my own CLAUDE.md early on: only enable the MCP servers you actually need. With ten-plus connected, the unused tool definitions alone crowded the context enough that the model would forget instructions from the first half of a long conversation by the time it reached the second. I’d felt the problem as a rule of thumb; the research just put numbers on it.

Problem 2: The Double-Hop Latency

MCP’s architecture puts a server between the AI and the tool. When the model wants to fetch an email, it doesn’t hit the Gmail API directly — it asks the MCP server, the MCP server calls Gmail, and the result comes back through the MCP server. Two network round-trips per operation.

For a single call you’d never notice. But a model makes dozens of tool calls to answer one question. Processing twenty emails means looping through search → fetch → classify, over and over, and the double-hop stacks up each time. Interactively it just feels “a little slow.” In batch jobs it’s a clear bottleneck.

Problem 3: Debugging Is Painful

With a CLI tool you run one command and read the output. You curl an API, pipe the response through jq, and check whether you got what you expected. When it breaks, you can see where it broke.

MCP tools don’t work that way. Tool calls only execute inside the model’s conversation, which makes them hard to exercise in isolation. When something goes wrong, was it the model sending bad input, a bug in the MCP server’s handler, or an upstream API that changed? Telling those apart means parsing JSON-RPC transport logs. As a developer experience, that’s a clear step backward.

Problem 4: A Serious Security Hole

Everything so far has been about ergonomics. The security story is worse.

A survey of 119 publicly exposed MCP servers found that every single one allowed access without authentication, and 43% carried command-injection vulnerabilities. By April 2026, estimates put the number of at-risk servers around 200,000. Anthropic declined to change the spec, describing the behavior as “intended.”

In other words, security is left entirely to the author of each MCP server. The shape of the problem mirrors npm’s: convenience and risk both scale with the size of the ecosystem.

Problem 5: No Composability

Unix has a design principle: connect small programs with pipes. curl to fetch, jq to transform, grep to filter — each tool does one thing, and you compose them into something complex.

MCP tools have no such composability. There’s no way to feed one MCP tool’s output directly into another’s input; everything has to route through the model. Because the AI sits in the middle every time, processing stays linear — you can’t chain tools into an efficient pipeline. Work you’d write in one line of shell becomes many model round-trips in MCP. That’s the backdrop to “MCP is dead. Long live the CLI.”

And Yet MCP Isn’t Dead

That’s a long list of problems. So is MCP useless?

The honest verdict: it isn’t dead — it’s lost its claim to being universal.

Start with the facts. MCP sits under the Linux Foundation and has been adopted by OpenAI, Google, Microsoft, AWS, and Cloudflare. The ecosystem’s momentum is real. Big tech doesn’t pile onto a dead protocol.

And there genuinely are use cases where MCP is the right tool.

When you need real-time, stateful interaction. Browser automation with Playwright, for example: you snapshot the page on each navigation and decide the next action from the current state. That “hold state while you converse with the tool” pattern is hard to pull off with stateless CLI commands.

When you need managed auth. Gmail’s MCP server clears OAuth once, and every later session manipulates mail without re-authenticating. Do this from a CLI script and you’re writing your own token-management code.

When the API has a complex schema. For something like Google Analytics, with its sprawling argument surface, having the MCP server hide the argument assembly is genuinely useful.

In my own setup, Playwright, Gmail, and Google Analytics are still clearly better as MCP, and I have no intention of moving them to the CLI. One-shot operations like file or git commands, on the other hand, were always fine as plain CLI (Bash) from the start.

How to Choose, From Here

MCP has been demoted from “silver bullet” to “one option among several.” So how do you choose?

The rule of thumb reduces to two axes: does it hold state? and do you need composability? Stateful operations that stand on their own lean MCP. Stateless work you’ll want to combine with other tools leans CLI.

If you’re running five or more MCP servers right now, the first move is to ask whether each one really needs to be connected all the time. Just disconnecting the ones you don’t use cuts token consumption sharply and lifts the model’s accuracy. And if you’re thinking of building an MCP server, ask first whether a CLI script could do the job — if it fits in shell, that path is easier to debug, composable, and costs zero tokens.

MCP has clear territory where it’s the right choice. The problem was never the protocol itself; it was that MCP got picked as the default answer far too often. There are no silver bullets in technical selection — and MCP was never the exception. The industry is just catching up to that ordinary truth.