MCP just removed the concept of a session

If you build anything that uses the Model Context Protocol, the standard that lets an AI agent talk to outside tools, the ground moved under you on 2026-07-28. MCP shipped a new specification, and the headline change is structural, not cosmetic: the protocol is now stateless. Anthropic's own developer account called it the largest update to MCP since launch, and two independent technical write-ups, from WorkOS and The Register, corroborate both the mechanism and the scale of the change.

This is the unglamorous kind of infrastructure news that doesn't trend anywhere outside a dev feed, but it quietly changes how you'll deploy and scale MCP servers for the next year.

What actually got removed

Two things are gone entirely.

The Mcp-Session-Id header and the session it represented. Before this release, a client opened a connection, the server handed back a session ID, and every request after that had to be pinned to that same server instance. If you were running more than one server behind a load balancer, you needed sticky sessions, a shared session store, or both, just to keep track of who was talking to whom.

The initialize/initialized handshake. The two-step connection dance that used to kick off every MCP session is gone too.

The spec is direct about both changes: the session header "and the protocol-level session that came with it are also removed," and the handshake "is removed" outright. These map to two formal proposals, SEP-2567 and SEP-2575, if you want to read the actual change requests.

What replaces them

Instead of establishing a session once and leaning on it, every request now carries what it needs on its own. Client metadata travels in _meta on each call, and a new header, MCP-Protocol-Version: 2026-07-28, replaces the old session-based versioning. A new server/discover method lets a client fetch a server's capabilities on demand instead of only at connection time.

The part that matters most if you're actually building a server: state didn't disappear, it just isn't the protocol's job anymore. The spec puts it plainly: a server that needs to carry state across calls can do what HTTP APIs have always done, mint an explicit handle, a basket_id, a browser_id, whatever fits, and have the model pass it back as an ordinary argument on later calls. That's a pattern you already know from building any stateless web API. MCP just stopped pretending it needed to be different.

Why this is worth caring about

The practical payoff shows up in how you run the thing. The spec spells it out: a remote MCP server that used to need sticky sessions, a shared session store, and deep packet inspection at the gateway can now sit behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server's ttlMs allows.

That's not a small operational win. Sticky sessions and shared session stores are exactly the kind of infrastructure that's easy to get wrong under load, and they're extra moving parts you had to build and maintain just to satisfy the protocol, not because your actual tool logic needed them. Removing that requirement means a server doesn't have to remember who it was just talking to, which makes it genuinely easier to scale horizontally.

What breaks, and what to check

This is a breaking release. There's no forward compatibility with 2025-11-25 implementations without updates, so treat it as a real migration, not a drop-in upgrade.

Two specific things to check in your own code:

• If you shipped against the 2025-11-25 experimental Tasks API, you'll need to migrate to the new lifecycle. The spec covers multi-round-trip requests differently now, via InputRequiredResult (SEP-2322).
• If your client matches on the literal error code -32002, update it. The spec moved to the standard JSON-RPC code -32602 instead.

There's also a narrower change worth knowing about even if it doesn't touch you today: SEP-2260 restricts server-initiated requests to only fire during active processing, and SEP-2243 now requires Mcp-Method and Mcp-Name headers for routing.

The takeaway

If you're running an MCP server today, this is worth a real look before you assume it still works. If you're about to build one, you get to skip the session-management complexity entirely and start with the pattern this release settled on: stateless by default, explicit handles when you actually need to carry state. That's a simpler starting point than what MCP asked of builders even a few months ago, and simpler is usually the thing that actually ships.