What the July 28 MCP release candidate actually restructures
The Model Context Protocol steering group cut the 2026-07-28 release candidate as the largest revision of the protocol since launch. The final specification ships on July 28 and closes the ten-week SDK-maintainer window the RC opened. Four load-bearing changes land together: a stateless HTTP core, the Tasks extension for long-running work, MCP Apps for server-rendered UI inside sandboxed iframes, and an authorization surface aligned with OAuth 2.1 and OpenID Connect deployments. A formal deprecation policy ships alongside so future revisions can evolve without breaking the deployed surface.
The operationally important reads:
- The stateless core is the real news, not the extension surface. The prior spec’s stateful-session assumption is what forced the connection-affinity workarounds every production MCP deployment ended up writing against sticky-session load balancers, sidecar session stores, or per-region single-instance servers. Stateless collapses the transport to plain HTTP with the JSON-RPC base protocol running on top; every deployment that stood up affinity plumbing to keep the prior spec running gets to delete the workaround inside the migration window.
- The Tasks extension formalizes the long-running-work pattern the market already shipped. Every serious MCP integration this year invented its own tool-call-returns-a-handle idiom because the prior spec had no answer for tool calls whose latency exceeds the HTTP timeout.
tasks/get,tasks/update, andtasks/cancelland as the standardized surface — the per-vendor idioms shipped against the gap are now legacy code inside the ten-week window. - MCP Apps (SEP-1865) puts server-rendered UI on the audit path, not the client-side hack path. Tools declare their UI templates ahead of time; hosts prefetch, cache, and security-review them; the rendered UI talks back over the same JSON-RPC surface every direct tool call runs through. Every UI-initiated action goes through the same consent-and-audit path as a tool call — the build a custom web UI to gate agent actions pattern the security team wrote gets to collapse into the spec’s own affordance.
- The authorization surface aligns with OAuth 2.1 and OIDC. The prior spec’s under-specified auth layer is what the NSA CSI on MCP security called out as the leading blocker for enterprise adoption. The RC’s alignment with the deployed IdP substrate — Okta, Azure Entra, Ping, ForgeRock — closes the gap the security team has been writing custom auth-gateway middleware against for the last two quarters.
The structural read isn’t MCP shipped a new version. It is that the protocol has crossed from experimental integration surface to production-standardized substrate — the enterprise adoption blocker cited by every 2026 MCP survey has a spec-level answer, the deprecation policy commits the steering group to a compatibility contract, and the ten-week migration window is the deadline the team’s MCP server portfolio grades against.
What the four load-bearing changes restructure for the FY27 MCP plan
The MCP server portfolio consolidates against the stateless transport. The prior spec’s session-model forced the deployment topology to either sticky-session load balancing (fragile) or single-instance-per-region (unscalable). The stateless core lets the MCP server portfolio deploy behind a standard load balancer with no session affinity, no sidecar session store, no per-region pinning. The infrastructure team that stood up the affinity plumbing during the prior spec’s era gets to retire it — the FY27 platform-simplification target the team wrote against the prior spec’s session-model becomes a delete-code refactor inside the migration window.
The Tasks extension collapses the per-vendor long-running-work idioms. Every production MCP deployment doing structured extraction on documents, running long-running searches, or triggering multi-step tool chains ended up writing its own returning-a-handle idiom because the prior spec had no standardized long-running-work surface. tasks/get / tasks/update / tasks/cancel land as the client-driven lifecycle over the server-directed task-creation model. The FY27 MCP-server plan can retire the per-vendor idioms and grade against the standardized surface — the portability envelope on the per-vendor MCP-server standing contract improves against the same underlying feature set.
MCP Apps lets the security team put UI-initiated actions on the same audit path as tool calls. The prior spec had no story for server-rendered UI; every team that shipped an interactive MCP tool either wrote a custom web UI outside the audit path or forced the interaction through a chat-mediated turn-taking loop that broke the UX. MCP Apps’ sandboxed-iframe surface with the same JSON-RPC transport lets the interactive tool ship inside the client, on the audit-and-consent path, without the security team writing a bespoke gateway. The interactive tool surface the product team scoped against the prior spec’s gap ships against the standardized affordance inside the migration window.
The OAuth 2.1 / OIDC alignment closes the enterprise-adoption gap. The NSA CSI on MCP security called out authorization as the leading blocker, and the 30-CVE cluster on path-traversal and argument-injection flaws in reference servers underscored the maturity gap. The RC’s alignment with the deployed IdP substrate — the same OAuth 2.1 / OIDC surface the enterprise SSO plane already runs on — means the FY27 MCP-adoption plan grades against the same auth substrate the standing IdP contract already underwrites. The custom auth-gateway middleware the security team wrote as the interim measure retires cleanly against the aligned surface.
Where the RC is signal and where it is noise
Signal: the ten-week window is a hard deadline for the Tier-1 SDK portfolio. The steering group’s Tier-1 SDKs — Python, TypeScript, Go, Java — are expected to ship RC support inside the window. Every MCP server the team runs against a Tier-1 SDK grades against the SDK’s RC-support ship date; every MCP server against a Tier-2 SDK grades against a longer migration window that the team’s own portfolio-portability envelope has to underwrite.
Signal: the deprecation policy is the contract the FY27 procurement plan needs. The prior spec had no formal deprecation contract; the per-cycle spec revisions broke deployed MCP servers with no advance notice. The formal deprecation policy commits the steering group to a compatibility contract the FY27 procurement plan can grade the standing MCP-server contract against — the how long until the next breaking revision forces a re-migration question the procurement function had no answer to now has one.
Noise: MCP Apps replaces the custom web UI is the wrong frame. MCP Apps is the standardized affordance for the tool-scoped UI surface; the platform-scoped web UI (dashboards, admin consoles, workflow builders) still runs outside the MCP transport. The framing that maps every custom web UI onto MCP Apps overshoots the affordance; the framing that maps the interactive tool surface onto MCP Apps hits the spec’s target.
Noise: the stateless core makes stateful servers impossible. The stateless core is the transport-level default; server-side state (session data, per-user cache, running-task state) stays in the server’s own persistence layer. The stateless-transport framing that reads as no server-side state misreads the change; the framing that reads as no connection-affinity requirement at the transport hits it.
What the engineering team should do inside the next two weeks
Inventory the MCP server portfolio against the RC’s four load-bearing changes. For every MCP server the team runs — internal, third-party, community — grade against the stateless-transport migration cost, the Tasks-extension replacement cost for the per-vendor long-running-work idioms, the MCP Apps opportunity for the interactive-tool surface, and the OAuth/OIDC alignment against the enterprise IdP substrate. The output is the FY27 MCP-server portfolio migration plan the ten-week window grades against.
Grade the Tier-1 SDK dependency against the RC’s ship date. For every MCP server against a Tier-1 SDK, book the migration inside the ten-week window; for every MCP server against a Tier-2 SDK, book the extended-window migration against the SDK maintainer’s public timeline. The team’s per-SDK migration timeline becomes the input to the standing MCP-server contract renegotiation.
Retire the custom auth-gateway middleware against the aligned OAuth 2.1 / OIDC surface. The interim custom-auth-gateway code the security team wrote against the prior spec’s under-specified auth layer is the first delete-code refactor the migration window opens. The FY27 platform-simplification target the team wrote against the prior spec’s auth gap becomes a concrete backlog item — grade the delete-code refactor against the same review path every security-critical delete goes through.
Update the standing MCP-server contract against the deprecation policy. The procurement function’s standing MCP-server contract had no compatibility-contract input before the deprecation policy landed. The RC’s deprecation policy is the input the standing-contract renegotiation has been waiting on — the per-vendor compatibility-envelope clause the procurement function has been writing against a moving target now grades against the steering group’s public policy.
What the RC makes cheaper but does not replace
The 2026-07-28 RC compresses the transport, authorization, and long-running-work-lifecycle costs of the MCP-integration surface, not the senior judgment of deciding which MCP servers ship against the enterprise IdP substrate, writing the tool-scoped UI templates the MCP Apps affordance runs against, owning the per-vendor compatibility envelope on the standing MCP-server contract, and running the per-cycle code review against the team’s MCP-server portfolio. The teams that confuse the cheapened transport cost for cheapened judgment ship the interactive-tool surface against MCP Apps templates the security review has not run against, read the CVE post-mortem on the next path-traversal cluster, and eat the per-cycle re-migration cost the deprecation policy would have caught upstream. The teams that keep the senior judgment at the center of the MCP-portfolio decision translate the four load-bearing changes into per-quarter throughput improvements the prior spec’s under-specified surface could not produce.
The MCP question is no longer does the team run MCP servers; it is which MCP servers the team runs against the stateless transport, the Tasks-extension lifecycle, the MCP Apps interactive surface, and the OAuth 2.1 / OIDC aligned authorization, and how the ten-week migration window grades against the FY27 MCP-server portfolio plan.
At SONNET CODE we run the AI Development engagement against the MCP-server portfolio migration plan — per-server stateless-transport migrations, per-vendor Tasks-extension replacements for the long-running-work idioms, per-server MCP Apps interactive-tool surfaces, and OAuth 2.1 / OIDC alignment against the enterprise IdP substrate. If your team’s MCP-server portfolio is still written against the prior spec’s session-model or under-specified auth surface, schedule a call — we’ll walk you through the migration plan we ship inside the ten-week window before the final spec closes it.
