Saying No to MCP Was the Easy Part

The people who declared MCP dead in March were right about the symptom and wrong about the patient. That’s my contrarian read, and I’ll defend it: the protocol that got written off as bloated plumbing spent the next few months quietly removing the exact thing everyone was complaining about. The obituaries aged worse than the protocol did.

Quick recap for anyone who tuned out after the pile-on. At Ask 2026 on March 11, Perplexity CTO Denis Yarats said the company was moving away from MCP, pointing at a number that made a lot of engineers wince: 72% of the context window consumed by MCP tool definitions. Within days, “MCP is dead” was the take of the season. I watched teams I advise rip MCP servers out of their stacks on the strength of a conference remark and a 72% figure they never measured in their own setup.

Why that number landed so hard

Because it was real, and because anyone who had wired up more than three or four MCP servers had already felt it. Tool definitions are text. Text is tokens. Tokens are the budget you actually fight over when you’re building something that has to reason across a long session. If three quarters of your window is spent describing what the model could do before it does anything, you don’t have an agent, you have a very expensive table of contents.

So Perplexity’s call made sense for Perplexity. A consumer search product running at that scale is counting tokens the way airlines count fuel. What bugged me was the generalization that followed. A company with full control of its own model, its own serving stack, and its own tool surface deciding it doesn’t need a standard interoperability layer is not evidence that the layer is worthless. It’s evidence that vertically integrated products don’t need standards as badly as everyone else does.

The part the hot takes skipped

MCP’s value was never really the token efficiency. It was auth, audit trails, and governance. That’s an unglamorous list, which is why it didn’t trend. But if you’ve ever sat in a review where someone from security asks who approved a tool call, what identity made it, and where the log lives, you know those three words are the difference between a demo and something that ships inside a company with compliance obligations.

Nobody who went viral in March was addressing that. They were comparing MCP to a hand-rolled function-calling setup and declaring victory on context size. Fine. Now go explain your hand-rolled setup to an auditor.

Then July happened

The 2026-07-28 specification dropped and it’s the biggest structural change the protocol has had. MCP is now fully stateless. Sessions are gone. No handshake, no ticket. Every request carries what the server needs to make sense of it on its own: protocol version, client identity, capabilities, bundled in. Updated SDKs for TypeScript, Python, Go, and C# shipped alongside it.

If you’ve deployed anything stateful behind a load balancer you already know why this matters. Stateless means HTTP deployment stops being a special case. It means horizontal scaling without sticky sessions and without a session store that becomes your weakest link at 3am. Cloudflare’s write-up and the official spec post both frame it around enterprise scalability, and for once I think the framing is honest rather than marketing. Removing sessions removes a category of deployment friction rather than papering over it. The spec also adds extensions for interactive apps and long-running tasks, which tells you where the maintainers think the hard problems are now.

What I’d actually tell you to do

I review tools for a living, so here’s the practical version.

• If you ripped MCP out in the spring based on someone else’s token math, re-measure on the current spec before you commit to maintaining your own integration layer forever. Custom glue is cheap to write and expensive to own.
• If you’re a small team shipping a single product with a handful of tools, you may genuinely not need MCP. That was true in February and it’s true now. Standards cost something.
• If auth, audit trails, and governance appear anywhere in your requirements, the calculus is different and it isn’t close. That’s the use case MCP was built for, and the stateless rewrite makes it easier to run, not harder.
• Pin your SDK versions and read the migration notes. A protocol that removed sessions is a protocol that broke assumptions somewhere in your code.

The lesson isn’t about MCP

It’s about how fast this space buries things. A CTO shares one real constraint from one real product, the number is genuine, and four months later the protocol has addressed the structural complaint while the “it’s dead” posts are still circulating with no correction attached. Standards don’t die from bad press. They die from nobody using them, and that is not what’s happening here.

You said no MCP. That was a defensible call in March. Worth asking whether it’s still your call in the version that exists now.

🕒 Published: October 1, 2026