The MCP 2026-07-28 Release Candidate, Explained — Stateless Core, Tasks, MCP Apps, Auth Hardening, and 5 Changes That Matter for Japanese SaaS AEO

What happened — the RC lock and the July 28 final

On May 21, 2026, the release candidate for MCP's next spec, 2026-07-28, was locked (✅ blog.modelcontextprotocol.io). The final specification is scheduled to publish on July 28, 2026. The roughly 10-week window from RC to final is for SDK maintainers and client implementers to validate the changes against real workloads; under the SDK tier system, Tier 1 SDKs are expected to ship support within this window.

This is the largest revision since launch, delivering on the 2026 roadmap in one shot — "a stateless core that scales on ordinary HTTP infrastructure," "extensions including server-rendered UIs through MCP Apps and long-running work through the Tasks extension," and "authorization that aligns more closely with OAuth and OpenID Connect deployments." Behind it are friction points that community feedback and production telemetry kept surfacing: load-balancer incompatibility with stateful sessions, unclear task lifecycles, governance bottlenecks, and enterprise compliance gaps.

① Stateless Core — breaking up with stateful sessions

The biggest change is making the protocol core stateless. The new core runs statelessly on commodity HTTP infrastructure with no special requirements. Concretely, server-initiated requests may now only be issued while the server is actively processing a client request — and this is now required.

② Extensions framework — growing without breaking the spec

The Extensions framework lets new capabilities ship as opt-in extensions and stabilize there before, if ever, moving into the specification. That keeps the core thin and stable while experimental features get validated in production. MCP Apps and Tasks are the first major extensions to ride on this framework.

③ Tasks extension — long-running work, done safely

The Tasks extension reshapes long-running work around the stateless model. A server can answer tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel.

// Conceptual: tools/call returns a task handle
client → tools/call          → server
server → { "task": "t_123" }   (returns a handle immediately)
client → tasks/get  t_123    → "running"
client → tasks/get  t_123    → "completed" + result
// cancel with tasks/cancel t_123 if needed

Tasks shipped as an experimental core feature in 2025-11-25, but production use surfaced enough redesign that the right home for it turned out to be an extension rather than the specification. It's a healthy feedback loop in action: something that entered the core gets moved to an extension based on field experience.

④ Auth hardening — moving toward OAuth/OIDC

The RC includes authorization that aligns more closely with OAuth and OpenID Connect deployments. It answers the enterprise-compliance-gap friction point and meaningfully advances MCP's security posture. Integration with existing identity providers and SSO stacks gets easier, giving enterprises a foundation to put agents into production with confidence.

⑤ Deprecation policy — 12 months of predictability

Every feature gets an Active, Deprecated, and Removed lifecycle, with at least twelve months between deprecation and the earliest possible removal. It's an unglamorous but crucial change that reduces the fear of the spec breaking without warning and gives vendors the predictability to invest in MCP support on a plan.

Implications for Japanese SaaS AEO — the KanseiLink view

From the vantage of KanseiLink's measured data across 225+ services, this spec revision is largely a net positive that lifts Japanese SaaS agent-readiness (AEO).

FAQ

Q1. When does MCP spec 2026-07-28 become final?

The release candidate was locked on May 21, 2026, and the final spec is scheduled to publish on July 28, 2026. The roughly 10-week window in between is for SDK maintainers and client implementers to validate, and Tier 1 SDKs are expected to ship support within it.

Q2. Do existing MCP servers need to be rebuilt?

Thanks to the deprecation policy, even deprecated features carry at least a 12-month grace period. Stateful implementations are worth planning a migration to the stateless core, but rather than an immediate full rewrite, the sensible path is to move in stages while watching SDK support ship.

Q3. Why did Tasks move from core to an extension?

Tasks shipped as an experimental core feature in 2025-11-25, but production use surfaced enough redesign that the right home for it turned out to be an extension rather than the specification. It follows the Extensions framework's philosophy: stabilize in an extension, then move into the core only if warranted.

Q4. What should Japanese SaaS tackle first?

If you're already on OAuth, alignment with the auth hardening is relatively easy. Services with long-running workflows (year-end adjustment, monthly close) get the most from the Tasks extension. Start by understanding your current success rate and auth method (e.g., via KanseiLink), then plan a migration to the stateless core.