MCP Just Went Stateless: The 2026-07-28 Spec Explained

The 2026-07-28 MCP specification lands July 28, and it is the largest revision to the protocol since authorization. The short version: MCP is going stateless. The initialize handshake is gone. The Mcp-Session-Id header is gone. The connection no longer remembers who you are or what your client can do — every request now carries that itself. This is a good change for anyone running a server. It is also a change that quietly moves a hard question to the center of the table: if the protocol no longer holds your context, what does?

What actually changed in the 2026-07-28 MCP spec?

The 2026-07-28 release candidate rewrites the core of the protocol around a single idea — every request is self-describing. Here is what that concretely means, straight from the spec.

The initialize/initialized handshake is removed. There is no longer a one-time negotiation at connection start where client and server agree on protocol version and capabilities. Alongside it, the Mcp-Session-Id header and protocol-level sessions are gone from the Streamable HTTP transport.

The information that used to live in that handshake now rides in a _meta field on every request — protocol version, client info, and client capabilities travel with each call. A new server/discover method lets a client fetch the server's capabilities on demand, when it needs them, rather than receiving them once at the top of a session.

List and resource-read results now carry ttlMs and cacheScope, modeled directly on HTTP Cache-Control. ttlMs is a freshness hint in milliseconds; cacheScope is public or private and controls whether shared intermediaries may cache the response. Clients can cache a tools/list response for as long as the server permits instead of re-polling.

Two routing headers arrive: Mcp-Method on every request, and Mcp-Name on tools/call, resources/read, and prompts/get. A gateway can now route on a header without parsing the JSON-RPC body.

And a set of features move or retire. Roots, Sampling, and Logging are deprecated — annotation-only, so they keep working for at least a year, but the direction is set. Tasks, which shipped as an experimental core feature, moves out to its own extension after production use surfaced enough redesign. And there's a new MCP Apps extension that lets servers ship interactive HTML interfaces hosts render in a sandboxed iframe.

What does "stateless" actually mean in practice?

Stateless does not mean your server forgets everything. It means the protocol stops being the thing that remembers.

Under the old model, a session was a live thing. The client connected, ran initialize, and the server handed back a Mcp-Session-Id. From then on, both sides carried an implicit shared understanding: this is who you are, this is your protocol version, these are your capabilities. Every subsequent request leaned on that context. The session was a small pool of state living between two endpoints.

The new model deletes that pool. Each request arrives carrying its own context in _meta — version, client identity, capabilities — so any server instance can answer it cold, with no memory of a prior request. As Microsoft's write-up on scaling MCP servers on App Service puts it, a server that previously needed sticky sessions and a shared session store can now run behind a plain round-robin load balancer.

If you have written HTTP APIs, this is familiar. Statelessness is exactly what let the web scale: any request can hit any server because the request carries everything the server needs to respond. MCP just adopted the same discipline.

Why did MCP drop the session at all?

Sessions are expensive to run at scale, and the cost falls on operators.

A stateful protocol forces sticky routing. If request two depends on state established by request one, request two has to reach the same server instance — which means session affinity in your load balancer, or a shared session store every instance reads and writes. Both are operational tax. Both are failure modes. A dropped session store, a rebalanced pod, a scaled-down instance, and the client's context evaporates mid-conversation.

The stateless rewrite pushes that state out of the transport and into places built to hold it. State keyed off Mcp-Session-Id moves to an explicit-handle pattern — a handle passed in, a handle passed out, and the actual state parked in whatever durable store you choose. The protocol stops pretending to be a database. The migration work is mostly about relocating state you were implicitly storing in the session.

That relocation is the whole story for individual servers. But it opens a different question for teams.

What does statelessness mean for a team's context?

Here is the wedge. The spec solved a transport problem: where does connection state live. It did not touch — and could not touch — a much older problem: where does your team's context live.

Those are not the same state. Connection state is the version handshake, the capability list, the per-request plumbing. Team context is the durable stuff your AI tools actually need to be useful: your architecture decisions, your naming conventions, the reason a module is structured the way it is, the thing you decided in a meeting six weeks ago that isn't written down anywhere a model can read.

