MCP went stateless and my infrastructure diagram got boring

The MCP spec release candidate dropped back in May, the final version ships July 28, and it deletes the single worst part of running MCP servers for real traffic. I want to be excited calmly. I cannot.

Some history for the newer readers. Remote MCP servers have been session-shaped since the beginning: the client opens a session, state accumulates, and your infrastructure inherits requirements that nothing else in your stack has. Sticky sessions at the load balancer. A shared session store once you run two replicas. That one gateway config nobody wants to touch. When I wrote about running MCP in production, the section everyone emailed me about was the deployment pain, not the protocol.

what actually changed

The RC makes the core protocol stateless. A server can now sit behind a plain round-robin load balancer, route on an Mcp-Method header, and let clients cache tools/list responses instead of re-asking every session. Your MCP server becomes, deployment-wise, a boring HTTP service. Boring is the highest compliment infrastructure can earn. The New Stack has a good rundown of the roadmap thinking if you want the committee's version.

Two extensions landed alongside. MCP Apps lets servers ship server-rendered UI, which I have not formed an opinion about yet beyond mild suspicion. Tasks handles long-running work properly, and that one I have wanted since the first time an agent tool call sat inside an HTTP timeout doing eleven minutes of honest labor.

the auth part your security team will ask about

Enterprise-Managed Authorization went stable: access to MCP servers now runs through your identity provider instead of through whatever each server improvised. Claude, Claude Code and VS Code support it on the client side; Asana, Atlassian, Canva, Figma, Linear and Supabase are live on the server side. If you spent last year writing a wrapper proxy that injected OAuth tokens into MCP traffic (I know at least three of you personally), you get to delete it. Pour one out.

what to do about it

If you run remote MCP servers: read the RC now, because the sticky infrastructure you built is about to become removable, and removable infrastructure that stays is how legacy happens. The migration is mostly deletion, which is the best kind.

If you held off on remote MCP because the ops story was a mess: that was the correct call, and the reason just expired. The stateless core plus IdP-managed auth is the shape this needed from day one.

And if your agents only talk to local MCP servers over stdio, none of this touches you, carry on. Your day will come the moment someone in a meeting says the word "centralize".

Spec finals ship July 28. My prediction, free of charge: the first wave of blog posts will celebrate statelessness, and the second wave will discover which servers were quietly depending on session state without declaring it. I have a draft titled "so where did my session go, actually" ready either way.