MCP 2026-07-28 Specification Released: Major Shift to Stateless Core

iconMetaEra
Share
AI summary iconSummary
KuCoin announces a major protocol update with the release of MCP 2026-07-28, transitioning to a stateless core design. The new specification eliminates session-based interactions, lowering infrastructure costs and enhancing scalability. OAuth 2.0 and OIDC support are now integrated for enterprise authorization, alongside a formal extension framework. Developers must migrate due to breaking changes. The update also introduces new token listings, expanding trading options.
MCP is no longer just a vendor-specific plugin interface; it’s beginning to resemble a public pipeline. The pipeline will be more robust, but also less flexible.

Article author, source: 0x9999in1, ME News



TL;DR

  • On July 28, 2026, MCP released its fifth version of the specification2026-07-28, officially characterized as the largest revision since the protocol's inception. The core change is singular: the removal of sessions from the protocol layer.
  • initialize/initialized The handshake is gone,Mcp-Session-Id the request header is gone. Each request carries its own protocol version, client identity, and capability declarations within _meta. Any request can land on any instance—a simple round-robin load balancer is sufficient.
  • This is not a performance optimization; it’s an architectural mistake. Sticky sessions and shared session storage were once the most expensive part of the bill on MCP servers.
  • The state hasn't disappeared; it has been moved from the transport layer to the tool parameters, called an "explicit handle." The model can see it and therefore can manage it.
  • The interactive interface (MCP Apps) and long-running tasks (Tasks) have been officially incorporated into the versioned extension framework, ensuring the core protocol no longer bloats with new capabilities. Authentication has been aligned with real-world OAuth 2.0 and OIDC standards, and enterprise-grade managed authorization extensions have also been promoted to stable release today.
  • The cost is real: this is a breaking change. Roots, Sampling, and Logging, along with the old HTTP+SSE transport, are now deprecated, with an official transition window of at least 12 months.
  • One sentence judgment: MCP is no longer like a vendor-specific plugin interface; it’s beginning to resemble a public pipeline. Pipelines are more robust, but also less accommodating.

The two lines that were removed are the highlight of this update.

Let’s start with a counterintuitive fact.

The most important part of this update, called the "biggest overhaul in history," isn't what was added, but what was removed.

initialize and initialized have been a pair since MCP's inception in November 2024.Mcp-Session-Id This request header has been the foundation of all deployment solutions since the remote MCP went live. On July 28, both were removed together.

What does a new request look like? Very simple.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

The method name and tool name are moved to the HTTP headers. Gateways, rate limiters, and WAFs no longer need to parse the JSON payload to guess the intent of the call—just check the headers. Protocol version, client information, and capability declarations are all included in _meta and sent with the request. Want to know what capabilities the server has ahead of time? A new server/discover endpoint has been added, but it’s optional, not required.

What does this mean? It means the MCP server has finally become a regular HTTP workload.

According to Sean Roberts, Netlify’s VP of AI, it’s straightforward: the stateless core makes MCP a first-class HTTP payload, with no session management to work around. Cloudflare puts it more bluntly, saying this version lets Agent infrastructure start working like the rest of the web—stateless, cacheable, routable, and globally scalable.

Sounds like standard vendor marketing speak. But this time it’s different, because they’re talking about one specific thing: the session disappeared, so Lambda can run, Workers can run, and edge nodes can run.

Two, sticky sessions are the real ceiling on the path to scaling agents.

Why take such a harsh action?

The old model had an unavoidable physical limitation: sessions were pinned to the instance handling the handshake.

As a result, everyone is forced to do the same thing: either enable sticky sessions so the load balancer remembers which server each client should go to, or set up a shared storage system like Redis to store session states for all instances to access.

Both paths are viable, but both involve paying an invisible tax.

Sticky sessions make scaling awkward. When an instance goes offline, the sessions attached to it are dropped. Newly launched instances during traffic spikes cannot pick up existing sessions, leaving the load permanently unbalanced. Going with shared storage is more expensive—you're introducing a stateful middleware for a requirement that fundamentally just involves "remembering what the client is called," and you also need to ensure high availability for it.

It’s not a problem when it’s small, but it becomes a problem when it scales up.

Look at the numbers to understand how the scale has grown. In December 2025, on the first anniversary of MCP, the SDK was downloaded 97 million times per month. By this release in July 2026, Anthropic reported monthly downloads exceeding 400 million, with the official blog stating "close to 500 million"—a fourfold increase within the year. The cumulative downloads for both the TypeScript and Python SDKs have each surpassed the one-billion mark.

