TL;DR. The diagnosis that MCP burns tokens is right. But that's a problem of the load pattern that dumps every tool definition up front, not of the protocol — and that pattern is already being split open by tool search. And the skeptics' prescription, go back to the CLI, only works for tools that already have a shell-reachable surface. A tool bound to live editor state, like Unity, has no such surface. That's why I can't turn MCP off.
The Promise of MCP
When Anthropic shipped the Model Context Protocol in late 2024, the nickname that stuck was USB-C for AI. One standard connector plugging an LLM into external tools — GitHub, Linear, Notion, Slack — and the era of writing a new adapter per tool was over. Within a year and a half MCP was accepted as foundational infrastructure, and every halfway-serious SaaS shipped its own MCP server.
The Case for Skepticism
The developers who use that promise daily are now turning their backs on it. The most head-on rebuttal is Quandri's engineering blog post, "MCP is dead". The core is cost.
- Context erosion — Quandri's four connected MCP servers ate roughly 21,077 tokens before anything was used — 10.5% of Claude's 200K context. Linear alone was 12,807 tokens across 42 tool definitions. You actually use a handful of them.
- 65x — Looking up one Linear issue via the CLI is about 200 tokens; doing the same thing through MCP is about 12,957. Same result, 65 times the cost.
- Slow — In an independent benchmark MCP was 3x slower per call, 9.4x slower on the first call. Add mid-session server crashes, process restarts after auth failures, and an opaque permission model.
This isn't one company's grievance. Perplexity ripped MCP out internally, citing 72% context-window waste, and in one measurement just three servers — GitHub, Playwright, IDE — filled 143K of 200K (72%) with tool descriptions while tool-selection accuracy collapsed from 43% to under 14%. The skepticism is numbers, not sentiment. Not a card to discount.
The Prescriptions Already Exist
The skeptics prescribe two things. Use the CLI you already use — the model learned that tool from man pages and Stack Overflow. And Skills — don't keep every definition resident; load a tool's usage only when needed. Both are right. And both share the same diagnosis: the problem isn't what MCP is, it's how the definitions are loaded.
And that load pattern got split open over the past six months.
- Code execution with MCP — Anthropic shipped a way to move the tool catalog out of model context and into code/filesystem. The agent writes code to call tools instead of calling them directly, and reads a definition only when it needs it. One workflow went from 150K tokens to 2K — a 98.7% cut, ~10x faster.
- Tool search — Anthropic's Tool Search and Programmatic Tool Calling went GA in February 2026. When tool descriptions would exceed 10% of context, instead of keeping them all resident the system floats only the names and pulls schemas in via search.
- Code Mode — Cloudflare's February approach exposes an entire API through two tools — search and execute — at about 1,000 tokens. Spreading the same surface through native MCP costs 1.17M tokens.
The Claude Code I write this blog in runs exactly that way. Dozens of MCP tools sit there as names only, and when one is needed it pulls the schema via ToolSearch. The design that preloads 21,077 tokens, the one the skeptics hit, is already past tense. MCP isn't dying; its load pattern is changing.
Where the CLI Can't Reach
If that were all, this ends at "the skeptics are right and the fix has shipped." It doesn't end there, because of the premise baked into prescription #1 — go back to the CLI assumes a shell-reachable surface already exists. git, gh, Linear have CLIs. They have man pages. Those tools are driven by text without any MCP at all.
Unity has none of that. I build a rhythm game in Unity using Unity MCP, and it does not reduce to a shell. Reading the live scene graph, inspecting the serialized fields of the selected GameObject, triggering a domain reload, catching console logs, touching play-mode state — there is no unity-cli command that selects a GameObject and reads an inspector value. Unity is a stateful runtime bound to its GUI, and the only door into that living state is the single MCP server embedded in the editor.
Blender, Figma, game engines, DAWs — the whole category that manipulates live editor state is the same. Here MCP isn't redundant with a CLI; it's the only entrance. The skeptics' prescription reaches only tools that reduce to shell text. Tools that don't reduce sit outside its range. So you can't turn it off even knowing it burns tokens.
The MCP That Gets Redesigned
So the assertion is this. MCP is a fair target of skepticism, but the target is eager-loading, not the protocol — and the target is already falling. The outline of how to use MCP without invading tokens and context is in hand: don't preload definitions, pull them in via search (tool search); push the catalog out of model context and into code (code execution).
What's left to research is stateful tools. Tool search and code execution are optimized for SaaS APIs whose calls are stateless. How you apply progressive disclosure to a tool whose state is alive — like Unity — is still immature: dump the whole scene graph and context blows up again; trim too hard and the agent goes blind. A load strategy that exposes just enough live state to the model — that's the next thing to dig into. I'm digging there.
The one line I owe the skeptics is clear: an MCP that preloads tokens deserves to die. It's just that this is not the death of MCP — it's the death of a bad load pattern.
References
Skeptic side
- Quandri — MCP is dead
- Perplexity drops MCP internally — 72% context waste
- The bloat tax — MCP tools eat context and tool-selection accuracy collapses
Prescription side