The Model Context Protocol 2026-07-28 specification shipped on July 28, 2026. And it is the largest rewrite since MCP launched.
The headline change is simple to state and hard to undo: the protocol core is now stateless. That means the `initialize` handshake, the `Mcp-Session-Id` header. And the session model that pinned every client to one specific server instance are gone. If you built an MCP server on the 2025-11-25 spec, your deployment logic is now legacy code. This is not a deprecation warning with a long runway; this is a transport-model rewrite that changes how requests are routed, how capabilities are negotiated, how list endpoints cache, and how authorization flows.
For small operators and indie builders, this is the moment MCP stops being a neat local-dev protocol and becomes ordinary HTTP infrastructure.
That is mostly good news. It also means you have migration work to do.
Why Stateless Matters More Than the Marketing Suggests
The old MCP spec worked like a stateful API pretending it was not one. The client connected, sent an `initialize` message, received a session identifier, and echoed that identifier on every following request. The server used the `Mcp-Session-Id` header to pin the client to whichever instance issued it.
That design is familiar. But it is and expensive: sticky sessions, a shared session store, and gateway-level body parsing to route traffic correctly.
The 2026-07-28 spec removes all of that. The changelog states: “Make MCP stateless: remove the initialize/notifications/initialized handshake.” Each request is now self-contained and can hit any server instance. In practice, an MCP server can run behind a plain round-robin load balancer with no sticky sessions and no shared session store. Routing moves to an `Mcp-Method` header, so gateways can make routing decisions from headers instead of parsing request bodies.
This is the part that matters for small businesses. You no longer need to reason about session affinity, sticky routing, or keeping a shared store warm just to expose a few tools to an AI agent. Your MCP server can sit next to your regular API on the same boring load balancer. The protocol has finally accepted that it is HTTP.
What Replaces the Session
“Sesssions, in any protocol-visible sense, are gone.” That is the migration guidance, and it is worth reading twice.
The protocol does not introduce a new session token.
Instead, it splits the old session’s responsibilities into three narrower mechanisms that stay visible in the payload: per-request capability negotiation, a small set of new headers for routing.
And an “explicit state handle” pattern for any workflow that genuinely needs cross-call state.
Protocol version and client capabilities now travel on every request inside `_meta` fields: `io.modelcontextprotocol/protocolVersion` and `io.modelcontextprotocol/clientCapabilities`.
Clients should identify themselves on each request using `io.modelcontextprotocol/clientInfo`. And servers should identify themselves in each result’s `_meta` via `io.modelcontextprotocol/serverInfo`. The list endpoints (`tools/list`, `resources/list`, `prompts/list`) no longer vary per connection. And they gain a `ttlMs` field so responses can be cached for a defined duration.
For stateful workflows, you pass explicit handles in tool arguments instead of relying on a protocol-level session. This is the “Stateless protocol, stateful applications” idea. The protocol does not pretend your multi-step workflow is stateless; it just makes you own the state explicitly. That is cleaner, but it as well means you have to redesign any tool that assumed the session would carry context across calls.
The Deprecations and Additions That Change the Shape of MCP
This rewrite is not only about removing sessions.
Three long-standing core features are deprecated: Roots, Sampling, and Logging.
Roots are replaced by Resource URIs, which is to say plain URLs. Sampling and Logging are removed from the core and may come back as extensions. If your server depended on any of these, you now need a migration plan, not a configuration tweak.
Authorization is too rewritten. The new spec aligns MCP authorization with OAuth 2.1 and OpenID Connect in ways that make it meaningfully enterprise-ready. That is a strong signal about where MCP is heading. The protocol is being positioned as load-bearing plumbing for agentic products, not as a clever hack for local LLM experiments.
At the same time, the spec introduces a formal extensions framework and promotes two extensions to first-class status: MCP Apps (server-rendered UIs) and a redesigned Tasks extension for long-running work. Optional capabilities now live in versioned extensions with their own lifecycle, following the SEP change process. This is the right move. It keeps the core small and stable while letting richer features evolve without forcing every server to adopt them.
What You Should Do This Week
If you run an MCP server in production, the first action is to check what spec version your SDK is targeting.
The GitHub MCP Server already supports the latest spec ahead of the official release, which is a good sign that the community is moving fast.
Your server may need to handle both old and new-era deployments during a transition window.
But the transport model is rewritten, so plan for real code changes, not just a version bump.
Start with the handshake. Remove any `initialize`/`notifications/initialized` logic. Strip `Mcp-Session-Id` handling from your Streamable HTTP transport. Move your routing logic to the `Mcp-Method` header. Add `_meta` fields for protocol version, client capabilities, client info, and server info. If you cache list endpoints, implement the `ttlMs` field instead of relying on connection-specific behavior.
Then audit your use of Roots, Sampling, and Logging. Replace Roots with plain URLs. Decide whether Sampling and Logging are worth reimplementing as extensions, or whether they were vanity features you can drop. If you have multi-step tools that relied on session state, refactor them to accept explicit state handles in arguments.
Finally, treat this as infrastructure maturity, not a crisis. A stateless MCP server is cheaper to run at scale and easier to reason about. The rewrite is painful because it is comprehensive. But the result is a protocol that behaves like the rest of your HTTP stack. For a one-person agency or a lean product team, that means fewer exotic operational problems and more time spent on the actual tools you are shipping.
If your MCP server is still running the 2025-11-25 session model, pull the changelog, pick one endpoint.
And rewrite it stateless this week. The rest of the migration is mostly the same pattern repeated.