That context was never in the MCP session to begin with. But the session was a comforting fiction. As long as the protocol carried some state between requests, it was easy to not think hard about where the real context lived. Statelessness removes the fiction. Every request now stands alone, self-describing, carrying its own context — which makes the absence of a shared, authoritative context source impossible to ignore.

Consider the actual shape of a team using AI today. Every developer runs their own tools — Claude, Cursor, Copilot — each pointed at its own local config. Each has a CLAUDE.md or an equivalent that drifted the day after it was written. When one engineer teaches their assistant a convention, that knowledge dies on their laptop. This is the CLAUDE.md problem: per-developer config files that fork silently until no two agents on the team share the same picture of the codebase. Context collapse. Convention drift. AI amnesia by a hundred small divergences.

A stateless protocol makes the demand explicit. If context travels with each request, something authoritative has to supply that context — the same answer, every request, every tool, every developer. The protocol is now honest that it isn't that thing.

Where should your shared context live now?

Behind a stateless protocol, you want exactly one authoritative source of truth — external, durable, and shared. This is the layer the spec's own migration advice points at without naming: state doesn't disappear, it relocates to a store built to hold it. For a team, that store is not a session cache and not a per-machine dotfile. It's a shared context layer.

That layer is a category. ContextOps is the practice of managing your team's AI context as shared infrastructure — one authoritative source of truth that every agent reads from, instead of context scattered across per-developer files. It sits behind the MCP connection, not inside it. MCP is the mechanism that delivers context to each tool on each request. ContextOps is where that context actually lives.

The distinction matters more now than a week ago. In a stateful world you could imagine the session as a kind of memory, and paper over the fact that your real context was fragmented. In a stateless world there is no session to hide behind. Either there is one source of truth your agents inherit, or there are as many versions of the truth as you have laptops. There are better and worse ways to solve AI memory, and the ones that survive the stateless shift are the ones that put context in a shared, external layer rather than a local file.

How does the shared-layer approach actually work?

The model is workspace-scoped and single-source. Your team's context — conventions, architecture, decisions, the working agreements that make a codebase legible — lives in one workspace. Every MCP-connected tool reads from that workspace. Update the context once, and every agent inherits the change on its next request. There is no per-developer copy to drift, because there is no per-developer copy.

This is what Contextium is: shared AI context infrastructure — the team-level layer behind Claude, Cursor, Copilot, and every MCP-connected tool, so every agent inherits the same source of truth from one place. MCP is how it reaches those tools; the MCP integration is the delivery mechanism, and the workspace is the source of truth.

Notice how cleanly this maps onto a stateless protocol. Stateless MCP wants an external, authoritative source that can answer any request cold. A workspace-scoped context layer is precisely that: it doesn't care which server instance handles the request, which developer's laptop it came from, or which tool is asking. The context is the same regardless. Statelessness and shared context aren't in tension — they're the two halves of the same design. The protocol got stateless so it could scale; the context layer stays authoritative so your team stays coherent. This is the same principle behind persistent context for Claude Code: the assistant is stateless between sessions, so the durable context has to live somewhere it can always reach.

What should your team do before and after July 28?

Before the date, this is mostly a server-operator checklist. If you maintain a remote MCP server, audit anything keyed off Mcp-Session-Id and move it to the explicit-handle pattern — handle in, handle out, state in a durable store. Plan to read protocol version and capabilities from _meta rather than a handshake, implement server/discover, and attach ttlMs and cacheScope to your list and read results. The deprecations of Roots, Sampling, and Logging give you a year — but the direction is set now.

After the date, the question shifts from your server to your team. The protocol is stateless, which means the burden of "what does my AI know about our codebase" no longer has even the illusion of living in the connection. It lives wherever you decide to put it — and if you don't decide, it lives in a dozen drifting local files by default. The teams that come out ahead are the ones that treat shared context as infrastructure: one workspace, one source of truth, every agent inheriting the same picture. That decision doesn't have a deadline the way the spec does. It just gets more expensive to defer the longer your context stays scattered. You can see how the shared-layer model is priced when you're ready to move context off individual laptops and into a place the whole team reads from.

Stateless MCP didn't create the shared-context problem. It just took away the last place you could pretend it was already solved.