The July 28, 2026 MCP release candidate is the largest revision to the Model Context Protocol since it launched in late 2024. The headline change: MCP is now stateless at the protocol layer. No sessions, no handshake, no sticky routing. Any request can land on any server instance.
If you run MCP servers in production today, some of what you built will break. If you are evaluating MCP for your company's AI stack, the new spec changes the calculus on complexity and cost in your favor.
Here is what changed, what it breaks, and what it means for businesses using MCP to give AI agents real company context.
What "MCP stateless protocol" actually means
The original MCP spec required a session handshake. A client would connect to a specific server instance, establish a session, and all subsequent requests in that conversation had to route back to the same instance. The server held state between turns.
The 2026-07-28 release candidate removes this entirely. According to the official MCP spec blog, there is no longer a handshake or session concept at the protocol layer. Each HTTP request is self-contained. Any server instance can handle any request without knowing what came before.
As Netlify's engineering team put it: "No sticky sessions. No session store. No shared state across instances. By removing session management from the equation, an entire layer of operational complexity disappears with it."
The MCP spec repo's SEP-1442 proposal — which drove this change — framed statelessness as the default, with stateful behavior available as an opt-in extension for the cases that genuinely need it.
What the spec actually changed
The 2026-07-28 RC is not just the session removal. The full spec post lists several interconnected changes worth understanding:
No handshake or sessions. The initialize/initialized lifecycle is gone. Clients send requests directly. Servers respond without needing to know the client's prior state.
Multi Round-Trip Requests (MRTR). For tool calls that genuinely need multiple back-and-forth turns — think long-running agent tasks — the spec introduces MRTR as an explicit mechanism. This replaces the implicit statefulness that sessions provided, but does so at the application layer rather than the protocol layer.
Header-based routing. Routing context now travels in HTTP headers rather than being baked into server-side session state. Standard load balancers can make routing decisions without needing to understand MCP internals.
Cacheable list results. Tool and resource listings can now be cached. An agent does not need to re-fetch the full list of available tools on every request.
Authorization updates. OAuth flows are clarified and tightened. This matters for business deployments where MCP servers sit in front of permissioned company data.
Tasks. A new primitive for async, long-running work. Relevant for agent workflows that cannot complete within a single HTTP round-trip.
Why this is a meaningful shift for scaling
Before this spec, running MCP servers behind a load balancer required workarounds. Microsoft's Azure App Service team documented the problem directly: you had to disable ARR affinity and use stateless HTTP transport to get any real load distribution, because sticky sessions meant traffic could not spread freely across instances.
With the new spec, an MCP server is an ordinary HTTP workload. You can run it behind any standard load balancer, scale horizontally without coordination between instances, and deploy to serverless infrastructure where instances spin up and down independently. Google Cloud's engineering team confirmed this in their August 2026 writeup on scaling agent infrastructure with the stateless updates.
The Trilogy AI team described the July 28 spec as MCP's largest revision ever, noting that it resolves the core operational tension that made enterprise deployments painful: you either accepted session pinning and its scaling constraints, or you built your own workarounds.
For businesses, this translates to lower infrastructure cost and fewer failure modes. A stateless MCP server has no session store to go down, no sticky routing to misconfigure, and no instance-specific state to lose during a deployment.
What breaks and what you need to do
If you have MCP servers running against the previous spec, the session lifecycle change is a breaking one. Clients that send an initialize request expecting an initialized response will not get the expected behavior from a 2026-07-28-compliant server.
The practical migration checklist:
- Remove session initialization logic. Any code that manages session IDs, tracks per-session state, or routes requests based on session affinity needs to be refactored or removed.
- Move state to the application layer. If your tool calls genuinely need multi-turn context, use MRTR or pass context explicitly in each request rather than relying on server-side session memory.
- Update your SDK. The MCP Tier 1 SDKs (TypeScript and Python) are being updated for the RC. According to the spec blog, those SDKs are seeing close to half a billion downloads a month — the ecosystem is large enough that SDK updates will arrive quickly, but pin your version until you have tested against the new behavior.
- Review your auth flows. The OAuth changes in the RC are clarifications, not complete rewrites, but read the updated authorization section before assuming your existing flow is compliant.
- Drop ARR affinity if you are on Azure App Service. With stateless MCP, sticky session routing is no longer needed and actively hurts load distribution.
If you are starting fresh, the new spec is strictly simpler. Gravitee's team noted at MCP Dev Summit that the July spec changes make MCP servers approachable for teams without stateful infrastructure experience.
What this means for business MCP deployments specifically
Most of the coverage of this spec change focuses on the infrastructure engineering angle. The business angle is different and worth stating plainly.
MCP servers that expose company knowledge — your Slack history, your Notion docs, your CRM data, your financial records — have a different scaling profile than generic tool servers. The state that matters is not session state. It is the knowledge state: what is indexed, who has permission to see what, and whether the context is current.
The 2026-07-28 spec makes the transport layer simpler, but it does not change the hard problem for business AI: getting the right company context into the right MCP server in the first place, keeping it current as your data changes, and enforcing permissions so the AI only surfaces what a given user should see.
That is the layer where Gyld's business context MCP servers operate. Gyld ingests data from Slack, Gmail, Notion, Google Drive, HubSpot, Salesforce, QuickBooks, and more into a per-company knowledge base, then exposes that knowledge through MCP servers that any AI agent — Claude, ChatGPT, Cursor, Codex — can call. The stateless transport change in the July RC means those MCP servers can scale horizontally without session coordination, which is the right direction. The knowledge layer — what gets indexed, who sees what, and how citations attach to answers — stays consistent regardless of which server instance handles a given request.
For teams evaluating whether to build their own MCP infrastructure or use a managed company brain, the new spec lowers the build cost somewhat. But the indexing pipeline, permission model, and freshness problem are unchanged. Comparing the build-vs-buy tradeoffs is worth doing with the new spec in hand, not the old one.
The practical takeaway
- The
2026-07-28MCP release candidate makes the protocol fully stateless: no sessions, no handshake, standard HTTP routing. - Existing MCP servers that manage session state will need refactoring before they are compliant.
- New deployments get a significantly simpler operational model — standard load balancers, horizontal scaling, serverless-compatible.
- For business AI stacks, the transport simplification is real, but the knowledge layer problem — what context the MCP server actually holds, how it stays current, and who can access what — is the work that remains.
If you are building or evaluating MCP servers to give AI agents access to your company's data, start building your company brain with Gyld and connect the apps your team already uses, without standing up session infrastructure or maintaining a custom indexing pipeline.
Frequently asked questions
Does the 2026-07-28 MCP spec break all existing MCP servers?
Any server that relies on the session handshake — the initialize/initialized lifecycle — will need to be updated. Servers that were already using stateless HTTP transport as a workaround are closer to compliant, but should still be tested against the RC spec and updated SDKs before treating them as production-ready under the new version.
What is Multi Round-Trip Requests (MRTR) and when do I need it?
MRTR is the new mechanism for tool calls that require multiple back-and-forth turns between the client and server — for example, a long-running agent task that cannot resolve in a single HTTP round-trip. If your MCP tools complete in a single request, you do not need MRTR. If you were using session state to carry context across turns, MRTR is the replacement.
How does the stateless change affect MCP servers that expose permissioned company data?
The stateless transport change affects how requests are routed, not how permissions are enforced. Authorization — including OAuth flows — is still required and is clarified in the RC. Permissions need to be evaluated per-request rather than being cached in session state, which is actually more correct behavior for access control.
When will the MCP SDKs be updated for the 2026-07-28 spec?
The official MCP blog notes that the Tier 1 SDKs (TypeScript and Python) are being updated alongside the RC. Given that those SDKs are seeing close to half a billion downloads a month according to the spec announcement, the ecosystem is moving quickly. Pin your SDK version and test against the RC before upgrading in production.
Does going stateless mean MCP servers can no longer maintain any context between calls?
Statelessness is at the protocol layer, not the application layer. An MCP server can still query a knowledge base, a database, or a cache on every request — it just cannot rely on in-memory session state that persists between requests on the same server instance. Context lives in your data layer, not in the server process. For business MCP servers, this is the right architecture anyway: company knowledge should live in a durable, permissioned store, not in ephemeral server memory.