In late May, a backend engineer at the Canadian insurtech Quandri published a post titled, with no hedging, "MCP is dead", and backed it with the kind of numbers most takedowns skip. Connecting four ordinary servers, Linear, Notion, Slack and Postgres, ate 10.5 per cent of a Claude-sized context window before anyone typed a word, purely on tool definitions. Linear alone shipped 42 tools and roughly 12,800 tokens, whether you ever called two of them or all of them. The piece was careful, measured and widely shared. By the time it ran it was also half out of date, a fact the author flagged in her own update note near the top.

That gap is the interesting part, and it is not where most of the commentary went.

The case the critics actually make

The argument did not start at Quandri. It started in February with Eric Holmes, whose "MCP is dead. Long live the CLI" laid out the structural complaint: he kept writing the same tool documentation he would have written anyway, and the model never needed a new protocol to read it. He benchmarked a Jira MCP server against the plain REST API and clocked it at three times slower per call, and 9.4 times slower on the first call once you count initialisation. Quandri reproduced the spirit of that on its own stack and added the context maths.

Stack the complaints and each one is real. Tool definitions crowd the window. Every call routes through a separate server process that can fail to start, demand re-auth, or die mid-session. Permissions are coarse and hard to inspect. And much of it duplicates command-line tools the model already learned from man pages and public code. The CLI, by contrast, composes with pipes and grep, debugs in a terminal a human can watch, and costs almost nothing to keep around. The pitch, stated fairly, is that the industry wrapped a solved problem in a protocol and called it progress.

What the obituaries are actually killing

Here is what I can verify against that pitch. The largest and most quantified charge, context bloat, was being patched by the platform while these posts were being written. Quandri's own update concedes it: Claude Code now defers MCP tool schemas and loads them on demand through a tool-search step, cutting the always-on definition overhead by something like 85 per cent. A setup that used to burn 77,000 tokens before any work began drops to under 9,000.

And the company that built MCP got there first, and louder. Back in November, Anthropic, MCP's own author, published "Code execution with MCP", showing an end-to-end workflow that fell from about 150,000 tokens to roughly 2,000, a 98.7 per cent cut, by letting the agent write code against MCP servers instead of loading every definition up front. Near as I can tell, the strongest single number in the case against MCP is a number about one calling convention: dump every tool's full schema into the prompt, all the time, and keep it there. That convention is dying. The protocol underneath it is a different object, and conflating the two is where the obituary genre quietly cheats.

The honest counter is that deferred loading does not fix everything, and I want to give it its due. Holmes' latency figure survives a tool-search step untouched, because it is architectural. A process layer still sits between the model and the API. Servers still fail to initialise. Permissions are still coarser than a scoped API token. None of that is a context-budget artefact, and anyone telling you tool search closed the case has not read the case. That is the strongest version of the sceptic's position, and it holds.

But look at where the sceptics actually land once the rhetoric clears. Quandri's conclusion reads less like a eulogy than like a routing table: CLI for tools you already run, Skills for repeatable workflows, MCP for services with no decent CLI and for shared auth and permission scoping, the production database being the obvious case. Holmes keeps MCP for the situations where it earns its keep. Strip the headline and both pieces argue the same modest thing, which is that MCP should stop being the reflexive default and start being one option you reach for on purpose. That is not a death. It is a demotion from default to dependency, and the headline oversells the finding by a wide margin.

The unbundling, and who keeps buying the dead protocol

The 2024 sell for MCP was the USB-C of AI: one port for every tool, plug and forget. What 2026 has actually settled into is a portfolio. CLI for what the model already knows, Skills for the work you repeat, MCP for the rest. The "dead" headlines are really the market discovering there is no universal port, only a routing decision taken service by service. That is a more useful conclusion than the obituary it travels under, and it is roughly where careful teams were heading anyway.

Meanwhile the protocol that is supposedly dead keeps getting adopted by exactly the people who would benefit most from burying it. OpenAI took MCP across its products in March 2025, the desktop ChatGPT app included. Google DeepMind followed for Gemini. In December, Anthropic, OpenAI and Block donated MCP to a new Linux Foundation body, the Agentic AI Foundation. That is the move you make to turn a vendor format into neutral infrastructure, not the move you make over a corpse. Yes, "MCP supported" is now a reflexive checkbox on every SaaS landing page, and Quandri is right that the sticker often hides a flaky server, the way "AI-powered" and "blockchain-based" did in their cycles. But a boring checkbox that everyone ships is also what winning looks like for a standard. Protocols do not triumph by being elegant. They triumph by being everywhere and dull.

There is a second-order cost worth naming, because the CLI-first camp tends to wave it away. The reason MCP exists is that "just give the model a CLI and the docs" works beautifully until you have fifty services, a team, and an audit requirement. Auth scoping, per-tool permissions and a uniform way to discover what a service can do are exactly the unglamorous problems a shared protocol absorbs so each team does not reinvent them. A skill that pastes a bearer token and a curl command into the prompt is lighter, and it is also the thing your security lead will eventually ask you to stop doing. The honest read is that the CLI wins on ergonomics for an individual engineer and loses on governance at the scale where governance is the whole point.

The bet

So here is the falsifiable version. If "MCP is dead" is right in the strong sense its headline claims, then over the next year MCP should keep bleeding tokens while teams complain, and the standard should fragment as the big labs drift to private alternatives. My read says close to the opposite. The context argument fades from the discourse within a year, because deferred loading and code execution make it moot. MCP narrows to auth, guardrails and no-CLI SaaS, which is the job it was always best at. And the foundation backing hardens rather than splinters. The bounded test: if by mid-2027 deferred loading is the default, the token complaint has gone quiet, and MCP is still the thing every major model speaks, then nothing died here except the habit of loading every tool you own into a window you have to pay for. That is the bet, and it is the kind that gets settled by config files, not manifestos.