stateless MCP
Also written MCP stateless, stateless MCP server, MCP 2026-07-28
Stateless MCP is the 2026-07-28 revision of the protocol, which removed the initialize handshake and the Mcp-Session-Id header. Every request carries its own protocol version, client details and capabilities in _meta, so any server instance can answer any request without remembering the one before.
What does stateless MCP mean?
Up to the 2025-11-25 revision, an MCP conversation starts with a handshake. The client sends initialize, the server answers with the protocol version and capabilities it chose, and over HTTP it may hand back an Mcp-Session-Id that every later request must carry. The server has to remember that session, which is the state.
The 2026-07-28 revision removed all of it [1]. There is no initialize, no notifications/initialized and no session header. Each request carries what the handshake used to establish, in its own _meta:
{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{"_meta":{
"io.modelcontextprotocol/protocolVersion":"2026-07-28",
"io.modelcontextprotocol/clientCapabilities":{},
"io.modelcontextprotocol/clientInfo":{"name":"my-client","version":"1.0.0"}}}}
On HTTP the version and method are also mirrored into the MCP-Protocol-Version and Mcp-Method headers, and a request whose headers disagree with its body is refused [2].
Why it matters
Because no request depends on an earlier one, any server instance can answer any request. A stateless server can sit behind a plain round-robin load balancer or run on serverless and edge platforms, with no sticky sessions and no shared session store.
Stateless describes the protocol, not your application. A tool that needs to remember something between calls can still return its own handle, such as a cart or job id, and take it back as an ordinary argument on the next call [1].
What replaced the handshake
A server on 2026-07-28 must implement server/discover, which returns the protocol versions it supports, its capabilities and who it is [1]. A client may call it first to choose a version up front, but it does not have to: it can send tools/list or tools/call straight away.
The revision also removed ping, the HTTP GET stream and SSE resumability, so a health check or a reconnect strategy built on any of those needs changing as well. The health check guide covers the replacement probe.
How many servers are stateless?
Almost none, so far. On 20 August 2026 we called the remote servers in the official MCP registry, and 694 completed a handshake. 3 of them answered on 2026-07-28. 382 answered on 2025-11-25, and the other 309 on revisions older than that (registry census).
That was three weeks after the revision was published, so the share will grow. It does mean a client that only speaks the stateless revision would have reached under 1% of the servers we called.
How do I tell which one a server speaks?
Send server/discover first. Only two answers prove the server is stateless [2][3]:
- a
resultcarryingsupportedVersions - an error with code
-32020(HeaderMismatch),-32021(MissingRequiredClientCapability) or-32022(UnsupportedProtocolVersion)
Anything else, including a plain "method not found" (-32601), means the server is on a handshake revision, and the client should fall back to initialize. Testing a server with curl has both request sets in full, and our connection test makes the same decision on every check and reports which revision answered.