Anthropic’s own Claude connector directory now lists over 950 MCP servers. Data from the observability vendor Honeycomb better illustrates that Agents are already working in real-world scenarios: nearly 20% of their monthly interactive queries are initiated by Agents.

Four times in six months. Under this curve, any "hidden tax" in the architecture will be amplified into an obvious cost.

So the official wording is "one of the most requested features by developers." Translation: It's not that we want to change it—it's that the people running it in production can't take it anymore.

Three: The status didn't disappear—it was moved right in front of the model.

There is a misconception that must be clarified.

The protocol is stateless, but that doesn't mean your application is stateless.

The alternative specified in the specification is called an explicit handle. If your tool needs to maintain state across calls, have it return an identifier, such as basket_id, which the model can then pass as a parameter in the next call.

That sentence in the official blog is, in my opinion, the most interesting one in the entire document: they found it more effective than hiding state in the transport layer, because the model can see this handle and thus link it across tools.

Pause and consider the weight of this statement.

The previous design logic was: state is the infrastructure’s concern, and the model shouldn’t worry about it. The current logic is reversed: state is part of the model’s reasoning chain, and hiding it causes the model to make inaccurate judgments.

Hiding states makes the model dumb. This conclusion wasn't derived from architectural aesthetics, but from over a year and a half of production incidents.

The same logic extends to the server-initiated request pathway. Previously, when a tool needed to ask the user, “Confirm deletion of these 3 files?”, it relied on a persistent SSE stream to push the request back to the client. After becoming stateless, this stream is gone, replaced by Multi Round-Trip Requests, or MRTR.

The mechanism is not complex. The server returns a result type indicating "input required," along with the questions it needs to ask and a requestState. The client collects the answers, then resubmits the original call with the inputResponses and the unchanged requestState. Since everything needed to continue is contained within requestState, even if the retry lands on a different server, it can pick up right where it left off.

Supabase product lead Inian Parameshwaran said it plainly: supporting elicitation had been on their roadmap for a long time, but it wasn’t possible because Supabase MCP runs statelessly. Now, with MRTR, it’s possible—the tool can confirm costs before creating a project and ask for confirmation before deleting data.

Here, I want to highlight a point not emphasized in the official documentation but one you’ll inevitably encounter in practice:requestState is stored and returned by the client, placing it naturally outside the trust boundary. If the server treats it as trusted input and deserializes it directly, it opens a vulnerability. Signing, encrypting, and setting expiration—I believe these three practices will quickly become community standards. This is my assessment, not a requirement of the specification.

Four: Extended Framework — The Protocol Begins to Learn "Not to Gain Weight"

The second true bet is that the expansion framework has evolved from convention into institution.

Reverse DNS naming, capability negotiation via extensions mapping, independent ext-* repositories with authorized maintainers, and versioning separate from the core specification. It may sound dry, but it solves the problem all successful protocols face: the core becoming bloated.

Two extensions have now been officially endorsed.

MCP Apps allow the server to deliver interactive interfaces directly into the conversation—not just plain text or structured JSON, but full HTML interfaces running inside sandboxed iframes. Charts, forms, selectors—all are supported. The key design is that tools must declare UI templates in advance, enabling the client to prefetch them and perform security reviews before rendering anything. Operations on the interface still proceed through the standard JSON-RPC channel for tool calls.

Tasks handle the other half of the problem: long-running tasks. It has been upgraded from an experimental feature to an official extension, with its lifecycle redesigned to be stateless:tools/call returns a task handle, which the client polls using tasks/get, along with the new tasks/update and tasks/cancel.

It is worth noting that tasks/list has been removed. The reason is straightforward: without a session, the "list all tasks" operation is no longer secure, as you cannot define whose "all" is being referred to.

This extension was contributed by AWS. Swami Sivasubramanian, Vice President of Agentic AI at Amazon, said the new specification and stateless core have been integrated into Bedrock AgentCore. On the Microsoft side, Tina Schuchman, Vice President of Engineering at Foundry, stated that MCP enabled them to scale from dozens to thousands of integrations; the Foundry toolbox unifies tools through a single MCP endpoint to centralize governance, identity, and observability.

