MCP goes stateless on July 28. Here's what breaks and what gets cheaper.

The Model Context Protocol's 2026-07-28 specification publishes in three days, and it is the largest revision the protocol has seen since its original release. The release candidate has been public since May 21, but the discussion around it — on Hacker News, in MCP server repos, across every AI-adjacent corner of the internet this week — has noticeably accelerated as the deadline approaches. If you operate an MCP server, embed one in an agent, or proxy MCP traffic through a gateway, something in this update will hit you. The window to plan ahead is closing.

What "stateless" actually means here

Prior to this spec, every MCP connection began with a handshake: the client sent an initialize request, the server responded with its capabilities and agreed on a protocol version, and subsequent requests were tied to that session via an Mcp-Session-Id header. This made sessions first-class citizens of the protocol — and it made infrastructure annoying. A server cluster needed sticky sessions or a shared session store so that any request could land on the instance that still held the client's context.

The 2026-07-28 spec eliminates all of that at the protocol layer. SEP-2567 removes the Mcp-Session-Id header entirely. There is no more session. Every request is now self-contained: client metadata, capabilities, and protocol version travel in the _meta field on every request, not in a handshake that the server has to remember. At the infrastructure level, this means a remote MCP server can now run behind a plain round-robin load balancer and route traffic by the new Mcp-Method header without deep packet inspection or affinity rules.

The practical cost savings are real. Anyone who currently runs MCP servers on a managed container platform and pays for a Redis or Memcached session store to make the stateful protocol work at scale can remove that dependency. Horizontal scaling becomes straightforward rather than load-balancer-dependent.

What actually breaks

Two things break immediately on July 28 — not deprecated, not "please migrate eventually," but removed:

• The initialize / initialized handshake is gone (SEP-2575). The protocol version no longer flows through a startup exchange. It lives in _meta on every request. If you call initialize on a server that has updated its SDK, you will get an error. The replacement for capability discovery is server/discover. Client libraries will need to be updated; if you are managing your own MCP client code rather than relying on the official TypeScript or Python SDKs, this is a manual migration.
• tasks/list is removed outright. The Tasks feature, which manages long-running operations, has been rebuilt around task handles rather than session-bound objects. tasks/list no longer exists in the spec. If you poll for task status through that endpoint, you need a new approach before Tuesday.

Beyond those two, the spec mandates two new HTTP headers that were optional or absent before. Infrastructure that proxies MCP traffic and pattern-matches on headers needs to account for these. Several GitHub issues in popular MCP gateway projects this week are tracking exactly this migration.

What's deprecated but not gone yet

SEP-2577 formally deprecates Sampling, Roots, and Logging with a twelve-month removal window. Deprecated in the MCP spec means the features remain fully functional and spec-compliant until mid-2027 — but new implementations should not build on them, and existing ones should plan to move off.

Of the three, Sampling is probably the most widely used. It is the mechanism by which an MCP server can request that the client's LLM generate text — useful for server-side prompt chaining and agentic loops that live on the server rather than in the client. Its deprecation signals that the MCP team wants these patterns handled elsewhere, likely through the new Tasks extension, which is built for long-running, structured work rather than ad-hoc model calls. If Sampling is part of your server's core flow, start planning the migration now rather than at month ten of the twelve-month window.

What's being added

The removals and deprecations get the most attention, but the spec also ships new surface area worth knowing about:

• MCP Apps is an extension for server-rendered UIs — the ability for an MCP server to push a structured interface to the client rather than just returning text or data. Early use cases center on rich tool result displays and interactive configuration flows without requiring a separate frontend.
• The Tasks extension replaces the old Tasks-as-session-object model with a handle-based system. A server initiates a long-running operation and returns a handle; the client can poll or subscribe to that handle independently of any session. This is a cleaner primitive for agent workflows that span multiple turns or require human-in-the-loop checkpoints.
• Enterprise-Managed Authorization (EMA) was promoted from experimental to stable earlier in July. It formalizes MCP servers as OAuth 2.1 resource servers and lets organizations route authorization through their existing identity provider rather than handling it ad-hoc. For anyone building MCP integrations for enterprise clients, EMA stable is the authorization story you should build to now.

SDK timing

The official TypeScript and Python SDKs maintained by the MCP team are expected to ship 2026-07-28 support within the ten-week window that opened when the RC locked on May 21 — meaning by late July or early August. If you depend on the official SDKs and don't customize the protocol layer, the migration may be as simple as updating your package version and verifying that nothing in your server code assumed session persistence. If you rolled your own client or wrapper, the initialize handshake removal and the new _meta transport are where you will spend the most time.

Third-party SDKs and gateway wrappers — of which there are now dozens — are tracking the spec at different speeds. The safest assumption is that something in your dependency tree has not updated yet, and you should test against a server that has actually implemented the RC before assuming compatibility.

The concrete checklist before Tuesday

If you run an MCP server in production, these are the things worth doing right now rather than after the spec lands:

• Grep your server code for Mcp-Session-Id and any session-store initialization. Remove or stub it — those code paths will be dead on updated clients.
• Replace any initialize call in client code with server/discover. If your client library does this automatically, verify the version you're running.
• If you call tasks/list anywhere, find the handle-based replacement in the RC and migrate it. This one is a hard removal, not a deprecation.
• Audit any use of Sampling. It works for another year, but if it is core to your product, a migration plan now is cheaper than a rushed one at month eleven.
• If you run MCP servers for enterprise customers, read the EMA stable spec. Your customers' IT teams are about to start asking whether your integration supports it.

The 2026-07-28 update makes MCP substantially simpler to operate at scale. But "simpler to operate" comes with a version boundary, and the spec is landing whether or not any individual server is ready. Three days is enough time to at least know which category you're in.