The Stateless Core of MCP
Every request carries everything a server needs to answer it; nothing carries over from the request before it, not even on the same connection. Explain statelessness as a protocol invariant: every request is self-describing, and a server must not infer capabilities, version, or identity from any request that came before it on the same connection. Explain why statelessness matters operationally: any replica can answer any request, retries are safe to route anywhere, and load balancers need no stickiness. Distinguish a connection or a stdio process from a session or conversation, and state how list results relate to connection identity versus the authorization presented on a request. Design cross-request state with an explicit, opaque, server-minted handle that the client passes back as an ordinary tool argument, following the SEP-2567 pattern. Identify what 2026-07-28 removed to make statelessness the default, and name what replaced each removed piece. Before 2026-07-28, opening a connection to an MCP server meant sending an initialize request. That request negotiated a protocol version, exchanged capabilities, and recorded client and server identity, and the result was held as session state for as long as the connection lasted. Every later request on that connection leaned on what the handshake had established. The server never had to repeat "which version are we speaking" or "what can this client do" because it…
The Stateless Core of MCP: Every request carries everything a server needs to answer it; nothing carries over from the request before it, not even on the same…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.