MCP Just Went Stateless: What the July 2026 Spec Update Actually Changes

TL;DR

• MCP's 2026-07-28 spec drops the initialise/initialised handshake and the session ID header. Every request now stands on its own.
• A new pattern, Multi Round-Trip Requests, replaces the old server-initiated calls that needed a permanently open connection.
• Tool and resource lists can now be cached, so a client does not have to re-fetch the same catalogue on every reconnect.
• Authorisation gets tighter: issuer validation on every token redemption, and a move away from Dynamic Client Registration toward signed client metadata documents.
• Roots, Sampling, Logging, and the old HTTP+SSE transport are deprecated, with a twelve-month window before they are removed.
• The scale of adoption behind this release, half a billion SDK downloads a month, backing from AWS, Google Cloud, Microsoft, and Cloudflare, is the real headline. MCP is no longer an early protocol. It is infrastructure.

Why a stateless core is the biggest change here

The original MCP design opened a session first, then ran calls inside it. That meant a server had to remember which client it was talking to across multiple requests, and a load balancer had to keep sending the same client to the same server instance to keep that memory intact.

The new spec removes that requirement entirely. Every request carries its own protocol version and client identity. There is no session to open or close. A server can answer a request on any instance behind a plain round-robin load balancer, because nothing about handling that request depends on what happened before it.

This does not mean an MCP server cannot keep state. If a tool genuinely needs to track something across calls, it hands back an explicit reference, and the model passes that reference into the next call itself. The state lives in the conversation, not hidden in the transport. That is a cleaner boundary: what the model can see is also what the server depends on.

The problem this solves in practice

A stateful protocol is hard to run at real scale. Sticky sessions mean you cannot freely scale server instances up or down. A dropped connection can mean a lost session and a client that has to start over. None of this is unique to MCP; it is the same tradeoff every stateful web protocol has made before it, and the same reason the wider web moved toward stateless HTTP APIs decades ago.

MCP servers are now catching up to that lesson. A stateless request can be retried, load-balanced, and cached without any special handling. That is a meaningfully easier thing to operate than a protocol that expects a long-lived connection per client.

Multi-Round-Trip Requests, in plain terms

Sometimes a tool needs something mid-call: a missing parameter, a confirmation before it does something risky, like deleting a record. The old approach handled this through server-initiated requests that needed an open, bidirectional stream sitting there waiting.

The new approach is simpler to reason about. The server responds to the original call with a status that says more input is needed, along with what it needs. The client collects that input and retries the same call with the answers attached. No stream has to stay open in between.

It is a request, then another request, not a conversation held open in the background.

Caching finally has a real answer

Before this release, a client calling tools/list had no standard way to know whether it was safe to reuse that result. Now list responses carry a cache duration and a scope. A client can hold onto a tool catalogue instead of re-fetching it on every reconnect, which also helps keep upstream prompt caches stable.

Authorisation gets a real hardening pass

This is the part worth paying closest attention to if you are already thinking about OAuth 2.1 alignment for anything you build. Three changes stand out:

• Authorisation servers must return an issuer parameter, and clients must check it before redeeming a code. This closes a class of mix-up attack where a token meant for one authorisation server gets redeemed against another.
• Client credentials are now bound to the specific issuer that minted them. No reuse across authorisation servers.
• Dynamic Client Registration is being phased out in favour of signed client metadata documents. DCR still works today, but it is on a deprecation clock.

None of this is exotic. It is the same direction OAuth 2.1 has been pushing for a while now: less implicit trust, more explicit verification at every handoff.

What changed, at a glance

What is being deprecated

Roots, Sampling, and Logging are deprecated. They keep working for at least twelve months, but new work should not depend on them. The older HTTP plus Server-Sent-Events transport is on the same clock. If you are building something new on MCP today, build it against the current primitives, not the ones headed for retirement.

The adoption number that matters more than the spec details

The spec changes are real, but the more telling detail is who is behind this release. The post carries direct backing from AWS, Google Cloud, Microsoft, Cloudflare, Figma, and several infrastructure vendors already running MCP at production scale, alongside download numbers in the hundreds of millions per month across the official SDKs. A protocol does not get authorisation hardening and a stateless rewrite because a handful of hobby projects asked for it. It gets that because production teams hit the actual limits of the old design and needed a fix.

The short version

MCP just traded a stateful, session-based design for a stateless one, added a cleaner pattern for mid-call input, made tool catalogues cacheable, and tightened authorisation in ways that track directly with where OAuth 2.1 has been heading. None of this is a cosmetic version bump. It is the protocol absorbing eighteen months of real production use into its core design.

Full details and the maintainers' own write-up are here: https://blog.modelcontextprotocol.io/posts/2026-07-28/