MCP goes stateless: what the 2026-07-28 spec changes on your server

The Model Context Protocol just got its largest revision since it existed, and the final spec landed on July 28 under the version string 2026-07-28. TechCrunch covered the release candidate on July 20, so nobody running a remote MCP server can claim surprise. The headline change is blunt: session IDs and the initialization handshake are gone. The core is now stateless request/response, authorization moves close to OAuth/OIDC, and the things that used to ride on the session model become versioned extensions, MCP Apps for server-rendered UI and Tasks for long-running work. Claude Code already speaks the new spec, and Anthropic's release notes say Claude and Claude Code widened support through August.

What actually changed

If you built your server on the old model, you built on a bidirectional, stateful stream. The client opened a session, the server kept state for it, and both sides could push notifications. That is how tools/list changes were announced, how progress was streamed, and how a lot of servers kept per-session context around. The 2026-07-28 revision throws that out at the core level. Every call is an independent request carrying its own credentials. Long-running behaviour goes through the Tasks extension. UI goes through MCP Apps. Neither is part of the base contract anymore.

The second change is quieter and, for cost, more important: clients now cache the tools/list response according to a ttlMs value the server returns. Under the old model a busy client re-listed tools per session. Now you decide how long the catalogue is valid, and the client stops asking.

Why operators should care

A remote MCP server can now sit behind an ordinary round-robin load balancer. No sticky sessions, no shared session store, no Redis cluster whose only job is remembering who connected where. That is the difference between an MCP integration that survives a demo and one that survives an internal platform team. It also opens serverless and edge hosting, because there are no long-lived connections to keep alive. The stateful model I described in MCP explained is now the legacy description.

Stateless MCP does not make your server simpler. It moves the state into the token and the client, then makes you prove you never needed the rest.

The trade is real. Responsibility for context and authorization shifts onto the client and onto tokens. A server that used session state to remember which user it was serving now reads that from the OAuth/OIDC credential on every request. That is more correct, and it is more work.

Migration playbook for a stateful server

• Inventory session dependencies. Grep for anything keyed on a session ID: caches, rate limits, per-user scratch state, progress maps. Each one moves into the request (token claims, explicit parameters) or into external storage keyed on the user, not the connection.
• Replace server-initiated notifications. Progress pushes and list-changed notifications have no home in a request/response core. Long jobs become Tasks: create, poll, fetch result. Anything that only existed to nudge the client can usually be deleted.
• Set ttlMs deliberately. A stable internal catalogue can advertise a long TTL. A server whose tools depend on user permissions keeps it short and computes the list from the token, not from a cached session.
• Wire OAuth/OIDC before the cutover. Run the new flow against a staging client (Claude Code is convenient, see Claude Code with MCP) and verify that a request with no session context still resolves the right identity.
• Version your extensions. Apps and Tasks are versioned. Pin what you implement and treat a bump as a contract change with a changelog entry.
• Load-test behind a dumb balancer. If the server behaves identically when every request lands on a different replica, you are done. If not, you missed a session dependency.

The honest gap

The material I have describes the protocol contract, not a migration from a production fleet. I have not seen published numbers on what tools/list caching saves at scale, and the claim that stateless servers are cheaper to run is an architectural inference, not a measured result. Servers with heavy notification patterns will find Tasks a lossy replacement, and a final spec does not mean every client has shipped it. Check your client's version before you rip out the session code.