- Agentic Commerce , Protocols
- 22 May, 2026
- · 10 Mins read
- ForkPoint Team
MCP 2026 Release Candidate Explained
On May 21, 2026, the Model Context Protocol (MCP) maintainers locked the release candidate for the largest specification update since the protocol launched. The final spec ships July 28, 2026, with a ten-week validation window for SDK and client teams.
If your business has invested in MCP — or is evaluating it — this release is the one that takes MCP from a fast-moving early standard to a stable foundation enterprises can commit to. This article explains what changed, why it matters commercially, and what your team should do next.
A One-Paragraph Refresher
MCP is the standard interface AI assistants use to connect to business software. Before MCP, every AI vendor needed a custom integration with every system — your CRM, catalog, ticketing tool, data warehouse. MCP collapses that into a single protocol, the same way USB-C collapsed a dozen device cables into one.
Each system exposes an MCP server. One protocol, every integration.
The AI is the client. Your system is the server. They communicate over MCP.
Why This Release Is Different
MCP’s first version shipped quickly and gained adoption faster than its authors expected. Several design choices that worked for prototypes and single-server deployments became friction at production scale. This release rewrites those choices for the realities of enterprise infrastructure: load balancers, multi-region deployments, security audits, long-running jobs, and a 12-month deprecation contract that lets buyers plan.
In short: MCP moved from an early standard worth experimenting with to a stable platform worth standardizing on.
1. Stateless Protocol Core
What changed. The previous spec required a session handshake: the client opened a session, the server issued a session ID, and every subsequent request had to return to that specific server instance. The new spec removes the handshake entirely. Each request carries the metadata the server needs in a small _meta envelope. Any server instance can handle any request.
⚠ Traffic locked to one server. Sticky session infrastructure required.
✓ Load balancer routes anywhere. Horizontal scaling. Failover by default.
Business impact. Sticky sessions are expensive. They constrain how you deploy, complicate failover, and limit horizontal scaling. Removing them means MCP servers can run behind standard load balancers, deploy across regions, and scale the way the rest of your web infrastructure already does. Lower hosting cost, simpler operations, faster failure recovery.
For workloads that genuinely need continuity (a multi-step checkout, a long-running analysis), the spec defines an explicit-handle pattern: the server returns an opaque identifier the client passes back on subsequent calls. State lives in your database — where it should — rather than in server memory.
2. First-Class Extensions Framework
What changed. Extensions are now part of the protocol, not a workaround. Each extension has a reverse-DNS identifier (com.acme.feature), an independent version, and its own maintainers. Two official extensions ship alongside the core:
- MCP Apps — servers can render real HTML interfaces inside the AI client (sandboxed, prefetched, cached). The AI is no longer limited to chat-style responses.
- Tasks — a standard for long-running work (large report generation, codebase scans, batch operations) that no longer requires holding an open connection.
Server-rendered UI inside the AI client (sandboxed iframe, prefetched, cached).
Long-running jobs with an async lifecycle — no held-open connections.
Your vertical extension. Independently versioned. Can graduate into core.
Business impact. You are no longer blocked on the core working group to add capabilities your industry needs. Verticals — commerce, healthcare, financial services — can ship extensions that codify their workflows, gather adoption, and graduate into the core spec if successful. This is how mature standards (HTTP, OAuth, USB) evolve, and it is the mechanism that lets MCP grow without breaking what already works.
3. Hardened Authorization
What changed. Six Security Enhancement Proposals (SEPs) tighten alignment with OAuth 2.0 and OpenID Connect. The most consequential:
- Servers must validate the
iss(issuer) parameter per RFC 9207, closing a known token-substitution attack class. - Clients must declare their
application_typeduring Dynamic Client Registration so servers apply the correct security policy. - Clarified rules for issuer binding, refresh tokens, scope accumulation, and
.well-knowndiscovery.
- ✓ token signature
- ✓ audience
- ✓ scope sufficient
- ✓ iss matches expected new · RFC 9207
Business impact. Enterprise security reviews are where AI integrations go to die. By aligning with the same OAuth and OIDC standards already approved by most enterprise security teams, MCP integrations now clear procurement faster. If you sell to regulated industries — finance, healthcare, government — this is the change that makes deals close.
4. Deprecation Policy and Removed Features
Three core features enter formal deprecation with a guaranteed twelve-month transition window before removal.
| Feature | What it did | Replacement |
|---|---|---|
| Roots | Indicated which “folders” the client cared about | Tool parameters, resource URIs, or server configuration |
| Sampling | Let the server request LLM generations from the client | Direct LLM provider API integration |
| Logging | Streamed log messages over the protocol | stderr for local processes; OpenTelemetry for observability |
Business impact. A published deprecation policy is what separates a research project from an industry standard. Procurement teams, CTOs, and architecture review boards need a multi-quarter horizon before they commit. The 12-month minimum gives every downstream team room to plan migrations on their own roadmap rather than scrambling against a surprise breaking change.
5. Schema and Standards Updates
A set of focused improvements that compound into a meaningfully better protocol:
- Tool schemas now support full JSON Schema 2020-12, including conditionals (
if/then/else) and composition (allOf,oneOf). Tool authors can finally express rules like “if shipping option A is selected, a phone number is required.” - Error code for missing resources moved from custom
-32002to the standard JSON-RPC-32602— generic tooling now works without MCP-specific patches. - Trace Context propagation is formally documented with fixed
_metakeys. Distributed failures are now debuggable across long chains of MCP servers. - New
Mcp-MethodandMcp-Nameheaders let load balancers and API gateways route requests without parsing the body — lower latency, lower infrastructure cost. - New response fields
ttlMsandcacheScopelet CDNs and proxies cache MCP responses correctly, with explicit lifetime and sharing semantics.
Business impact. Each of these closes a small gap that previously required custom workarounds. Collectively, they remove most of the “MCP-specific tooling” overhead — your existing API gateway, CDN, observability platform, and JSON-RPC libraries now work without adaptation. That is a real, recurring cost reduction.
6. Multi Round-Trip Requests
What changed. When a server needs additional input mid-request (a confirmation, a missing parameter, a credential), it previously held the connection open with Server-Sent Events. That pattern fails under stateless load balancing because the second message might land on a different server. The new pattern returns an InputRequiredResult containing the requests and an opaque requestState. The client gathers the responses and re-issues the call with the echoed state — any server can resume.
Server B completes work Server A started. All state in the echoed blob.
Business impact. Long-running, multi-step interactions (approvals, escalations, human-in-the-loop workflows) no longer require expensive session affinity infrastructure. Combined with the Tasks extension, this is the foundation for production-grade agentic workflows that span minutes, hours, or days.
Governance: How MCP Now Evolves
The release introduces three governance mechanisms that determine how the protocol changes going forward:
- Feature Lifecycle Policy — every feature moves through Active → Deprecated → Removed, with a minimum 12-month deprecation window. Predictable for buyers, fair to implementers.
- Extensions framework as the official on-ramp — new capabilities ship as opt-in extensions first, prove themselves, then graduate into core.
- Conformance requirements — Standards Track proposals must ship with matching scenarios in the conformance suite. The spec is now testable, not just describable.
This is the governance maturity that distinguishes a long-lived industry standard from a fast-moving project. It is the precondition for serious enterprise commitment.
Release Timeline
10-week validation window begins. SDK and client teams ship updates.
Spec frozen. Tier-1 SDKs (Python, TypeScript) ship support.
Roots, Sampling, Logging exit the core spec. 12-month window closes.
Anthropic’s Tier 1 SDKs (Python, TypeScript, and others) are expected to ship support within the validation window. Most businesses building on those SDKs will receive the upgrade as part of a routine dependency bump.
What to Do Now
If you operate an MCP server today (product catalog, CRM connector, internal data access):
- Migrate off
initialize/Mcp-Session-Idto the new_metaenvelope. - Move per-session state into your database using the explicit-handle pattern.
- Add Roots, Sampling, and Logging to your deprecation roadmap.
- Audit your OAuth implementation against the six new SEPs before your next security review.
- Upside: drop sticky-session infrastructure, scale horizontally, clear enterprise security reviews faster.
If you consume MCP servers (you build AI assistants, agents, or internal copilots):
- Upgrade to the SDK release that adopts the new spec; most migration work is handled there.
- Evaluate the new capabilities — MCP Apps for rich UI surfaces, Tasks for long-running jobs, full JSON Schema for richer tool definitions.
- Expect lower infrastructure cost and better debuggability from the new tracing and caching primitives.
If you are a commerce or enterprise leader evaluating protocols:
- MCP has crossed the line from interesting standard to production-grade infrastructure.
- The full agentic stack is now clear: MCP for tool access, A2A for agent-to-agent workflows, UCP for consumer commerce. Each layer is independently maturing. (We covered the full landscape in our executive guide to MCP and A2A.)
- The “wait and see” window has effectively closed. Competitors who began adoption during the experimental phase now have a 12-to-18-month head start on tooling, internal expertise, and integration partnerships.
Bottom Line
The 2026-07-28 release candidate is MCP’s transition from early standard to durable platform. It trades the convenience of stateful sessions for the economics of stateless infrastructure, opens the protocol to vertical extensions, hardens security to enterprise standards, and commits to a deprecation policy that allows multi-year planning.
For builders, the migration is well-scoped: upgrade the SDK, retire deprecated features over twelve months, audit OAuth. For business leaders, the signal is clearer: the protocol is no longer a moving target, and the cost of waiting now exceeds the cost of acting.
If your team is scoping MCP adoption — or revisiting an earlier implementation in light of these changes — our team can help you plan the migration, evaluate the new extension capabilities, and avoid the common pitfalls.