If you run AI agents that connect to business tools over MCP, the 2026-07-28 release candidate is the most significant protocol change since MCP launched in November 2024. The short version: sessions are gone, every request must be self-contained, and the sticky-routing hacks that kept your servers running are no longer the right answer.
This post unpacks exactly what changed, what breaks, what gets easier, and how a business context layer abstracts the complexity so your agents stay focused on company knowledge rather than protocol plumbing.
What the MCP Stateless Protocol Update Actually Changes
The current MCP spec requires an initialization handshake that establishes a session between client and server. That session persists for the life of the connection. As SEP-2575 — the formal proposal to make MCP stateless puts it directly: "A truly stateless protocol, where every request is self-contained and can be understood in isolation, is highly desirable for its inherent simplicity, scalability, and reliability. The current Model Context Protocol is not stateless by default."
The 2026-07-28 MCP release candidate fixes this by removing the handshake and session layer from the protocol entirely. Every HTTP request now carries everything the server needs to process it. No prior state. No session ID. No assumption that the next request lands on the same instance.
The practical effect: you can put an MCP server behind a standard load balancer without sticky sessions, shared session stores, or affinity rules. As Chanl's migration guide frames it, the old model imposed "the same problem that plagued stateful web servers in 2010" — and it was baked into every MCP SDK before this spec.
Before and After: The Key Differences
| Area | Old (stateful) MCP | New (stateless) MCP |
|---|---|---|
| Initialization | Required handshake to establish session | No handshake; each request is self-contained |
| Load balancing | Sticky sessions or shared session store required | Any standard load balancer works |
| Scaling | Horizontal scaling is operationally painful | Scale out freely; requests are routable |
| Caching | Hard — session state is opaque | Easier — requests are cacheable and traceable |
| Async work | Often hidden inside session state | Explicit via the new Tasks extension |
| Breaking change? | — | Yes — existing session-based servers need migration |
The MCP blog's release candidate post summarizes the new posture as "routable, cacheable, traceable" — three properties that matter a lot once you move beyond a single developer's laptop.
What Breaks (and What You Need to Fix)
The stateless shift is a breaking change. If your MCP server relies on the old session model — which is the default in every MCP SDK before the 2026 spec — you have real migration work ahead.
What breaks:
- Any server-side state stored in the session object is no longer automatically available between requests. If your tool implementation assumed it could read context set during initialization, that assumption is gone.
- Clients that send an
initializehandshake before tool calls will need updating. The new protocol skips that step. - Infrastructure configured with sticky-session load balancing will work, but it's now unnecessary overhead — and the spec no longer accommodates it as a design pattern.
What gets easier:
- Deploying MCP servers as stateless functions (AWS Lambda, Cloud Run, similar) becomes natural rather than awkward.
- Observability improves because each request is a complete, self-contained unit you can log, trace, and replay.
- The new Tasks extension, which graduates to a first-class extension in this release, gives async work an explicit, visible handle rather than hiding it inside session state. That's a meaningful improvement for long-running agent workflows.
Authorization also tightens. The release candidate includes authorization hardening alongside the stateless changes. If your server handles OAuth or token-based auth, review the updated spec before migrating.
What This Means for Business AI Agents Specifically
For agents doing real business work — querying CRM data, pulling Slack threads, reading deal history from HubSpot — the stateless shift has a specific implication: context that used to travel implicitly inside a session now has to travel explicitly with every request.
That sounds like more work. In practice it clarifies something that was always true: the agent needs to know what company context to bring to each call, and that context has to come from somewhere reliable.
This is where the LinkedIn analysis of the shift lands on an important point: "The way those agents connect to internal databases, APIs, and enterprise tools is about to change." Teams that built context delivery as an afterthought — stuffing things into session state, hoping the agent figures it out — will feel this change most.
Teams that treat company context as a first-class layer will find the transition cleaner. The protocol getting out of the session-management business is actually good news if your context layer is already doing that job properly.
How a Company Brain Layer Absorbs Protocol Changes
Gyld is built as the business context layer for AI, sitting between your company's data sources and the AI agents that need them. It ingests data from the apps you already use — Slack, Gmail, Notion, HubSpot, Salesforce, Google Drive, QuickBooks, and more — into a permissioned, source-cited knowledge base, then exposes that knowledge as MCP servers your agents connect to.
The MCP stateless protocol update doesn't change that value proposition — it reinforces it. Here's why:
Context is explicit by design. Gyld's MCP servers don't rely on session state to carry company knowledge. Each tool call gets the relevant context from the indexed knowledge base, fetched on demand. That's already the stateless model.
You don't maintain the protocol layer. When the MCP spec changes — and it will keep changing as the standard matures — Gyld absorbs that update. You're not patching SDK versions or rewriting initialization logic. You connect your apps once, choose what to index, set permissions, and the MCP server your agents talk to stays current.
Permissions travel with the data, not the session. The old session model could obscure who was allowed to see what. Gyld's permission model is explicit: data is indexed as private, team-level, or company-wide, and that's enforced at query time regardless of how the protocol handles sessions.
If you're evaluating how this compares to building your own RAG pipeline, the Gyld vs RAG comparison covers the tradeoffs — including why maintaining your own retrieval infrastructure means you absorb every protocol and infrastructure change yourself.
How to Think About Migration If You Run Your Own MCP Server
If you operate a custom MCP server today, here's a practical frame for the migration:
- Audit session state usage. Find every place your server reads from or writes to session state. That's your migration surface.
- Move persistent context to explicit storage. Anything that needs to survive between requests — user preferences, conversation history, business context — belongs in a database or a context layer, not the session object.
- Test behind a round-robin load balancer. If requests fail when they land on different instances, you've found state that's still leaking through.
- Adopt the Tasks extension for async work. Long-running operations that were previously hidden in session state now get explicit task handles. This is a better pattern — use it.
- Review auth flows. The authorization hardening in the 2026 RC is worth reading carefully before you ship.
The Chanl migration guide walks through the SDK-level changes in detail if you need the implementation specifics.
Key Takeaways
- The 2026-07-28 MCP release candidate makes stateless the recommended default, removing the initialization handshake and session layer from the protocol.
- This is a breaking change: session-based servers need migration, but the result is servers that scale cleanly behind standard load balancers.
- Business AI agents need explicit, reliable context delivery — the stateless shift makes that requirement visible rather than hiding it inside session state.
If you'd rather have your agents focus on answering business questions than on protocol plumbing, start building your company brain with Gyld and let the MCP layer handle itself.
Frequently asked questions
What is the MCP stateless protocol update?
The 2026-07-28 MCP release candidate removes the stateful session layer from the Model Context Protocol. Previously, MCP required an initialization handshake that established a persistent session between client and server. The new spec makes every request self-contained, so MCP servers can run behind standard load balancers without sticky routing or shared session stores.
Does the MCP stateless change break existing MCP servers?
Yes. It is a breaking change. MCP servers built with any SDK released before the 2026 spec use sessions by default. You will need to audit session state usage, move persistent context to explicit storage, and update client initialization flows. The new Tasks extension provides a better pattern for async work that previously lived in session state.
How does stateless MCP affect AI agents doing business tasks?
Context that previously traveled implicitly inside a session must now travel explicitly with each request. For agents querying business data — CRM records, Slack threads, deal history — this means the context layer needs to be reliable and explicit. Teams that already treat company context as a first-class concern will find the transition cleaner than those who relied on session state to carry business knowledge.
What is the Tasks extension introduced in the 2026 MCP spec?
The Tasks extension graduates to a first-class part of the MCP spec in the 2026-07-28 release candidate. It gives long-running or asynchronous operations an explicit, visible task handle rather than hiding them inside session state. This makes async agent workflows easier to observe, retry, and reason about.
Do I need to migrate my MCP server immediately?
The 2026-07-28 document is a release candidate, not a final spec, so there is a window before it becomes the normative standard. That said, the direction is clear and the Spec Enhancement Proposal (SEP-2575) is marked Final. Teams building new MCP servers should target stateless from the start. Existing servers should plan migration before the spec finalizes to avoid a forced, rushed update.