PaPoo
cover

MCP Goes Stateless, and That Matters for Claude Builders

For anyone building with Claude or Claude Code, this MCP release is interesting because it shifts the protocol closer to the boring, useful parts of the web: stateless requests, cacheability, routing, and clearer auth rules. That sounds less flashy than “agentic workflows,” but in practice it’s the kind of change that makes real deployments less fragile.

Key Points

My Take

What strikes me is that this is a very “grown-up” protocol release. MCP started life feeling a bit like it was borrowing stateful RPC habits from a world that had not yet fully decided how agents should be deployed. This version says, pretty plainly, that the future is stateless, cacheable, and easier to wedge into normal infrastructure. I think that is the right call.

image_0002.png

The stateless core is the most important part, not the loudest one. If you build Claude integrations in production, sessions are often where things get weird: sticky load balancing, hidden transport state, and brittle failure modes that only show up under real traffic. Removing the protocol-level session and making every request self-contained should make life much easier. I’d actually want to try this first on a boring internal tool before anything ambitious, just to see whether the ops story really does get cleaner the way the release claims.

The header-based routing change also feels genuinely practical. Putting Mcp-Method and Mcp-Name into HTTP headers makes MCP look more like something API gateways can understand without playing body-parsing games. That’s not glamorous, but it’s the sort of thing enterprise teams care about immediately. If you’re using Claude in a company setting, I think this could matter more than any single “agent” feature.

MRTR is the piece I’m least certain people will appreciate until they use it. The old always-open stream model was fine in theory, but it was never the easiest fit for browser-ish, proxy-heavy, or serverless environments. A request can now pause for user input and resume with inputResponses. That feels much more aligned with how real product workflows behave. I’d be curious whether this ends up making approval flows and missing-parameter prompts feel less hacky in Claude-driven apps.

The auth changes sound less dramatic than statelessness, but they may save teams a lot of pain. The article is pretty blunt that authorization has been where implementers spend most of their integration time. I believe that. OAuth and local app redirect handling are exactly the sort of thing that turns a neat prototype into a support ticket farm. Tightening issuer validation and moving toward metadata documents feels like the protocol trying to stop people from shooting themselves in the foot.

I do think the deprecations are where some builders will grumble. Roots, Sampling, Logging, and the older HTTP+SSE transport are all on the way out, and that means migration work. But I’d rather see a protocol pick a direction than drag legacy patterns around forever. The twelve-month minimum window is sensible. It’s not painless, but it’s honest.

image_0003.webp

My one caution is that “more production-grade” can become a marketing phrase real fast. The release is clearly a serious step forward, but the actual test will be whether SDKs, servers, gateways, and auth providers all behave consistently once people start pushing this hard. I think Claude builders should be optimistic, but not lazy. Try the new stateless path, check how your caching behaves, and make sure your auth assumptions are not accidentally relying on old session semantics.

This looks like MCP moving from promising infrastructure to infrastructure that you can probably trust under load. That is a bigger deal than it sounds. For Claude and Claude Code users, it should mean cleaner integrations, easier scaling, and fewer weird transport headaches.


Reference: The 2026-07-28 Specification

同じ著者の記事