Statelessness and Scaling

## The model this replaced Every MCP revision up to and including 2025-11-25 opened with a handshake. The client sent an `initialize` request carrying its protocol version, its capabilities and its client info; the server answered with an `InitializeResult` containing the negotiated version, the server's capabilities, its `serverInfo` and optional `instructions`; the client then sent `notifications/initialized`. Everything that followed on that connection was interpreted against the state that exchange had created. Over Streamable HTTP the server could mint an `Mcp-Session-Id` and require the client to echo it on every subsequent request; the client could send an HTTP `DELETE` to end the session, and a `404` on a request meant the session had expired and the client had to start over with a fresh `initialize`. ## What the current revision says Revision 2026-07-28 deleted that whole layer. The spec states plainly that MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities, and servers MUST NOT rely on prior requests over the same connection to establish context. It goes further and denies that a connection is a conversation at all — an open stdio subprocess is a pipe that happens to carry messages, not a session. The per-request replacement lives in `params._meta` (type `RequestMetaObject`). Two keys are required on every request: `io.modelcontextprotocol/protocolVersion` and `io.modelcontextprotocol/clientCapabilities` (an empty object `{}` is a legal capability set). `io.modelcontextprotocol/clientInfo` is optional and, like the `io.modelcontextprotocol/serverInfo` a result carries back, is self-reported and untrusted. Because capabilities travel per request, a server MUST NOT infer them from anything it saw earlier. The other half of what `initialize` used to return — `instructions`, `serverInfo`, the list of supported versions — moved to `server/discover`, a method servers MUST implement and clients MAY call. ## The concrete removals - `initialize` and `notifications/initialized`: gone. - Protocol-level sessions and the `Mcp-Session-Id` header: gone. A server that receives such a header today is receiving an unknown header with no protocol meaning. - HTTP `DELETE` as session termination: gone, along with the expired-session `404`. A modern-only server has no session to delete. - The standalone HTTP `GET` listening stream: gone, replaced by `subscriptions/listen`. - Stream resumability (`Last-Event-ID`, SSE event ids): gone. A broken stream loses the in-flight request and the client re-issues it as a new request with a new JSON-RPC id. - `ping`, and the whole `ServerRequest` union of server-initiated requests: gone (server-side input needs are expressed with `InputRequiredResult` instead). ## Where the state actually went Statelessness is a protocol property, not a claim that nothing persists. A server may absolutely own durable data — a database, a job queue, a half-built query. What changed is that continuity across calls is now **explicit and client-visible**: the server mints a handle (a workspace id, a cursor, a job id) and returns it in a tool result; the client passes it back as an ordinary argument declared in that tool's input schema. The handle is application data, not a protocol field, and the spec is emphatic that possessing one is not authentication — the threat model renamed "Session Hijacking" to "State Handle Hijacking" for exactly this reason. A related MUST reinforces the model: a server's tool, prompt and resource set MUST NOT vary per connection, though it MAY vary by the authorization presented. There is no per-connection view of the server to build up. ## Why it was done Three payoffs. First, deployment: an MCP endpoint becomes an ordinary stateless HTTP POST endpoint, so any node behind a load balancer can serve any request without session affinity, and scale-in or a rolling deploy costs at most the in-flight requests. Second, latency and simplicity: a one-shot `tools/call` no longer needs a two-round-trip handshake before it can do anything, which matters for serverless and edge deployments where a warm session was never guaranteed. Third, honesty: connection-scoped state was quietly load-bearing in implementations, and making the state explicit as handles put it where both the host and the user can see it. ## What it means in practice Building a client, you stamp `_meta` on every outgoing request rather than once at startup. Building a server, you assume nothing about who is calling beyond what this request carries — its `_meta` and its credential — and you store anything you need to remember in a place every node can reach. Reading old code or old blog posts, treat any mention of `initialize`, `Mcp-Session-Id` or `Last-Event-ID` as an artifact of the 2025-11-25-and-earlier era; a server that still speaks that way is a **Legacy**-era server, and a modern-only client cannot talk to it.