A protocol that AWS, Microsoft, Google Cloud, and Cloudflare are all using as a foundation to build upon is no longer just a plugin standard for a single company.

Five: The real pain point has never been connectivity, but identity

The official blog includes an honest admission: over the past year, licensing has been the area where they’ve spent the most time discussing with implementers.

This version adds six SEP authorizations, all unglamorous but necessary. The authorization server must return the iss parameter as specified in RFC 9207, and the client must verify it before exchanging the code—this closes a vulnerability to authorization server confusion attacks. During dynamic registration, the client must declare application_type; finally, localhost callbacks for desktop and CLI applications will no longer be arbitrarily rejected. Credentials are bound to the issuer that issued them and cannot be reused across authorization servers.

More significantly, Dynamic Client Registration (DCR) has been officially deprecated in favor of the Client ID Metadata Document (CIMD). While DCR remains functional and backward compatibility is maintained, it will be removed in future versions.

On the same day, Enterprise Managed Authorization (EMA) graduated to stable release. This may be even more significant for enterprise IT than statelessness.

In the old system, each employee had to manually authorize each server individually. Onboarding meant connecting to one service after another by hand. The security team couldn’t enforce unified policies—permissions were granted individually by each user, with no centralized control or audit trail. Worse still, work accounts and personal accounts were mixed, with no mechanism to enforce the use of enterprise identities.

EMA turns the enterprise's own identity provider into the decision-maker. Underlying this is the ID-JAG assertion issued by the IdP during single sign-on, which the client uses to obtain an access token from the MCP server's authorization server. The user never encounters any single-server consent page.

Okta is the first supported IdP, using its Cross App Access. On the client side, all Claude products and VS Code have been integrated. On the server side, Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase are already supported, with Slack in progress. Linear’s engineering lead, Tom Moor, offered a charming comment: “Log in once, and all MCP connectors are automatically configured—it’s magical.”

The magic isn't in the experience—it's in the governance. Access decisions have finally returned to the IdP dashboard, with an audit trail spanning all connectors.

But I must be complete: statelessness and EMA address identity and scale, not the entirety of Agent security. Those two numbers from Cisco’s “State of AI Security 2026” report remain stark: 83% of organizations plan to deploy Agent capabilities, yet only 29% feel prepared. Prompt injection, tool description poisoning, Agents being used as lateral movement pivots—these issues won’t disappear just because a protocol removes sessions.

The good news is thatMcp-Method and Mcp-Name are now enforced, reducing the cost of policy execution on the gateway. The specification also requires servers to reject requests with mismatched headers and body, blocking a class of routing and security misconfigurations—this represents a tangible improvement in defensive posture. But that’s as far as it goes.

Six: Cost: This is a breaking change, and the invoice has been issued.

I don't like talking only about returns without discussing the账.

This version is a breaking change. The Roots, Sampling, and Logging features are collectively deprecated. The old HTTP+SSE transport is also officially deprecated. The specification now formally establishes a feature lifecycle policy: Active → Deprecated → Removed, with each stage lasting at least 12 months.

There are also some smaller but impactful changes: the tool's input and output schema now fully supports the JSON Schema 2020-12 vocabulary, including oneOf, anyOf, and conditional keywords; furthermore, the "resource not found" error code has been changed from the custom -32002 to the standard JSON-RPC -32602. If you have -32002 hard-coded in your code, you must update it.

The area with the highest migration cost, as explicitly stated by the official team, is developers relying on session identifiers.

