In MCP 2026-07-28, why is an open stdio connection to a server not a session?

## The rule, in the spec's own words Revision 2026-07-28 states that MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities, servers must not rely on prior requests over the same connection to establish context, and an open connection — such as a stdio process — is not a conversation or a session. That sentence exists because stdio makes the opposite assumption so tempting. The client spawned the process, the process lives for as long as the host wants it, and one pipe carries all traffic in order. It looks exactly like a session. It is not one, and the spec spells it out for stdio specifically because that is where implementers get it wrong. ## What a request carries on its own Every request's `params._meta` (type `RequestMetaObject`) must include `io.modelcontextprotocol/protocolVersion` and `io.modelcontextprotocol/clientCapabilities`; an empty capabilities object is legal. `io.modelcontextprotocol/clientInfo` is optional and SHOULD be sent, and results SHOULD carry `io.modelcontextprotocol/serverInfo` in `_meta`. Both info objects are self-reported and explicitly untrusted. `io.modelcontextprotocol/logLevel` is likewise per request; without it on a given request, the server must not emit `notifications/message` for it. So the unit of protocol context is the request, not the connection. There is no first message that establishes terms for the ones after it — which is why the `initialize` request and the `notifications/initialized` notification were removed in this revision, along with the `Mcp-Session-Id` header and the HTTP `DELETE` that used to terminate a session. ## What this forbids a server implementation from doing - Caching the protocol version or capabilities the first request declared and applying them to later ones. Read `_meta` each time; a conforming client sends it every time, and a client that legitimately changes its capabilities between requests must be honoured. - Treating the connection as an authenticated principal. On Streamable HTTP, authorization travels per request in the `Authorization` header with an audience-bound token; the process or socket is not the identity. On stdio, identity is whatever the launching host arranged out of band, and it still is not established by "having connected". - Keeping a "current directory", "current document", "selected project" or similar cursor that a later request implicitly uses. If a call depends on it, the call must say so in its arguments. - Assuming request N+1 follows N. Requests may interleave, and on Streamable HTTP the next one may reach a different node entirely. ## What the connection is still for Dropping sessions does not make the connection meaningless. On stdio it is the framing and lifecycle unit: newline-delimited UTF-8 JSON-RPC on stdin and stdout with no embedded newlines, `stderr` reserved for logging (a client should not read stderr output as an error signal), stdout carrying nothing but MCP messages, and shutdown performed by closing stdin, waiting, then force-terminating. The direction rule added in 2026-07-28 is also connection-level: the client must not write JSON-RPC responses to stdin and the server must not write JSON-RPC requests to stdout. Cancellation is `notifications/cancelled`. It is also the correlation unit for anything explicitly scoped to it — an in-flight request's `progressToken`, or a `subscriptions/listen` stream whose notifications are tagged with `io.modelcontextprotocol/subscriptionId`. Those are per-request or per-subscription scopes that happen to ride the connection, not connection-derived context. On stdio the client must re-send `subscriptions/listen` after a reconnect, precisely because nothing about the previous connection survives. ## Where cross-call continuity goes instead If work genuinely spans calls, the continuity is made explicit and travels in the message: values passed as ordinary tool arguments, addresses expressed as resource URIs, or a handle the server minted and returned for the client to pass back on the next call. Because such a handle is data on the wire and not a proof of identity, the spec is emphatic that possessing one must never be treated as authentication — the same authorization check runs on the request that presents it. ## Why the change was made Statelessness is what lets the deployed fleet scale and recover simply. Any node behind a load balancer can serve any request, because no node holds context another node lacks. A dropped stream loses only the in-flight request, which the client re-issues as a new request with a new JSON-RPC id — 2026-07-28 also removed SSE resumability via `Last-Event-ID`, so there is nothing to resume and nothing to reconstruct. And on stdio, a restarted subprocess is immediately usable, because there is no handshake to redo and no accumulated context to rebuild. ## The interview tell A candidate trained on pre-2026 material will describe an `initialize` handshake that negotiates a version once and a session that everything afterwards belongs to. Saying plainly that the connection is transport and the request is the unit of context, and naming which revision changed it, is the answer that lands.