Model Context Protocol Drops Sessions: What the New Stateless MCP Spec Means

What MCP Is and Why Sessions Existed

The Model Context Protocol is the open standard that connects AI agents—coding assistants, autonomous workflow tools, chatbots—to external services like code repositories, databases, and APIs. Anthropic introduced it in late 2024. By mid-2026, OpenAI, Google DeepMind, Microsoft, AWS, and hundreds of enterprise vendors had adopted it. The Agentic AI Foundation, a Linux Foundation directed fund, now governs the spec.

Under the previous finalized specification (2025-11-25), every MCP client had to open a session before making any tool call. The server issued an Mcp-Session-Id header. Every subsequent request in that session had to carry it back.

That design created a real infrastructure problem. The session ID pinned each client to the server instance that issued it. Horizontal scaling required either sticky load balancer routing or a shared session store like Redis so any instance could look up state created by another. Neither is cheap to operate at scale.

What the New Spec Actually Changes

Two Specification Enhancement Proposals define the core shift. SEP-2575 removes the initialize/initialized handshake. SEP-2567 removes the Mcp-Session-Id header and the protocol-level session entirely.

What replaces them: the protocol version, client identity, and client capabilities that used to be exchanged once at connection time now travel in a _meta field on every individual request. A new server/discover method lets clients fetch server capabilities on demand.

The result is that any MCP request can land on any server instance. A remote server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer.

Stateless Protocol Does Not Mean Stateless Applications

This is the part that gets misread. Removing sessions at the protocol layer does not mean your server has to give up persistence.

Lead maintainers David Soria Parra and Den Delimarsky are explicit about this. Servers that need to carry state across multiple tool calls should do what HTTP APIs have always done: mint an explicit handle from a tool—a basket_id, a browser_id, a workflow_run_id—and have the model pass it back as an ordinary argument on later calls.

That sounds like a workaround. It is actually more powerful than what sessions allowed.

When state lives inside transport metadata, the agent cannot see it. The model cannot reason about it, compose it with handles from other tools, or pass it forward across steps in a multi-agent workflow. When state becomes an explicit tool return value, it becomes a first-class input the model can work with. Parra and Delimarsky describe this pattern as “often a more powerful” substitute for session state—not just an equivalent one.

What Else Ships in the July 28 Release

The stateless architecture is the headline, but the 2026-07-28 spec is the broadest MCP revision to date.

What GitHub’s Same-Day Support Actually Removed

GitHub announced that its GitHub MCP Server—which lets AI agents read code, search files, and interact with repositories—shipped an updated version implementing the new spec on the same day it finalized.

Three specific engineering changes were documented:

1. Redis session storage removed. Database writes on initialize are gone. Database reads are eliminated from every individual call.
2. Deep packet inspection no longer required. The new spec’s mandatory HTTP headers expose enough information for logging and secret scanning without parsing every request body.
3. Elicitation updated to support the multi-round-trip request model, with backward compatibility for older clients maintained through a Go SDK wrapper.

GitHub also confirmed that all Tier 1 SDKs have preserved backward compatibility and shipped beta support for the new spec.

What Your Migration Actually Looks Like

The scope of work depends entirely on how much your existing implementation relies on session state.

Minimal work required if:

• Your server is already effectively stateless
• You run exclusively over stdio

In these cases: remove the initialize handler, add support for the new Mcp-Method and Mcp-Name headers, and update the SDK.

More substantial work required if:

• Your server uses the session ID to look up per-client state across multiple tool calls

Here you need to migrate that state to the explicit handle pattern. Tools return a handle. Clients store it. The model passes it back as an argument on subsequent calls. Application state lives in Redis, PostgreSQL, or in-process—but it is now visible to the model.

The harder case: community SDKs outside the Tier 1 list have no guaranteed support timeline for 2026-07-28. Do not commit to a migration date until your SDK author publishes one. If you cannot migrate immediately, pinning your client SDK version and maintaining the 2025-11-25 protocol era for both client and server is the safest interim approach.

The Bigger Picture

Lead maintainer Soria Parra described the 2026-07-28 revision as containing the “most substantial changes” made to the specification “probably since adding authorization,” noting that “a lot of things that made MCP are gone.” He also said that teams keeping their SDKs current should not have much difficulty upgrading.

The spec was in release candidate form for roughly ten weeks before finalizing—enough time for SDK maintainers and implementers to test against real workloads. With a formal deprecation policy now in place (at least 12 months between deprecation and earliest possible removal) and the Extensions framework providing a structured path for new capabilities, the architecture appears designed for long-term stability rather than continued churn.

This has implications for broader agent infrastructure as teams standardize around governed, scalable tool execution.

The Practical Takeaway

The stateless MCP spec is not just an infrastructure optimization. Moving state out of hidden transport metadata and into explicit handles that the model can see, reason about, and compose is a qualitative change in what AI agents can do across multi-step tool chains.

If you maintain an MCP server, the immediate action items are clear: audit your session dependencies, check your SDK’s Tier 1 status, update your error code handling for -32002, and start thinking about your state as handles rather than server-managed context. The teams that treat this as a refactor opportunity rather than a compliance exercise will end up with agent infrastructure that is both cheaper to run and more capable by design.