So it’s worth restating the timeline. The candidate release was locked on May 21, with the official release on July 28, providing a full ten weeks for SDK maintainers and client implementers to validate. All four Tier 1 SDKs (TypeScript, Python, Go, C#) supported the new version on day one, while the Rust SDK was in beta.

Ten weeks of public validation window + 12 months of deprecation transition period + standardized SEP must have corresponding test cases in the conformance test suite before finalization. Together, these three elements constitute what I consider the most professional aspect of this revision.

It is not about glossing over breaking changes or dumping them onto the community to handle alone.

The requirement for consistency is especially critical. Going forward, if you want to add new features to the standard, first write testable scenarios. This is the approach of tying "design intent" to "implementation reality"—many protocols learned this the hard way.

Interestingly, the migration also delivered positive returns. Enrico Toniato, Chief Technology Officer at Manufact, behind the open-source framework mcp-use, provided specific figures: splitting the client and server using the new SDK v2 reduced package size by approximately 83% and improved speed by 25%.

A single architecture optimization also slimmed down the package. Things like this don't happen often.

Seven: My Judgment

So, what do you think of this update?

My first impression is: this is an admission of error, and a graceful one.

The original bidirectional stateful design of MCP emerged from local scenarios: your editor connects to a server running on the same machine, establishes a handshake, and maintains a single connection—this is entirely reasonable. The problem arises when remote MCP is introduced, and this model is dragged into the cloud environment, prompting everyone to start patching it. Sticky sessions are patches, storing sessions in Redis is a patch, and maintaining a long-lived connection for elicitation is also a patch.

When there are too many patches, it’s time to rebuild the foundation. According to protocol co-inventor David Soria Parra, this version incorporates all the lessons learned over the past 18 months. Core maintainer Nick Cooper put it even better: MCP is one and a half years old and is absorbing decades of web protocol design experience to become a more mature protocol.

Second judgment: The true watershed significance of this update lies in governance, not technology.

The timeline deserves a double-check. On November 25, 2024, Anthropic open-sourced MCP. On December 9, 2025, MCP was donated to the newly established Agentic AI Foundation under the Linux Foundation, a dedicated fund initiated by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. Eight months later, the first major version was released.

A protocol invented by a single entity underwent its most painful surgery after being handed over, rather than falling into committee gridlock afterward—this itself is a validation of the effectiveness of open governance.

The shift in focus is also evident from the list of ecosystem platforms: Figma speaks about connecting design and code, Intuit talks about delivering trusted financial intelligence experiences to 100 million consumers and business customers, and Zoom discusses securely bringing meeting intelligence into AI platforms. These are not the language of developer toys—they are the language of product lines.

The third point, and the one I think is most important to say: protocol maturity comes at a cost—the cost is "no room for complaints."

Stateless, routable, cacheable, traceable. W3C Trace Context is now passed through fixed key names in _meta, providing OpenTelemetry-compatible distributed tracing out of the box. You’ve seen these terms throughout the evolution of HTTP, REST, and gRPC.

MCP is becoming a pipeline you won’t talk about—just like no one discusses how exciting TCP is today.

Is this a good thing? I think it is. Victory at the data level has never belonged to the most stunning design, but to the one that breaks the least. At the moment the session was deleted, MCP sacrificed a degree of elegance in exchange for the ability to scale horizontally behind round-robin load balancing.

Scaling agents isn’t held back by how smart the model is—it’s held back by the things no one wants to talk about: where conversations are stored, how identity is inherited, whether tasks persist after disconnection, and how many times you need to click “agree” when ten thousand employees connect to a thousand servers.

This version moves these items forward significantly.

As for excitement, the pipe isn’t responsible for providing it—it only ensures it doesn’t leak when you’re not looking.

Source citation

  1. Model Context Protocol Blog, "The 2026-07-28 Specification", July 28, 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/
  2. Model Context Protocol Blog, "Enterprise-Managed Authorization: Zero-touch OAuth for MCP", 2026. https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
  3. Claude by Anthropic, "Bringing MCP 2026-07-28 to Claude", July 28, 2026. https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
  4. MCP Servers Blog, "The 2026-07-28 MCP Specification: A Stateless, Extensible Future", 2026. https://blog.mcpservers.org/posts/mcp-spec-2026-07-28
  5. Linux Foundation, "Linux Foundation Announces the Formation of the Agentic AI Foundation", December 9, 2025. https://linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
  6. Anthropic, "Donating the Model Context Protocol and establishing the Agentic AI Foundation", December 2025. https://anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
  7. Cisco, "State of AI Security 2026", 2026. https://blogs.cisco.com/ai/cisco-state-of-ai-security-2026-report
  8. IT Home, "Largest Update Since Launch: MCP 2026-07-28 Specification Released, Transitioning to 'Stateless' Core," July 29, 2026. https://www.ithome.com/0/983/102.htm
Disclaimer: The information on this page may have been obtained from third parties and does not necessarily reflect the views or opinions of KuCoin. This content is provided for general informational purposes only, without any representation or warranty of any kind, nor shall it be construed as financial or investment advice. KuCoin shall not be liable for any errors or omissions, or for any outcomes resulting from the use of this information. Investments in digital assets can be risky. Please carefully evaluate the risks of a product and your risk tolerance based on your own financial circumstances. For more information, please refer to our Terms of Use and Risk Disclosure.