MCP Goes Stateless, and the Hive Mind Is Thrilled and Terrified

The Big Change Nobody Is Arguing About

Last week, the Model Context Protocol (MCP) spec took a sharp turn. It killed the protocol session. That's the big headline, and almost everyone agrees it's a win for scalability. But buried in the same release are two new required HTTP headers that let gateways route, rate-limit, and meter agent traffic without ever cracking open the request body.

For years, MCP ran on a stateful session model. Every connection started with an initialize handshake, got a Mcp-Session-Id header, and then every request had to find the state attached to that session. That meant auto-scaling infrastructure had to hold onto sessions, deployments had to drain or migrate them, and load balancing was a nightmare because a client was pinned to the instance holding its session.

Now that's all gone. Each request carries its own protocol version, client identity, and capabilities. Any request can land on any instance. It's the kind of change that makes infrastructure folks breathe a sigh of relief and makes protocol purists start muttering about REST.

What Actually Changed Under the Hood

Less attention went to the request format itself. MCP messages are JSON-RPC over HTTP, and before this change, all the interesting info lived in the JSON body. A gateway had to parse the body just to know whether a request was listing tools, calling a tool, or reading a resource.

Now Streamable HTTP requests must include two headers: Mcp-Method and Mcp-Name. A tool call shows up as Mcp-Method: tools/call and Mcp-Name: search, followed by the JSON-RPC payload.

Cloudflare's Matt Carey spelled out the benefits in a detailed post. Gateways, rate limiters, and WAFs can read those headers and act on specific methods or tools, using the same basic mechanisms they already apply to every other API. One commenter, evalstate, pointed out the spec goes even further: you can copy tool parameters into headers for custom routing.

This is a big deal because agent governance has been bolted on from the outside. Cloudflare's Agent Tracing and Azure API Management's AI Gateway layer sit on top of the protocol as separate control planes. This release shoves metadata into the transport layer, so the systems infrastructure teams already run can read it natively.

The Human-in-the-Loop Gets Clunkier (or Simpler, Depending on Your View)

Elicitation also got split apart. Server-initiated requests used to require keeping a stream open. Now they use multiple round trips: the server returns input_required, the client collects the answer, then retries the call. Approval goes from one persistent connection to two separate requests. That's easier to deploy, but it means waiting for a human response no longer lives inside a single call.

Authentication got tighter too. Dynamic client registration is deprecated and slated for removal after summer 2027. The spec now uses RFC 9207 for issuer identification, and clients must send the canonical server URI as an RFC 8707 resource so tokens are only accepted by that audience.

The Community Reaction: Two Camps, Same Observation

Over on Hacker News, the reaction was sharply divided, but not about whether statelessness is an improvement. Everyone seems to agree it is. The real fight is about what this change reveals about MCP's origin.

One camp says this confirms the protocol never should have been stateful in the first place. Commenter drdexebtjl put it bluntly:

In hindsight, stateful MCP was obviously a mistake. This effectively turns MCP into another REST API endpoint, and you get to use the same infrastructure you already built for REST APIs—load balancers, API gateways, progressive rollouts, etc.

Commenter pjmlp called it a lesson the industry keeps relearning, harking back to Sun RPC: stateless servers are always better, and you only go stateful when you absolutely have to. Commenter luciana1u was even more blunt:

We invented a stateful protocol, found state hard to scale, stripped it out, and ended up with "just send a POST request." The REST crowd has been smugly waiting for this for 20 years.

Commenter bloppe framed it structurally: MCP is now basically a REST-like API, plus a spec that OpenAPI already provides, plus authorization at the framework level. Only the third part is genuinely new.

The defenders don't deny the similarity—they just disagree with the conclusion. Commenter lexicality pointed out that MCP is really just JSON-RPC, and what was actually invented is a set of conventions that models have been trained to use. Commenter vidarh summed it up most concisely:

The core advantage of MCP is that it's a standard backed by AI providers, and because of that, people have a strong incentive to actually implement it.

What the Implementers Say

People building on MCP came to a similar conclusion from a different direction. David Cramer, co-founder and CPO at Sentry, has been publicly critical of MCP in the past. After this release, he told Cloudflare that it fixed the messy authentication and tool handling. His take: "Agents only become useful when the underlying plumbing stops being the whole story."

Another thread asked an even more basic question: do agents even need a protocol, or can they just get shell access to normal CLI tools? Commenter firasd pushed back, noting that the CLI stance assumes the user is a developer at a laptop with a shell open in their coding environment. That's a tiny slice of the real use cases, which mostly come from mobile apps, web chats, and embedded components.

Adoption Is Exploding, but Money Isn't Flowing to Servers

There's no dispute about MCP's adoption numbers. Anthropic reports the MCP SDKs now see over 400 million monthly downloads, up threefold this year. But whether that adoption translates into actual server usage is another question.

A consulting firm's post on r/AI_Agents described auditing a client's server and finding 61 tool calls over three months—58 of them from the client's own engineers. The post's argument: teams confuse "an agent can access this" with "an agent will want to access this." The author, who disclosed that MCP work makes up a big chunk of their consulting revenue, drew a conclusion that echoes this release:

Money is flowing to gateways, registries, and auth layers, not to the servers themselves.

Migration Path for Teams Already in Production

For teams already running MCP in production, the migration is real work. Servers that relied on protocol sessions, server-to-client requests, or standalone streams can run a stateless route alongside the existing stateful session routing, migrate features over, drain active sessions, and remove the old path within the deprecation window. The spec, along with updated TypeScript, Python, Go, and C# SDKs, is available now.

The question that remains is whether this change makes MCP more useful or just more familiar. The protocol is now easier to run at scale, but it's also harder to see what makes it special. Maybe the answer is that its real value was never the protocol itself—it's the network effect of being the standard that every major AI provider supports. And that's a pretty solid foundation, even if it looks a lot like the REST APIs we've been running for decades.