MCP Was Declared Dead in January. The Numbers Say Otherwise.

Somewhere around January this year, my corner of the internet decided the Model Context Protocol was finished. The argument was always the same screenshot: a CLI call doing in a couple hundred tokens what an MCP tool call needed tens of thousands to do. "Just give the agent a shell" became the smart-person take. And honestly? It was a good take.

I had skin in this game. I run an MCP server in production — Next.js, TypeScript, real users — and I'd spent enough evenings watching tool schemas devour context windows to nod along with most of the criticism. But it's June now, and the data did something the discourse didn't predict: it went back up.

So this is my attempt at an honest accounting: what the critics got right, what the resurgence actually means, and what I changed in my own server because of it.

The backlash had real numbers behind it

The token math was never close. Firecrawl measured CLI operations averaging around 200 tokens against 32,000–82,000 tokens for equivalent MCP operations. That's not an optimization gap. That's two orders of magnitude.

And it gets worse, because a bigger context isn't neutral — it's hostile. A Databricks study found model correctness starts degrading around 32,000 tokens, long before the "1M context window" marketing implies, thanks to the lost-in-the-middle problem. Stuff your window with tool schemas and verbose JSON responses and you're not just paying more per call. You're actively making the model dumber.

I felt this one personally. My server's early tool definitions were generous: verbose descriptions, relationships populated deep by default, full documents returned when the agent needed three fields. The agent would burn a huge slice of its context before it had done anything useful. The critics weren't describing some hypothetical bad MCP server. They were describing mine.

And yet, the graph went back up

Here's what mid-2026 actually looks like. Google Trends shows MCP search interest clearly resurging after the early-2026 dip. Bloomberry analyzed 1,400 MCP servers and charted 232% growth in six months (August 2025 to February 2026). Firecrawl reports its own MCP usage grew roughly 35% in the last month alone.

Dead protocols don't do that. So either a lot of teams are wrong, or the critics and the adopters were measuring different things. I think it's the second one.

MCP isn't an action protocol. It's a context pipe.

The most interesting number in Bloomberry's dataset isn't the growth — it's the shape. Read operations outpaced writes 2:1. And Zuplo's State of MCP report found 63% of users adopt MCP servers primarily to access data sources: documentation, knowledge bases, internal systems. People aren't wiring up MCP so agents can do things. They're wiring it up so agents can know things.

That reframing matters because the actual discipline being practiced here is context engineering, not tool calling. Agents working without fresh data hallucinate around 35% more. A well-built MCP server is a runtime answer to the question "what does the model need to know right now?" — instead of pasting half your wiki into a system prompt and hoping. As InfoWorld put it, MCP shifts AI development from fragile prompt tuning to repeatable engineering.

When I checked my own server's logs against this, the pattern held: reads dominate, and the calls that exist mostly exist to feed an agent context it couldn't otherwise get.

The part a shell can't replicate

The "just use the CLI" argument is correct right up until the moment your agent needs to act on behalf of a specific user. OAuth and delegated authentication, multi-tenant boundaries, governance and audit trails — this is where MCP holds and a shell folds. A CLI command runs as whoever owns the box. An MCP server can know who's asking, what they're allowed to see, and write it all down.

That was the actual reason my server exists as an MCP server and not a folder of scripts: per-user auth. The token overhead was the price; scoped, auditable access was the product. The January discourse priced the overhead and forgot to price the product.

What I changed after the backlash

The critics didn't kill my server. They refactored it. The single highest-leverage change was making every read opt-in instead of generous by default:

// before: every tool call returned everything
return payload.find({ collection: "posts", depth: 2 });

// after: shallow by default, caller opts in to fields
return payload.find({
  collection: "posts",
  depth: 0,
  select: { title: true, slug: true, updatedAt: true },
  limit: 10,
});

Terser schemas. Tool descriptions went from paragraphs to single sentences. The model doesn't need prose; it needs to disambiguate this tool from the one next to it.

Fewer tools. Every exposed tool is schema text the model pays for on every single turn, whether it uses the tool or not. I cut the ones the logs said nobody called.

Capped responses. Hard limits and pagination everywhere. An agent that needs more can ask again; an agent that gets 80,000 tokens it didn't ask for gets worse at its job — that's the Databricks finding, applied.

This is the progressive-disclosure pattern the ecosystem is converging on, and it's also where clients are heading — Claude Code now defers MCP tool schemas and loads them on demand for exactly this reason. The protocol survived by getting leaner on both ends.

The verdict

Don't pick a side. Pick per job. CLI for cheap, local, deterministic operations where the agent is acting as you on your machine. MCP where the context is dynamic, the access is user-scoped, and somebody in compliance will eventually ask for the audit log.

And keep one more number in mind: Sonar's 2026 survey found 96% of developers don't fully trust AI agent output. You can't fix that with a bigger model — the lever you actually control is the quality of the context you feed it. That's the job MCP turned out to be for.

InfoWorld's framing is the one I'd bet on: MCP-like abstractions becoming standard infrastructure, much like REST did. Nobody writes excited threads about REST. Nobody declares it dead, either. MCP didn't die in January — it stopped being exciting, which is the best thing that could have happened to it.