The Model Context Protocol’s stateless rewrite is no longer a release candidate: version 2026-07-28 became the final specification on July 28, 2026, locking in the biggest architectural change in the protocol’s two-year history. The release candidate published on May 21 had already announced the headline move — removing the session-state handshake so MCP servers no longer require sticky routing — but the final release adds mechanisms that were not settled in May, formalizes a deprecation policy that protects existing integrations, and graduates three experimental features into an official extensions framework. Anthropic says MCP has now passed 400 million monthly SDK downloads, a 4x increase over the year, with more than 950 servers listed in Claude’s own connectors directory.
The practical question for anyone building or discovering MCP servers is not whether the change is real — both the official specification blog and independent press coverage confirm the July 28 date and the substance of the changes — but what shifted since the RC, and whether the tools people rely on to find and evaluate servers have kept pace. They mostly have not, and that gap itself is worth reporting: as verified directly on its own documentation page on July 30, 2026, the Official MCP Registry — the spec’s own canonical metadata index — is still labeled a preview product two days after the protocol it catalogs went final.
Glama remains the strongest overall pick for hand-evaluating MCP servers, with the deepest metadata and an in-browser sandbox. MCPfinder is the best agent-native option, and notably one of the few discovery tools structurally unaffected by the transport-layer rewrite, since its own discovery calls run over local stdio rather than the HTTP session mechanism the new spec replaces. Below, we break down what actually changed since May, which pieces of the ecosystem’s own tooling haven’t caught up, and how the six leading discovery, hosting and verification tools stack up against the finalized spec.
What actually changed since the May release candidate
The RC locked the headline change back in May: MCP moves from a bidirectional, session-based protocol to a stateless request/response core, so a server no longer needs to track a persistent Mcp-Session-Id across a client’s lifetime and can run cleanly behind a standard load balancer. The final release adds three mechanisms that were not part of that May announcement. Client ID Metadata Documents (CIMD) replace Dynamic Client Registration for authentication, binding a client’s credentials to the authorization server that actually issued them — paired with a new RFC 9207 issuer-validation requirement, this closes a class of OAuth mixup attack that DCR alone did not prevent. Multi Round-Trip Requests (MRTR) let a client and server exchange several related calls without holding a bidirectional stream open the entire time. And two new HTTP headers, Mcp-Method and Mcp-Name, let infrastructure route MCP traffic based on the method and target server without parsing the JSON-RPC envelope itself — a small detail that matters a great deal once you’re running MCP behind commodity load-balancing infrastructure rather than a single local process.
Governance also changed in a way that protects existing deployments rather than exposing them: the final spec introduces a formal Specification Feature Lifecycle and Deprecation Policy that guarantees a minimum 12-month window between any feature’s deprecation and its actual removal. That answers a real concern the RC period raised — that a protocol moving this fast could break integrations on short notice — with an explicit, published commitment instead.
Three extensions graduate, not just ship
Tasks, MCP Apps and Enterprise Managed Authorization (EMA) are now official, independently versioned extensions rather than experimental additions bolted onto the core spec. Tasks — support for long-running operations that survive a crash or restart — moves from a blocking request pattern to a durable, asynchronous one. MCP Apps lets a server render interactive UI inside a sandboxed iframe on the client side. EMA is squarely aimed at the enterprise buyers who have been the fastest adopters: it lets a company centralize MCP server access control through its existing identity provider rather than managing credentials server by server. Anthropic named Figma, Intuit, Netlify, PostHog, Xero and Zoom as ecosystem partners that built alongside the new spec ahead of its release — a concrete signal that the enterprise features were not designed in a vacuum.
The ecosystem’s own registry hasn’t caught up — and that’s a useful data point
The most quotable fact in this transition is not in any press release: the Official MCP Registry, the vendor-neutral, namespace-authenticated metadata index that directories like Glama, PulseMCP and MCPfinder build on, is still labeled a preview product on its own documentation page as of July 30, 2026 — two full days after the specification it catalogs became final. Its maintainers still warn that breaking changes or data resets may occur before general availability. That is not a criticism of the registry’s engineering; preview-to-GA timelines for infrastructure projects routinely lag a headline spec release. But it is a genuinely useful thing to know before assuming “the spec is final” means every piece of official tooling around it shipped in lockstep. In practice, this changes little for most developers, who already consume the registry indirectly through community directories rather than querying it directly — but it is a reminder that “final” describes the protocol document, not necessarily every system built to implement it.
Why agent-native discovery is structurally insulated from the rewrite
The July 28 changes rewire how an MCP server handles sessions, authentication and routing over HTTP. They say nothing about how a discovery tool like MCPfinder operates, because MCPfinder’s own search-evaluate-install loop runs over a local stdio connection between the agent and the discovery server itself — a fundamentally different transport from the stateful HTTP sessions the spec just removed. That is worth stating plainly rather than assuming: the servers MCPfinder helps an agent find are the ones whose transport behavior changes under the new spec, but the discovery mechanism itself does not depend on the mechanism it just replaced. The practical result is that an agent using MCPfinder to search, retrieve trust metadata, and generate install configuration for Claude Desktop, Cursor, Claude Code, Cline or Windsurf continues to work exactly as it did before July 28 — while the servers it eventually installs are the ones migrating to the new stateless behavior underneath.
What to do if you maintain an MCP server or client
If you operate a server built against the RC or an earlier spec, the 12-month deprecation runway means nothing breaks today, but it is worth budgeting migration time rather than treating the runway as indefinite. If you’re choosing infrastructure to host a new server, Smithery’s hosted remote-server model is a natural fit for the stateless core specifically because a server behind a standard load balancer, with no sticky-session requirement, is exactly the deployment pattern the new spec enables. And if your job is finding and evaluating other people’s servers rather than building your own, the finalized spec changes remarkably little about which tool to use: Glama for depth and a live sandbox, MCPfinder when the one doing the searching is an agent rather than a person.