{"slug": "mcp-goes-stateless-what-the-2026-07-28-spec-actually-changes", "title": "MCP Goes Stateless: What the 2026-07-28 Spec Actually Changes", "summary": "The Model Context Protocol's 2026-07-28 specification makes MCP stateless by removing the handshake and session ID, allowing requests to land on any server behind a load balancer without shared session stores. The change eliminates sticky routing and Redis session stores, enabling serverless and edge deployments. Combined MCP SDK downloads have reached roughly half a billion per month, four times the start of the year.", "body_md": "The Model Context Protocol shipped its 2026-07-28 specification on July 28, dropping the handshake and session ID that made MCP a stateful, stream-holding protocol since launch\n\nEvery request now carries its own protocol version and identity, so requests can land on any server behind a plain load balancer with no shared session store required\n\nOAuth and OIDC got real hardening, tool and prompt lists became cacheable, and Tasks moved into a formal, versioned extensions framework\n\nTier 1 SDKs already support it, and combined MCP SDK downloads have crossed roughly half a billion a month, four times where they stood at the start of the year\n\nSince it launched, MCP worked like this: a client opens a connection, sends an `initialize`\n\nrequest, gets back an `initialized`\n\nresponse, and from that point on every request in the session carries an `Mcp-Session-Id`\n\nheader that ties it to that one specific handshake. The server holding that session has to remember it, which means if you were running more than one server instance behind a load balancer, that load balancer needed to route every request from the same client back to the same instance every time, or nothing worked. Anyone who has run a real MCP deployment in production knows what that requirement turns into in practice, sticky routing rules, a shared Redis session store so any instance can pick up any session, and a gateway that has to open and parse the request body just to figure out where to send it.\n\nThe 2026-07-28 spec removes that model entirely. There is no handshake, no session ID, no held-open stream that a server has to keep alive and remember. Each request now travels on its own, carrying its own protocol version, its own client identity, and its own capabilities, self-contained the way a normal HTTP request already is everywhere else on the web. That single change is why coverage of this release keeps reaching for the word stateless, and why more than one outlet called it the largest change to the spec since MCP launched. It means an MCP server can now run on genuinely serverless or edge infrastructure, spin up to handle one request, and disappear, because there is no session state anywhere for it to be responsible for remembering.\n\nFor anyone who has actually operated an MCP server at any real scale, this is the part worth paying attention to before any of the smaller feature additions, because it removes an entire category of infrastructure that existed only to work around a protocol design choice, not to serve users.\n\nIt also changes who can reasonably build one. A stateful server needs somewhere to keep that state alive between requests, which nudges you toward a long-running process, a container that stays up, something with memory that persists across a session. A stateless server needs none of that. It can be a function that wakes up, answers one self-contained request, and goes back to sleep, which is a very different cost and complexity profile for a solo developer or a small team deciding whether an integration is worth building at all. The old model quietly filtered out anyone who did not want to run and babysit a long-lived process just to expose a handful of tools to an agent.\n\nDropping session state does not mean dropping the features that state used to make possible, it means those features got rebuilt on top of stateless requests instead. The spec introduces Multi Round-Trip Requests, which replace the old pattern of a server holding a connection open to ask the client something mid-call. Instead, a tool can return a result with `resultType: \"input_required\"`\n\ndescribing what it still needs, and the client answers by retrying the original call with those answers attached in `inputResponses`\n\n. The conversation still happens, it just happens across independent, stateless requests instead of one long-held connection.\n\nRouting got a parallel fix. Requests now carry `Mcp-Method`\n\nand `Mcp-Name`\n\nHTTP headers, so a gateway or a web application firewall can make a routing or authorization decision by reading headers the way it already does for every other kind of HTTP traffic, instead of parsing a JSON body just to figure out what a request is asking for. That sounds like a small detail until you consider how much infrastructure exists purely to do body inspection for protocols that did not expose enough in their headers, and MCP had been one of them.\n\nTool, prompt, and resource list responses also picked up `ttlMs`\n\nand `cacheScope`\n\nfields, telling a client exactly how long a given list is safe to reuse before asking again. That is a plain caching contract MCP simply did not have before, and it directly cuts the redundant re-fetching that shows up in any agent that calls the same server repeatedly across a session.\n\nThat last point matters more than it looks on the page. Before this spec, a client had no reliable way to know whether a server's tool list was still accurate without asking again, so most implementations either re-fetched constantly, wasting a request every time, or cached indefinitely and risked working from a stale list if the server ever changed what it offered. A server publishing its own TTL removes the guesswork entirely, the server states its own freshness window and the client just honors it, the same basic contract that has kept HTTP caching sane for decades finally showing up in a protocol that agents lean on constantly.\n\nThe authorization changes are less flashy than the stateless rewrite but matter just as much for anyone running MCP servers behind real identity systems. Authorization servers now have to return the `iss`\n\nparameter specified in RFC 9207, and clients are required to validate it before redeeming an authorization code, closing a class of mix-up attacks between authorization servers that the previous spec left open. Client credentials are now bound to the specific authorization server that issued them, so a credential obtained from one server cannot be replayed against a different one. Desktop and CLI applications also got a real accommodation, clients can now declare their `application_type`\n\nduring registration specifically to allow localhost redirects, which is how most local developer tools actually need to handle OAuth callbacks.\n\nDynamic Client Registration, the mechanism most existing MCP clients use to register themselves with a server automatically, is formally deprecated in favor of Client ID Metadata Documents, a simpler model where a client publishes a static document describing itself instead of registering programmatically every time, though DCR keeps working during the transition so nothing breaks overnight. The same grace period applies to the original HTTP+SSE transport and to Roots, Sampling, and Logging, all deprecated with a minimum twelve month window before removal. That is a deliberate choice, and a reasonable one, a protocol with this many production deployments cannot flip a switch and expect every server and client to update in lockstep, so the spec authors built in the runway.\n\nTasks, meanwhile, graduated out of the experimental core and into a formal, versioned `io.modelcontextprotocol/tasks`\n\nextension, with a poll-based `tasks/get`\n\nand a new `tasks/update`\n\nmethod for long-running work that does not fit inside a single request-response cycle. MCP Apps and Enterprise Managed Authorization landed as extensions built on the same framework, which is itself the more durable change here, MCP now has an actual, documented path for adding capabilities without touching the core protocol every time, instead of every new feature fighting for space inside the base spec.\n\nNone of this would matter much if MCP were a niche protocol a handful of teams used. It is not. Combined SDK downloads across the ecosystem are now close to half a billion a month, a four times increase since the start of the year, with both the TypeScript and Python SDKs individually past one billion total downloads. TypeScript, Python, Go, and C# SDKs already support the 2026-07-28 spec, with a Rust SDK in beta, which means the tooling most agent builders actually reach for was ready essentially the day the spec shipped rather than trailing months behind it.\n\nThat adoption curve is exactly why the stateless rewrite is the story and not a footnote. A protocol with a hundred integrations can afford a breaking architectural change and absorb the fallout quietly. A protocol approaching half a billion monthly downloads, sitting underneath the plumbing that connects agents like Claude to the tools, files, and services they actually act on, cannot make a change like this casually. The twelve month deprecation windows, the backward-compatible DCR fallback, and the fact that four SDKs shipped support on release day all point at a spec change that was clearly built with existing production traffic in mind, not a clean-slate rewrite that expects everyone to catch up whenever they get around to it. I have written before about [the MCP servers I actually trust wiring into Claude Code](https://dev.to/blogs/lab/best-mcp-servers-for-claude-code-in-2026), and this release is the kind of change that quietly makes every one of those servers cheaper to run and easier to deploy at scale, without asking a working setup to change on day one.\n\nMCP's 2026-07-28 spec is the protocol growing up in the specific way infrastructure has to grow up once real production traffic depends on it, dropping the stateful session model that forced sticky routing and shared session stores, and replacing it with self-contained requests that any server instance can handle. The security hardening around OAuth and OIDC, the caching contract for list results, and the formal extensions framework for Tasks and Apps are all meaningful on their own, but the stateless core is the change that actually lets MCP servers run on infrastructure that was never a realistic option under the old design. With SDK support already shipped across four languages and monthly downloads near half a billion, this is not a spec change agent builders get to watch from a distance for long. If you run an MCP server today, the migration windows are generous, but the direction is not really optional.", "url": "https://wpnews.pro/news/mcp-goes-stateless-what-the-2026-07-28-spec-actually-changes", "canonical_source": "https://dev.to/raxxostudios/mcp-goes-stateless-what-the-2026-07-28-spec-actually-changes-4722", "published_at": "2026-07-30 00:01:05+00:00", "updated_at": "2026-07-30 00:30:47.030714+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-infrastructure"], "entities": ["Model Context Protocol", "MCP"], "alternates": {"html": "https://wpnews.pro/news/mcp-goes-stateless-what-the-2026-07-28-spec-actually-changes", "markdown": "https://wpnews.pro/news/mcp-goes-stateless-what-the-2026-07-28-spec-actually-changes.md", "text": "https://wpnews.pro/news/mcp-goes-stateless-what-the-2026-07-28-spec-actually-changes.txt", "jsonld": "https://wpnews.pro/news/mcp-goes-stateless-what-the-2026-07-28-spec-actually-changes.jsonld"}}