The MCP 2026-07-28 release candidate locked on May 21. It includes breaking changes from the previous 2025-11-25 release, and Anthropic has set a ten-week SDK validation window before the spec goes final.
I have been working through it. Here is the short version of what changed, what each piece is good for in production, and where I think it lands. Standard caveat: it is a release candidate, not the final spec, and the shape may still shift before final.
Stateless core
The protocol now supports stateless operation as a first-class mode. No initialize handshake, no Mcp-Session-Id header, no per-connection state to track.
The practical case I keep returning to: a customer support agent serving ten thousand concurrent users where every request can route to any server. Statefulness — every form of it — was a tax we were paying for almost no benefit at that scale. The stateless mode removes the tax.
MCP Apps in the protocol
Sandboxed, server-rendered HTML is now part of the protocol itself. This is the surface that was previously a Claude.ai-only feature and is now portable.
The pattern I would build with this first: a finance agent that flags expense anomalies and renders the approval form inline. The human approves, the agent moves on. There is no separate application to log into and nothing to context-switch through. The agent did not need a UI; the human, in this case, did.
Tasks extension (out of experimental)
Long-running operations now have a first-class shape in the protocol. An agent can kick off a six-hour data migration; the user can close the chat, walk away, and poll status from a different client tomorrow.
This is the change that unblocks the largest category of work I have been waiting on. Anything that does not fit inside the duration of a conversation — exports, migrations, training runs, backfills — now has a protocol-native answer instead of bespoke job-queue plumbing.
JSON Schema 2020-12 for tool schemas
Tool input schemas now use JSON Schema 2020-12. The mental model is the same as Zod or Pydantic, but in a language-neutral JSON dialect so the schema can travel between server and client without re-implementation.
The new capability worth noting is conditional validation. The kind of rule it now supports: a scheduling tool that requires a room_id only when meeting_type is in-person. Previously this had to live in the tool’s implementation; now it can live in the schema, which means the client can validate the call before it ever reaches the server.
OAuth 2.0 and OpenID Connect hardening
The auth story is more concrete. The case I am most interested in is enterprise MCP servers signing in against Okta — or any standard OIDC provider — without each server having to implement custom token validation. That is the line that makes MCP usable inside organizations that have a real identity stack.
Extensions framework
There is now a clean shape for protocol extensions outside the core spec. Team-specific or vendor-specific extensions can ship without waiting for a core release.
I expect most of the action over the next two quarters to happen here — in the extension layer — rather than in the core protocol. That is the right place for it.
The thing that mattered most
The change I keep coming back to is not any single feature. It is the lifecycle policy that ships with this RC: explicit deprecation windows, stability commitments for extensions, and a published cadence for protocol evolution.
My read is that this is the line that gets MCP into the production roadmaps of organizations that had “wait for MCP to stabilize” written down somewhere. The breaking change every six months pattern was the actual blocker for serious adoption. A spec with documented deprecation windows is a spec that the security team and the architecture review board can sign off on.
- Breaking changes every ~6 months
- No published deprecation window
- Extensions had no stability story
- Cadence of evolution was implicit
- Explicit deprecation windows
- Stability commitments for extensions
- Published cadence for protocol evolution
- 10-week SDK validation before any final
If your 2026 roadmap had “wait for MCP to stabilize” on it, this release candidate is worth a fresh look.
What’s your read on the RC? Anything I am under-weighting?
— Dinesh
The full release candidate is at blog.modelcontextprotocol.io.
Dinesh Bhat