The biggest rewrite of the Model Context Protocol since Anthropic launched it in 2024 lands on July 28, 2026. Sessions are gone. The initialize handshake is gone. Stateful transport machinery that made cloud deployments a scaling headache is gone. If you run MCP-connected agents against business data, this affects you — whether you built your own server or rely on a managed layer.
Here is what actually changed, why it matters operationally, and what you need to do about it.
What the MCP stateless update actually changes
The 2026-07-28 release candidate is, in the words of the MCP maintainers, the largest revision of the protocol since launch. The headline change: MCP is now stateless at the protocol level.
In the original design, every MCP connection required a session. The client sent an initialize request, the server stored session state, and every subsequent call was tied to that session. That worked fine on a developer's laptop. It became a serious problem the moment anyone tried to run MCP servers in the cloud at scale.
As The Register reported, Anthropic technical staff member David Soria Parra acknowledged the team learned "hard lessons" over the past two years as laptop-bound demos were adapted for multi-client enterprise use. The stateful session model made horizontal scaling, load balancing, and failover unnecessarily difficult — every request had to hit the same server instance that held the session.
The new spec eliminates that constraint entirely.
What's removed and what's restructured
The changes fall into three categories: removals, restructuring, and new capabilities.
Removed:
- The
initializehandshake and session negotiation are gone. Clients no longer need to complete a handshake before making calls, and the GitHub MCP Server changelog notes that clients can now complete connection setup in parallel, making things faster. - Persistent session state at the transport layer is eliminated. The GitHub team specifically called out that removing Redis session writes on
initialize— and session reads on every subsequent call — made their server "snappier without users losing anything." - Several little-used features from the original spec have been cut, reducing surface area for homebrew implementations to maintain.
Restructured:
- Server-to-client requests are restructured. Previously these were awkward to route because they depended on the open session channel. The new model makes them work cleanly over standard HTTP.
- Authorization is hardened. Values that previously required deep packet inspection of request payloads can now be read from HTTP headers guaranteed to be present — a meaningful security and observability improvement.
New capabilities:
- Extensions become first-class. MCP Apps (server-rendered UIs) and the Tasks extension graduate to supported extension points rather than experimental additions.
- The protocol is now explicitly routable, cacheable, and traceable — properties that standard HTTP infrastructure already handles well, but that the stateful model actively prevented.
Why statefulness was the wrong default
The Agentic AI Foundation's analysis puts the operational scale in context: Google Cloud's MCP Toolbox for Databases has surpassed 13,000 GitHub stars and handles over 20 million tool calls across 40+ databases in a single month. At that volume, a stateful session model is not a minor inconvenience — it is an architectural bottleneck.
The core problem: stateful sessions require sticky routing. A load balancer must send every request from a given client to the same backend instance. That means you cannot freely scale horizontally, you cannot fail over transparently, and every instance must maintain in-memory (or Redis-backed) session state that is never truly shared. The Microsoft App Service team documented this explicitly: the workaround before July 28 was to use stateless HTTP transport and disable ARR affinity so the load balancer could actually spread traffic. The new spec makes that the default, not a workaround.
For businesses running agents that call MCP servers dozens or hundreds of times per session — retrieving CRM context, checking Slack history, pulling documents — the latency and reliability improvements from dropping sticky sessions are real.
What breaks for homebrew MCP implementations
The update is not backward compatible in all areas, and The Register is direct about this: teams with homebrew MCP server implementations are "facing a slog."
Specifically:
- Any server that stores session state and expects an
initializecall needs to be rewritten at the transport layer. - Any client that assumes a persistent session channel for server-to-client requests needs updating.
- Authorization flows that relied on session context rather than per-request HTTP headers need to be restructured.
The official tier-1 SDKs (Python, TypeScript, Go) have shipped beta support with backward compatibility preserved, so if you are using those SDKs your migration path is managed. The GitHub MCP Server already supports the new spec ahead of the official release, using the Go SDK. But if your team hand-rolled a transport layer or built custom session management, the work is non-trivial.
The distinction that matters: stateless protocol, stateful applications
One important nuance from the official release candidate post: the protocol going stateless does not mean your applications cannot be stateful. It means the transport layer no longer carries state. Applications can still maintain conversation context, user preferences, or workflow state — they just do it at the application layer, where it belongs, rather than baking it into the protocol connection itself.
This is the right separation of concerns. HTTP has been stateless since its inception; cookies, sessions, and application state have always been application-layer concerns. MCP is finally adopting the same model.
How a managed context layer insulates you from protocol churn
This is the practical question for operators: how much of this do you need to care about personally?
If you maintain your own MCP server infrastructure — custom transport, custom session management, custom auth — the answer is: quite a lot. You are on the hook for the migration, and the timeline is now.
If you use a managed business context layer like Gyld that exposes your company's data as MCP servers, the answer is different. The protocol migration happens at the infrastructure layer, not at your application layer. Your agents — whether running in Claude, ChatGPT, Cursor, or any other MCP-compatible client — continue to get accurate, permissioned, source-cited context from your connected apps (Slack, Gmail, Notion, HubSpot, Salesforce, Google Drive, and others) without you rewriting transport code.
This is the core argument for a managed context layer versus a hand-built RAG pipeline: protocol evolution is someone else's maintenance burden. The 2026-07-28 update is a concrete example of why that matters. MCP will continue to evolve. Anthropic has already signaled this is not the last major revision. Teams that built directly on the protocol's lower-level primitives will keep absorbing that churn.
What you should do right now
A short checklist depending on your situation:
If you use official SDK-based MCP servers (Python, TypeScript, Go):
- Update to the latest SDK beta that includes 2026-07-28 support.
- Test your existing tool calls — the SDKs preserve backward compatibility, but verify your specific usage.
- No immediate action required for production if you are not on the critical path for the July 28 release.
If you maintain a custom or homebrew MCP server:
- Audit your transport layer for session state dependencies.
- Remove
initializehandling and replace with per-request auth from HTTP headers. - Restructure any server-to-client request flows.
- Budget meaningful engineering time — this is not a one-line change.
If you use a managed MCP provider:
- Confirm with your provider that they are tracking the 2026-07-28 spec.
- Verify that their SDK version is updated before the release date.
- Focus on your agent logic, not the transport layer.
Key takeaways
- The 2026-07-28 MCP spec is the protocol's largest overhaul since launch: sessions and the
initializehandshake are removed, transport is now stateless by default, and authorization moves to HTTP headers. - This is not backward compatible for custom implementations. Official SDK users have a managed migration path; homebrew server authors face real rewrite work.
- The stateless shift makes MCP servers genuinely cloud-native: horizontally scalable, load-balancer-friendly, and cacheable without sticky routing hacks.
- Managed context layers absorb protocol churn at the infrastructure level, letting your teams focus on what agents actually do rather than how the transport works.
If you want your AI agents to understand your business — not just the protocol — start building your company brain with Gyld and let the infrastructure keep pace with the spec automatically.
Frequently asked questions
What is the MCP stateless update and when does it ship?
The 2026-07-28 MCP specification is the largest revision of the Model Context Protocol since Anthropic launched it in 2024. It removes stateful sessions and the initialize handshake from the protocol core, making MCP transport stateless by default. The release candidate is available now; the final spec ships July 28, 2026.
Does removing sessions mean my agents lose conversation memory?
No. The protocol going stateless means the transport layer no longer maintains session state — not that applications cannot be stateful. Conversation context, user state, and workflow tracking remain application-layer concerns. The change affects how MCP clients and servers connect, not what your agents remember.
Will my existing MCP tools break on July 28?
If you use official tier-1 SDKs (Python, TypeScript, Go), backward compatibility is preserved and the SDKs have already shipped beta support for the new spec. If you built a custom MCP server with hand-rolled session management or transport logic, you will need to rewrite those components — the changes are not backward compatible at the protocol level.
Why did MCP need to go stateless?
The original stateful design required sticky routing: every request from a client had to reach the same server instance that held the session. That made horizontal scaling, load balancing, and failover difficult in cloud deployments. At the scale MCP now operates — Google Cloud's MCP Toolbox alone handles over 20 million tool calls per month across 40+ databases — the stateful model was an architectural bottleneck.
How does a managed MCP layer like Gyld handle this protocol change?
Gyld manages the MCP infrastructure layer, including SDK updates and spec migrations. When the protocol updates, that work happens at the infrastructure level rather than in your codebase. Your agents continue to get permissioned, source-cited context from your connected apps — Slack, Gmail, Notion, HubSpot, Salesforce, and others — without your team absorbing the transport rewrite.