MCP Goes Stateless, and Developers Ask Whether That Just Makes It an API Again
MCP's July 28, 2026 release strips away protocol sessions and stateful handshakes, moving to a fully stateless architecture with metadata pushed into HTTP headers. The shift solves real scaling problems—load balancing, autoscaling, session migration—but it also reveals what MCP actually is: a REST API with a JSON-RPC convention on top and an auth layer below. The community is split not on whether statelessness is better, but on whether the protocol needed to exist at all once you've peeled back to REST plus headers.
Transcript
Onyx Okay, so MCP finally went stateless, and the community response is basically split between 'finally, we got it right' and 'wait, did we need a protocol at all?'
Echo Yeah.
Onyx Which is kind of the tell that something structural just shifted. The spec drops protocol sessions entirely—no handshake, no Mcp-Session-Id header tracking through a single instance. Any request lands on any instance. That's a real scaling unlock.
Echo Right. The old design pinned clients to whichever instance held their session state. Autoscaling infrastructure had to preserve sessions, load balancing was basically impossible, and draining for deploys meant keeping sessions alive through migration. Stateless removes all of that friction.
Onyx And the way they did it is kind of elegant. Two mandatory headers on every request now—Mcp-Method and Mcp-Name. So a tool call shows up as Mcp-Method: tools/call and Mcp-Name: search, with the JSON-RPC payload behind it. A gateway can read those headers and route, throttle, or meter without ever parsing the body.
Echo Mm-hm.
Onyx That's the part that actually matters here. Cloudflare basically said: your existing API gateway infrastructure can now read MCP traffic using the same primitives it already applies to REST. You're not inventing new infrastructure for this—you're using what you already have.
Echo Which is why the community reaction is so interesting. One camp says stateless was always the right answer. Someone noted we invented a stateful protocol, discovered state is hard to scale, stripped it out, and arrived at 'just send a POST request.' The REST crowd has been waiting for this moment.
Onyx Okay, that's genuinely funny.
Echo And the structural critique is sharper. Once you pull off the stateful layer, MCP is a REST-like API plus a JSON-RPC convention plus harness-level authorization. The argument is only the third is genuinely new.
Onyx Right. But the defense—and I think this actually holds—is that the blessing is the whole thing. MCP gave you a standard that by virtue of being blessed by AI providers, people had strong incentives to actually implement. That's not nothing.
Echo Fair. That's real. The adoption numbers back it up—Anthropic reports four hundred million monthly SDK downloads. But whether that adoption reaches individual servers is another question entirely.
Onyx Yeah, and there's a consultant post that's kind of damning here. They audited a client's MCP server—recorded sixty-one tool calls in three months. Fifty-eight of them were from the client's own engineers. Teams treat being reachable by an agent as though it meant being wanted by one.
Echo Wow.
Onyx Right? And the author concluded that the money is flowing to the gateways and registries and auth layers rather than to the servers themselves. That's the real product story.
Echo Which makes sense. If you're an infrastructure team, you care about observability, rate limiting, and who can call what. You care about the gateway. The server is just… a thing that got annotated with metadata you can now read from headers.
Onyx So the product question becomes: does MCP the protocol matter anymore, or is it just the standard that got infrastructure teams to implement it? Because once you've got the headers and the auth boundary, you could route to a plain REST API or whatever.
Echo Someone on Hacker News pushed back on that—said most people hit agents through phone apps, web chat, embedded widgets. You can't assume shell access.
Onyx That's fair. And David Cramer from Sentry said the release cleans up auth and tools, and that agents only get useful once the plumbing stops being the whole story. Which is exactly right.
Echo Right.
Onyx But the uncomfortable part is that the plumbing that matters is the gateway, not the protocol. The protocol is the thing that justified building the gateway in the first place.
Echo Which is episode eight forty again, isn't it? Power accumulates at the routing layer, not at the edges. The gateway controls the choice, controls the audit trail, controls whether a call even gets made. The server is downstream of that.
Onyx Yeah. And now the headers are standardized enough that Cloudflare can read them on day zero. You don't need to be a special MCP-aware gateway—you're just a gateway that understands Mcp-Method and Mcp-Name. That's the lock-in move, right there.
Echo For teams actually running MCP in production, though, the migration is real work. Servers depending on protocol sessions have to run a stateless route alongside the old one, move features across, drain active sessions, and remove the legacy path during the deprecation window. That's not a free upgrade.
Onyx Right. The spec and updated SDKs are available now—TypeScript, Python, Go, C#. So teams have the tools. But you're right that if you've baked session state into your server, that's a refactor.
Echo I think the real takeaway is that the protocol works now that it's stateless. It finally maps cleanly onto existing infrastructure. But the protocol was never really the product. The product was always the gateway, the auth layer, and the fact that Anthropic blessed it.
Onyx And the consultancy data suggests most teams haven't actually built the server side yet. Adoption is real at the SDK level. At the server level… ask me in six months.
Echo Fair bet.
Onyx So we're back to the unsexy infrastructure truth: the money flows where the control is.