Stateless MCP Makes the Protocol Worth Using Again

Theo — the developer and creator behind t3.gg — was not an MCP fan. He said so explicitly, repeatedly, and with some force. So when he dropped a video calling the latest MCP spec "massive" and saying he "can't believe" he's excited to try it again, that's not nothing.

The spec in question is the 2026-07-28 Model Context Protocol release. If you want the full technical breakdown of what moved under the hood, our 2026 spec update covers the implementation details. The short version: MCP — Anthropic's standard for letting AI agents talk to external tools and services — has dropped its requirement for persistent, stateful connections and moved to a request-response model. Think of it less like a phone call that has to stay open and more like sending a text: fire the request, get a response, done.

That sounds like an incremental plumbing fix. It is not.

Why the Old Model Was a Problem

To understand why this matters, you need to understand what the old MCP architecture actually demanded. If you want a deeper primer on how the client-server protocol works conceptually, that's useful context here — because the old version's fundamental problem was structural.

Under the previous spec, every MCP server required a dedicated, live connection to its client. Not "when you need it" — always. Set up five MCP integrations in your agent environment, start a coding task that touches zero of them, and you still had five bound connections sitting there consuming resources. Theo walked through a concrete example with Codex: one agent session spawning multiple sub-agents, each requiring its own set of stateful MCP connections, multiplying into dozens of bound processes running simultaneously on a single machine.

"Each agent can just hit a random endpoint and get back some JSON and then decide when it wants to do things from there instead of it being a bound connection," Theo explains. "It is just an endpoint that is hit — which is, to be frank, the way it always should have worked."

That's not hyperbole. The stateful model meant that hosting MCP servers in the cloud was often economically irrational — you'd be paying for live infrastructure to serve connections that might never fire. The practical result was that a lot of MCP deployments ended up running locally by default, not by design preference but because the cost-to-value math just didn't pencil out at scale.

The new model flips this entirely. Stateless MCP servers can run on serverless infrastructure — AWS Lambda, Cloudflare Workers, whatever you'd normally use for lightweight HTTP endpoints. You pay when requests come in. You pay nothing when they don't. This isn't a marginal improvement; it's the difference between maintaining a staffed storefront and having a vending machine.

Simon Willison's Reversal

Theo isn't the only publicly skeptical voice who changed their tune. Developer and researcher Simon Willison — writing at simonwillison.net — called the release "stateless MCP day" and described it as the most significant change to the spec since its November 2024 launch. According to Theo's reading of Willison's post, Willison concluded he plans to lean into MCP much more now when building sensitive applications on top of LLMs.

Willison's reasoning on the safety angle is worth sitting with. Giving an agent a shell environment with internet access is powerful but hard to audit — the agent can do essentially anything a human with a terminal could do. MCP, by contrast, exposes a defined, self-describing set of endpoints. The agent can only call what's listed. For applications where you want tight guardrails on what an AI can actually touch, that constraint isn't a limitation — it's the whole point.

The practical proof, per Theo's account of Willison's work: Willison built a dataset integration using MCP that he'd attempted four previous times but never felt confident enough to release. The stateless spec finally gave him a version that met his bar. That's the kind of signal that lands differently than a blog post saying "this is better now." Four attempts, one successful ship. The friction wasn't skill; it was the infrastructure overhead the old spec demanded.

The Backwards Compatibility Problem Is Real

None of this means MCP suddenly works everywhere. Theo's enthusiasm comes with a pointed concern attached, and it deserves equal weight.

The new spec is not backwards compatible. Old clients expected stateful connections; the new architecture is the opposite of that. Two tools can both legitimately claim "MCP support" and be entirely unable to talk to each other depending on which version they're running. Theo's analogy — USB-C cables that are all labeled USB-C but perform wildly differently depending on the actual standard they support — is apt and a little grim. The fragmentation risk is real.

"By fixing the standard, they ruined the nature of the standard," Theo says. "It is a way, way better solution. But this new solution is not backwards compatible."

The concern isn't theoretical. There are already a lot of MCP servers in the wild that were built under the old spec, often during the 2025 period when every company was looking for ways to justify AI integration spending. Those don't automatically upgrade. Clients that haven't updated their MCP bindings won't work with new-spec servers. The ecosystem is now split, and the split is invisible from the outside — both sides call themselves "MCP."

Theo's counterargument to his own concern: in a world where LLMs are genuinely good at writing code, upgrading a client's MCP implementation to the new spec should take roughly an hour of agent time. Any company building agentic tools that can't find that hour is making a choice, not hitting a wall. He's framing the upgrade gap as a legibility test — if a tool claims AI capabilities but can't update to a new, simpler, better standard within weeks, that tells you something about how seriously they're actually shipping.

That's a reasonable filter. It's also optimistic in a way that real adoption timelines tend to punish. "An LLM can do it in an hour" and "the team has prioritized it" are different things, and the gap between them is the entire history of software standards adoption.

Where This Actually Lands

Honestly? Theo reversing course on MCP is the most interesting data point in this whole story. This is someone who was "notoriously against" the protocol, found it actively annoying in practice, and watched it get outcompeted by a markdown file. The fact that the stateless spec cracked his skepticism open is more informative than any benchmark or launch blog post.

The MCP ecosystem is now at a genuine inflection point: a substantially better protocol exists, two credible critics have flipped their positions, and the main obstacle is the unglamorous work of getting the old guard upgraded. The spec improved. Whether the tooling around it improves fast enough to matter is a separate question — and not one Anthropic controls.

— Yuki Okonkwo, AI & Machine Learning Correspondent