Every team that deployed a remote MCP server before July 28 ran the same quiet workaround: sticky routing. Your load balancer had to pin each client to a specific server instance, or the session would break mid-call. Enterprises kept hitting the same walls - stateful transport sessions fighting load balancers, no standardized audit trails, and authentication tied to static secrets. Most teams treated that as an infrastructure constraint. It was actually a protocol defect, and the 2026-07-28 MCP specification just removed it.
What the stateless MCP spec actually removed
The 2026-07-28 specification is the largest revision of MCP since launch. Its headline is a stateless protocol core: the initialize handshake is gone, the session ID is gone, and every request now stands on its own. That sounds like a protocol detail. The operational consequence is concrete.
Under the old protocol, a client opened a connection with an initialize handshake, got an Mcp-Session-Id, and every later request carried that session ID back. That forced sticky routing: requests had to hit the same server instance, backed by a shared session store, with deep packet inspection at the gateway.
The 2026-07-28 spec deletes all of it. There is no initialize handshake and no Mcp-Session-Id. Each request carries the protocol version and client info in _meta fields, and any instance in a load-balanced cluster can handle any request.
With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload, making it easy to host and operate one on any infrastructure that developers and organizations already use for their APIs and services. That includes serverless - which the stateful design structurally prohibited.
What breaks when you upgrade
For anyone running an MCP server in production, 2026-07-28 is more than another version number. The specification calls this revision backward-incompatible. The session identifier header that the server used to mint has been removed from the transport. The handshake performed when a connection opens is gone as well.
The two most common failure points on migration:
Session-dependent in-memory state. If you configured session affinity on a load balancer, what that configuration protected no longer exists. If you held per-session state in memory, there is nothing left to hang it on. You need to move that state to an explicit client-visible handle - a task ID, a scoped token, something the client can pass and log.
Elicitation and mid-call user interaction. Because the back-channel was removed,
ctx.elicit()andctx.session.create_message()raiseNoBackChannelErroron a modern connection. If your server asks the user mid-call, that code needs rewriting around the input-required round trip - it is the single most likely thing to break.
Four primitives are formally deprecated and still work under a 12-month minimum overlap: Roots, Sampling, Logging, and the legacy HTTP+SSE transport still function, but new implementations should use their replacements.
On the SDK side: moving to SDK v2 and speaking the new protocol are separate steps. A v2 client or server keeps speaking the 2025-era protocol by default, and serving 2026-07-28 is an explicit opt-in. The v1 and v2 packages have different names, so they can coexist in one project. The recommended path is incremental: add the v2 packages while keeping the old SDK, migrate directory by directory, then remove the v1 dependency once nothing imports it.
What the August 22 roadmap says comes next
Five weeks after the 2026-07-28 release turned remote MCP servers into ordinary HTTP workloads, MCP Core Maintainers David Soria Parra and Den Delimarsky published an updated roadmap on August 22, 2026. It does not announce a new spec version - it names what the Core Maintainers and Working Groups will spend review time on next.
Five named priorities, in plain terms:
| Priority | What it means in practice |
|---|---|
| Agentic messaging primitives | Server-initiated webhooks and channels; clients stop polling for task completion |
| HTTP-native transport unification | Local stdio servers and cloud-hosted servers behave identically |
| Agent identity | Auth flows that work without a human at a browser - DPoP, Workload Identity Federation |
| Better primitives | Tasks extension matures into the core spec; progress reporting standardized |
| SDK experience | Reduce boilerplate; close gaps between TypeScript, Python, Go, C# SDKs |
The one worth watching is agent identity. Today, auth is built around a human approving in a browser. That does not work for agent-to-agent calls or unattended cloud workloads. The roadmap targets DPoP, Workload Identity Federation, and standard token exchange - with active engagement in IETF OAuth and WIMSE standards bodies.
This is the gap that most teams do not know they have. A stateless MCP server scales horizontally. But if your agent calls another agent's MCP server without a user session in the loop, there is currently no standardized way to prove which agent made the call, carry that identity across tool boundaries, or audit it afterward. Together, the five priorities describe MCP growing from a standard tool-call envelope into infrastructure for long-running, delegated work. The roadmap does not announce that all of this is available. Some foundations shipped in the 2026-07-28 specification; other parts are extensions, open design work, or IETF drafts. Developers should take the direction seriously without treating the diagram as a compatibility promise.
Beagle in action#platform-eng, 2:47pmThe non-obvious implication for teams running agents in Slack
Most teams using MCP through a Slack-based agent - whether it is Cursor, Claude, or a teammate like Beagle - are not running MCP servers themselves. They are consuming servers that others operate. If you only use MCP servers through an agent, you do not need to change anything today. Your client and server providers have to add support first.
But if your team has built internal MCP servers - wiring your Notion workspace, your Jira instance, your internal APIs - the migration is real and it is time-bounded. The deprecated HTTP+SSE transport and session-based design get a 12-month overlap from July 28, 2026. That is not a long runway for infrastructure that teams ship and then forget about.
Specification MCP 2026-07-28 delivers on a promise to make the protocol ready to productionize agentic systems. Stateless transport, MCP Apps and Tasks extensions, hardened OAuth, and a written deprecation policy - this is no longer a lab standard, but an infrastructure layer comparable to what REST was for web APIs.
The comparison to REST is worth sitting with. REST did not feel like a foundational shift when it landed either. It felt like a cleaner API pattern. Teams that adopted it early stopped fighting their infrastructure. Teams that stayed on SOAP kept writing adapters. The stateless MCP spec is not the same magnitude of change, but the dynamic is recognizable.
Stateless MCP servers: common questions
What is a stateless MCP server?
A stateless MCP server, as defined by the 2026-07-28 specification, processes each request independently with no protocol-level session. The initialization handshake and Mcp-Session-Id header are removed. Any server instance in a load-balanced cluster can handle any request, with no sticky routing or shared session store required.
Do I need to migrate my MCP server immediately?
No - but the clock is running. The 2025-era spec remains supported under the formal deprecation policy for at least 12 months from July 28, 2026. Deprecated features (Roots, Sampling, Logging, HTTP+SSE transport) follow the same window. New server implementations should start on the 2026-07-28 spec today; existing servers should plan migration before mid-2027.
What is the biggest breaking change in MCP 2026-07-28?
The removal of the session handshake and Mcp-Session-Id header. Any server that held per-session state in memory or relied on sticky routing must be refactored. The second most common break is code that calls ctx.elicit() mid-tool-call - that back-channel no longer exists in the stateless model.
Why does agent identity matter for MCP?
Current MCP auth assumes a human approves access in a browser. That breaks for unattended scenarios - a scheduled agent, an agent calling another agent's MCP server, or a cloud workflow with no user session. The new roadmap targets DPoP tokens and Workload Identity Federation to solve this, but the work is in progress, not shipped.
Does the stateless spec change anything for teams that only consume MCP servers?
Not directly. If your agent connects to a third-party MCP server (Notion, Linear, GitHub), your provider upgrades the server and your client follows. You only need to act if you run your own MCP server or maintain custom MCP client code.