Why MCP Became Stateless in the 2026-07-28 Spec

Status in the 2026-07-28 spec: core

MCP became stateless in the 2026-07-28 spec so that any request can be handled by any server instance, with no memory of earlier requests. The release removed the initialize handshake and the Mcp-Session-Id header. Every request now carries its own protocol version, client identity and capabilities.

The reason was practical. Sessions made MCP servers hard to load-balance, fragile when an instance failed and inconsistent across AI apps. The maintainers chose to fix that at the protocol level, even though it meant breaking changes.

This page explains the change in plain English, using the base protocol page and the design proposals behind it, as of October 2026.

What "stateless" means in MCP

The spec's definition is short: "MCP is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream."

In practice:

• Servers "MUST NOT rely on prior requests over the same connection to establish context," such as capabilities, version or client identity.
• Servers "SHOULD NOT require that a client reuse the same connection or process."
• State that spans requests, such as long-running tasks, "MUST be referenced by an explicit identifier the client passes on each request."

The spec adds a note that surprises many developers: an open stdio process "is not a conversation or session."

Why the change was made

Two Final design proposals explain the motivation. SEP-2575, Make MCP Stateless, names three problems with the old handshake:

1. Scalability. "A simple stateless load balancer (e.g., L4/L7 round-robin) cannot be used," because requests would land on servers without the session. Operators had to use sticky sessions.
2. Resilience. If the server instance holding a session failed, "that session state is lost," and the client had to start over.
3. Complexity. Servers had to "create, manage, and eventually garbage-collect per-client session state," which the SEP calls "a common source of bugs and memory leaks."

SEP-2567, Sessionless MCP, adds a second argument. Sessions "have not converged on a consistent meaning across clients." Some clients created a session per tool call, others per app launch or per page load, and almost none resumed them. A server author "cannot predict what scope or lifetime a session will have."

The release announcement calls the stateless core "one of the most highly-requested features from developers who were eager to get better reliability and scalability for their MCP servers."

How it works now

Each request is self-describing. The client puts the version and capabilities in _meta; on HTTP, the version and method also travel in headers so gateways can route without reading the body. This example is adapted from the Streamable HTTP transport page:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "Seattle, WA" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

The rest of the protocol was rebuilt around this idea:

The changes are listed in the 2026-07-28 changelog. Our summary of what changed in the July 2026 MCP specification covers the rest of the release.

Keeping state without sessions

Stateless does not mean your server forgets everything. It means the protocol does not hold state for you. The release announcement says: "If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument."

SEP-2567 gives a shopping-cart example. Instead of a cart tied to a session, the server offers create_basket(), which returns a basket_id, and the model passes that ID to add_item(basket_id, ...). The SEP notes handles are "a tool-design pattern," not a new protocol feature.

The announcement says the maintainers "found this works better than session state hidden in the transport," because the model can see the handle and pass it between tools.

What changed across spec versions

Up to 2025-11-25, MCP was described as "a stateful session protocol." The 2025-11-25 lifecycle page required the initialize request to be "the first interaction," followed by an initialized notification.

In 2026-07-28, the versioning page calls those older versions "legacy" and says a server MAY support both eras. It includes a compatibility matrix: a new client talking to an old server fails unless the client is "dual-era," and the same goes the other way.

Common mistakes

• Using the stdio process as a session. The spec says connection or process identity is not a proxy for a conversation.
• Storing per-user data in server memory between calls. The next request may hit a different instance. Use handles and real storage.
• Assuming the tool list can change per connection. List endpoints "no longer vary per-connection" in 2026-07-28.
• Expecting a dropped stream to resume. Resumability was removed; re-send the request with a new ID.
• Thinking stateless means no login. Authorization still applies on every HTTP request. See MCP authentication and OAuth.

Next step

The trickiest part of going stateless was letting a server ask the user something mid-call. Read MCP multi-round-trip requests explained. If you need help migrating a session-based server, talk to our MCP development team.

Frequently asked questions