Stateless MCP for Beginners

I've been seeing news everywhere that MCP just went stateless, but I had no clue what it means. So I decided to dig into it and write a blog post about it. Stateless MCP for Beginners The Model Context Protocol (MCP) connects AI assistants to tools, databases, and external applications. In the 2026-07-28 specification revision, MCP removed protocol-level sessions and became stateless. That change makes remote MCP servers easier to operate. They can scale behind ordinary load balancers without sticky routing or a shared MCP session store. Clients can safely cache tool definitions, and agents get more control over which application resources they share. But stateless does not mean MCP servers can no longer remember anything. A browser can still have open tabs, a database transaction can still have uncommitted changes, and a shopping cart can still hold items. The difference is how the client refers to that state. Why MCP Sessions Became a Problem State is information a system remembers between requests. Imagine an MCP server that controls a web browser. An agent might call open_browser , followed by navigate , click , and take_screenshot . The server needs to know that all four actions refer to the same browser. In earlier MCP versions, the connection could provide that context. The client began with an initialize request. Under Streamable HTTP, the server could respond with an Mcp-Session-Id , which the client attached to later requests. The server could then use that ID to recover information associated with the session. This worked naturally when one client talked to one server process. It became more complicated when an MCP service ran across several machines behind a load balancer. If Server A created a session and the next request reached Server B, Server B needed some way to recover that session. Infrastructure teams typically solved this with sticky routing, which kept the client tied to Server A, or a shared database that every server could use for session lo