One engineer at Quandri sat down to measure what four MCP servers actually cost her team. Linear, Notion, Slack, and Postgres - 77 tools. The tool schemas alone consumed 21,077 tokens, before a single line of real work hit the context window. On a 128K GPT-4o window, that's 16.5% gone before you've typed a question.
That measurement landed on Hacker News in May, sparked 174 comments, and touched off the debate now sitting somewhere between honest engineering critique and deliberate provocation: is the Model Context Protocol actually worth using?
The answer is yes - but only if you're precise about when.
What the "MCP is dead" critique actually shows
Benchmarking Jira MCP against its REST API directly, the original article found MCP was 3× slower per call and 9.4× slower on first call including initialization.
Every MCP server adds a process layer between the LLM and the underlying API, and the sharpest version of the critique is that MCP duplicates functionality that already exists and works better.
The token comparison is the most brutal part. To look up the same Linear issue: a CLI approach costs roughly 200 tokens total (50 for the prompt, 150 for the response), while MCP costs around 12,957 tokens - 12,807 of which are tool definitions always loaded into context regardless of whether you call them. That's 65× more tokens for the same operation.
These days, every SaaS landing page has "MCP supported" in the feature list. Whether the MCP server is stable or how much context it eats doesn't matter - the goal is checking the "we do MCP too" box. Same pattern as "AI-powered" and "blockchain-based" marketing from years past.
That observation stings because it's right. A protocol that ships fast attracts vendors who implement it sloppily. When users actually connect, they get dozens of tool definitions loaded, initialization failures, and mid-session crashes.
The honest version of the anti-MCP argument isn't "the protocol is bad." It's "most implementations are bad, and a bad implementation costs you tokens you can't get back."
So the critique lands. But it doesn't end the conversation.
Why the ecosystem didn't abandon it anyway
The MCP spec received major updates in November 2025 - asynchronous operations, statelessness, server identity, and an official community-driven registry. The numbers that followed: 97 million monthly SDK downloads across Python and TypeScript, over 10,000 active servers, and first-class client support in Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code.
In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation, with OpenAI and Block joining as co-founders and AWS, Google, Microsoft, Cloudflare, and Bloomberg as supporting members. That's not a protocol dying in committee. That's infrastructure getting a governance layer.
More pointedly, analysis of 1,400 MCP servers by Bloomberry charted a 232% increase in six months, from August 2025 to February 2026, with read operations outpacing write operations two to one. Teams aren't using MCP to take actions at scale yet - they're using it to retrieve context. That's the actual use case it's winning.
It's arguably brought agentic AI into the mainstream much faster than the industry expected - by making it easier to connect agents to many different sources of data, it's now possible to provide agentic systems with richer context than would otherwise require significant time and investment.
The real answer to the context problem also came from an unlikely direction: Anthropic's own engineering team. Since the Quandri measurements were taken, Claude Code rolled out Tool Search with Deferred Loading, which loads MCP tool schemas on-demand and reduces context usage by 85%+. The context bloat described in the original critique is largely addressed for users on current Claude Code versions - though the performance, debugging, and architectural arguments still apply.
Where MCP earns its keep, and where CLI wins
This is the part most of the debate skips. Quandri itself uses all three approaches side by side: Bash and CLI for tools already used day-to-day (gh, psql, aws) - zero context cost, full flexibility, debugs straight in the terminal. Skills for repeatable multi-step workflows like commit drafting and PR reviews, loaded only when invoked. MCP for services without a strong CLI (Slack, Linear, Notion), and where team-wide auth or permission scoping matters.
That's the practical split. CLI wins for high-frequency, latency-sensitive operations against tools that already have strong command-line interfaces. MCP wins when you need standardized discovery across a team, when the underlying service doesn't have a usable CLI, or when you're prototyping integrations and want the ecosystem to do the plumbing.
If tool descriptions are defective, underspecified, or misleading, the model may select the wrong tool, supply invalid arguments, or take unnecessary interaction steps. The tool description is not merely documentation - it serves both as a requirement-like specification that defines expected behavior and as a prompt-like instruction that shapes the model's contextual reasoning. This hybrid role blurs the boundary between software requirements and natural-language prompts, creating a novel design surface where textual imperfections can propagate as both specification errors and prompt misguidance.
That's the thing nobody talks about when they argue over tokens: the quality of the tool description is now a first-class engineering artifact. A well-written MCP tool description is more like a contract than a comment. Getting that wrong quietly costs more than the token overhead.
The question the debate keeps dodging
The "MCP is dead" framing is wrong, but it's usefully wrong - it forced a real conversation about architectural tradeoffs that the hype cycle was not having.
MCP provides a foundational protocol for agents to connect to many tools and systems. However, once too many servers are connected, tool definitions and results can consume excessive tokens, reducing agent efficiency. Anthropic wrote that on their own engineering blog. The protocol's inventors acknowledged the problem before the critics got loud.
The harder question isn't whether MCP has flaws. It's whether a standardized protocol - even an imperfect one - is better than the alternative: every team writing bespoke integration code that breaks when an API changes, that new teammates can't read, and that no agent framework can discover automatically.
As one CTO framed it, "MCP provides the plumbing that makes context engineering practical." Without standards, teams end up building fragile custom data pipelines that break often.
That's the real steelman for MCP, and it holds. A shared protocol with known failure modes is easier to reason about than a hundred custom integrations with unknown ones. The question is not whether to use MCP. It's whether you're using it for the right operations at the right granularity - and whether your tool descriptions are tight enough to do actual work.
Teams building on MCP today should pick servers the way they'd pick dependencies: check the maintenance cadence, read the tool schemas before connecting, and measure what each server actually costs in tokens on your specific stack. The context window is a budget. Spend it on the work, not the menus.