The Model Context Protocol's July 28, 2026 release candidate removes the session handshake that tied clients to server-side context. Protocol metadata travels with each request instead. For MCP services behind load balancers or running on serverless infrastructure, that could remove a substantial amount of session-management work.

The change is still a release candidate as of August 24. Its direction is clear, though: a server instance should be able to handle a request without remembering an earlier exchange with that client. Applications will still have state, but the protocol won't require a separate session store just to keep requests working.

How sessions complicated deployment

The session model described in the 2025-11-25 release began with an initialize handshake. The client and server exchanged capabilities, and an Mcp-Session-Id header associated later requests with the resulting session. When that session lived in one server process, subsequent requests needed to reach that process or retrieve its state from shared storage.

That arrangement was manageable for a single-user desktop tool connected to a local server. A service running across multiple instances had more work to do. Load balancers needed session affinity, often called sticky sessions, to route a client back to the same instance. Alternatively, instances could consult a shared store such as Redis to reconstruct session context.

Either approach added operational work. Rolling deployments needed to drain connections or risk disrupting in-flight tool calls. New instances couldn't simply take over an existing session without access to its context. Long-lived sessions also complicated serverless deployments intended to scale down to zero when idle. Session-affinity rules, distributed stores, and connection-aware health checks became part of keeping the service available.

GitHub's MCP server provides a concrete example. According to Google's engineering account of the stateless updates, it used Redis to persist session state between requests, adding a database write and read to every tool call. The account says GitHub removed that session storage after adopting the stateless approach. Those operations served the protocol's session model rather than the tool's application work.

What changes in the request flow

A series of Specification Enhancement Proposals, or SEPs, supports the redesign. In the July 28 release candidate, SEP-2575 and SEP-2567 remove the initialize/initialized handshake. Protocol version, client information, and capabilities move into a _meta field sent on every request.

A new server/discover method lets a client retrieve server capabilities when needed. Discovery no longer depends on establishing a persistent channel and keeping the results inside a protocol session.

SEP-2260 and SEP-2322 address communication in the other direction. Previously, servers could hold server-sent event, or SSE, streams open to send requests back to clients. The new approach returns InputRequiredResult objects directly. The client then initiates the follow-up request. An interaction may take several round trips, but each step fits the standard HTTP request-and-response model.

Other proposals address routing, caching, and tracing:

  • SEP-2243 adds an Mcp-Method header so proxies and gateways can route requests without inspecting their bodies.
  • SEP-2549 introduces ttlMs fields for cacheable tool and resource responses, allowing clients to avoid redundant calls across distributed instances.
  • SEP-414 standardizes trace context propagation so distributed tracing can follow work across the request chain.

The deployment benefit is that any suitably configured instance can handle a request without recovering a protocol session. That supports round-robin load balancing, serverless functions that scale down when idle, and replacement of instances without preserving their session context.

Removing protocol sessions doesn't guarantee that every rollout will be invisible to clients. An in-flight request can still be interrupted, and application dependencies still matter. It does remove one reason for maintaining session affinity or a shared Redis layer. Where session-store operations sit on the request path, removing them also eliminates their latency and an availability dependency.

Application state still needs a home

An agent that reads a file, modifies it, runs tests, and commits changes still needs context across those steps. A stateless protocol doesn't make that context disappear.

The proposed pattern is explicit handle-passing. A tool returns an identifier for a resource or operation, and the agent includes that identifier in later tool arguments. The server no longer needs to infer the relevant context from an earlier request in the same protocol session. Systems already passing resource handles between tool calls are using this pattern.

There is a cost. Tool calls become more verbose, and prompts and schemas need to make the required identifiers clear. The agent must preserve and pass the right handle rather than rely on context held invisibly by the server. Repeating too much information can also consume the model's context window without helping it complete the task.

The benefit is easier inspection. Explicit identifiers can appear in logged tool arguments and traces, alongside the protocol metadata carried in _meta. That makes it easier to reconstruct which resource a call addressed without first examining a separate session store. Replay and auditing become more practical when the inputs are visible, although the application still needs to retain whatever data those handles refer to.

Client identity moves toward metadata documents

The identity changes accompany the stateless redesign. Dynamic Client Registration, the flow in which a client sends a registration request to an authorization server and receives credentials, is deprecated under the described approach.

The replacement is Client ID Metadata Documents, or CIMD. A client's client_id is an HTTPS URL pointing to a JSON document that describes it. The authorization server fetches that document when needed.

A public MCP client, such as a coding agent, pipeline runner, or specialized tool, can publish client-metadata.json at a URL under its control and use that URL as its client identifier. The discovery pattern resembles OpenID Connect's well-known metadata documents. It is intended to fit existing OAuth infrastructure, though authorization servers still need support for the approach.

The roadmap published August 22 identifies Demonstrating Proof of Possession, or DPoP, and Workload Identity Federation as further work. DPoP binds tokens to a client's private key, preventing a stolen token alone from being replayed by another client.

Workload Identity Federation through ID-JAG grants is aimed at cloud-native agents running as service accounts in Kubernetes or managed cloud environments. The goal is authentication without API keys. That would give autonomous agents an identity model tied to their execution environment rather than a separately distributed key.

Long-running tasks are the next area of work

The stateless redesign addresses synchronous calls over ordinary HTTP infrastructure. Work that lasts longer than one request-and-response cycle needs additional support.

As of August 24, Tasks, SEP-2663, is an extension implemented and shipping in some servers, rather than part of the core specification. The roadmap makes its maturation into the core a priority.

The planned direction includes server-initiated events through webhooks and channels, reducing the need for clients to poll status endpoints until a job finishes. It also includes HTTP streaming for results delivered over time, plus steering and cancellation while work is running. These are roadmap items, not capabilities established by removing the session handshake.

The roadmap also identifies a unified HTTP-native transport, specifically Streamable HTTP over stdio for local servers. The aim is to use the same transport model for a cloud endpoint and a local process. If that work reaches a future specification, clients could need fewer separate code paths for local and remote servers.

What migration requires

Stateless operation is a sensible target for deployments carrying infrastructure solely to preserve MCP sessions. Getting there requires changes on both sides of the connection. A migration review should cover:

  • Code that reads, stores, or depends on the Mcp-Session-Id header.
  • Server-side in-memory session context that must become explicit application state.
  • Client startup logic built around initialize/initialized, including metadata that now belongs on each request.
  • Capability handling that assumes discovery happened once and remains valid for the life of a session.
  • Server-to-client interactions that need to use InputRequiredResult and client-initiated follow-ups.
  • Session-affinity rules, connection-draining behavior, and shared stores that may become unnecessary after migration.

Tool schemas also deserve attention. They need to show which handles a call returns and which later calls require them. Passing compact identifiers is preferable to repeatedly copying large amounts of context, provided those identifiers give the application enough information to retrieve the right state.

The DEV Community migration guide offers a starting point alongside the release candidate. Migration requires separating application state that must remain from protocol session machinery that can be removed. Discovery, multi-step tool calls, and instance replacement need testing before that machinery is retired.