MCP is now a stateless protocol… and without sessions. The latest version of the spec (2026-07-28) confirms this major shift.
Originally, it was envisioned that MCP would become stateless by default, with stateful as a last-resort option. This coexistence model was not adopted, on the grounds that it would have significantly increased the protocol’s complexity. Clients and servers would have had to maintain separate logics, expanding the surface for bugs accordingly. As for the idea of reintroducing sessions in another form, it was also abandoned… on the basis that existing applications were already poorly implementing the concept.
Anyone who wants to continue using sessions must therefore pin their MCP server to the earlier spec version (2025-11-25). It will remain supported for at least another 12 months.
From sessionless at the protocol level…
In the stateless paradigm, every request is independent and interpretable in isolation. This promotes elasticity and reliability—at least compared with the stateful paradigm.
This latter approach involves an initial handshake that establishes a persistent state. A client session tied to the server instance that holds this state makes it impossible to use a simple stateless load balancer (such as round-robin L4/L7) without implementing mechanisms that add complexity, such as session affinity.
Regarding reliability, the stateful model implies that if the server instance managing a session fails, the state is lost. The client must then detect the failure, re-establish a connection, and renegotiate from scratch.
The stateful approach also requires implementing, on both the client and server sides, lifecycle-management logic.
The stateless model is meant to lower these entry barriers. It decouples operations that were previously handled in bulk during the handshake. In particular, protocol version negotiation and capability discovery are now performed at the level of requests, through the _meta object, with specific endpoints.
… and at the application level
Transitioning to stateless and sessionless required changes across many ancillary MCP components. For example, tasks. This alternate execution mode, useful for representing batch operations in particular, had been incorporated into the 2025-11-25 spec. With the new version, it moves out of the protocol’s core and becomes an official extension.
It was also necessary to establish an alternative to sessions for managing state at the application level. The chosen solution relies on explicit identifiers generated on the server side and passed as arguments. Several aspects needed clarification within this framework, such as the absence of a native mechanism to communicate the TTL of these identifiers or the risk of orphaned state should the context be compressed.
From stateless also for server‑side requests for additional information
Among other major changes, the 2026-07-28 spec also introduces the MRTR (Multi Round-Trip Requests) pattern as a means for servers to signal that they require additional information to process a request. Its main advantage: no need for a shared storage layer between server instances, nor a stateful load balancer.
There are also advances in the authorization aspect (the part most demanding in terms of integration). In particular, the adoption of CIMD (Client ID Metadata Documents) in place of DCR (Dynamic Client Registration), which remains supported for backward compatibility for the moment. Client credentials are now also bound to their issuer: they can no longer be reused across authorization servers.
All first‑party SDKs (TypeScript, Python, Go, C#) support the new spec. The Rust SDK also supports it, but in beta.
