The release, in one paragraph
On May 21, 2026, the Model Context Protocol team published the 2026-07-28 Release Candidate — the largest revision of the spec since the protocol launched. Four headline changes: a stateless core that no longer requires sticky sessions, a session store, or gateway-level packet inspection (clients route on a new Mcp-Method header, cache tools/list responses against a server-provided ttlMs, and reconnect to any backend instance freely); the MCP Apps extension, a server-rendered UI surface that lets an MCP server ship interactive interfaces alongside its tool definitions; the Tasks extension, a first-class long-running work primitive that supersedes the various polling patterns the community has been hand-rolling; and an OAuth + OpenID Connect-aligned authorization profile that maps cleanly onto the identity stacks every enterprise already runs. The final spec ships July 28, 2026, with a ten-week SDK validation window; Tier 1 SDK maintainers are expected to ship support inside that window. The MCP team's framing is "the foundation we'll grow on for a long time" — stateless protocol, modular extensions, lifecycle policy that lets implementers build with confidence.
The surprising line isn't "MCP is getting more capable." Every major frontier vendor has been shipping MCP-adjacent surfaces since the protocol gained momentum twelve months ago. The surprising line is the architectural axis the RC chose to optimize: stateless HTTP rather than richer session semantics, modular extensions rather than monolithic core growth, OAuth-aligned auth rather than a new identity model. Each of those choices makes MCP cheaper to run on commodity infrastructure, easier to integrate with existing enterprise stacks, and less coupled to vendor-specific tooling. The protocol just stopped looking like a research-spec demo and started looking like a piece of plumbing CIOs can put into a five-year procurement plan. The catch — and there's always a catch — is that every remote MCP server already in production was architected against the previous assumptions. Migration isn't optional, and the ten-week window between July 28 and the SDKs catching up is the runway every implementer has to plan against.
Why the stateless core is the architecture decision, not the protocol revision
For twelve months, every team operating a remote MCP server has been making the same set of compromises against the protocol's stateful model: a Redis-backed session store to survive process restarts, a load balancer with sticky-session affinity (and the operational pain that comes with it), gateway-level deep packet inspection to route inside MCP traffic, and a tail of edge cases when a connection migrates between instances. The 2026-07-28 RC removes the need for every one of those compromises. That's not a protocol detail. It's a stack-shape change.
Sticky sessions are an operational tax MCP shops have been quietly paying. A load balancer with sticky-session affinity is more expensive to operate than a round-robin one, fails over differently, complicates blue-green deploys, breaks in subtle ways during scale-in events, and adds a moving part to incident response. Teams running remote MCP at scale have been carrying this cost as a line item that didn't have a name. The stateless core gives those teams an upgrade path to plain round-robin, dramatically simpler failure semantics, and a deploy story that matches the rest of their HTTP stack. The cost reduction is real, recurring, and material.
tools/list caching is the latency win nobody's been talking about. Under the previous spec, every client connection round-tripped tools/list against the server on startup, and again whenever the client decided to refresh. With the new ttlMs field, the server tells the client how long the tool catalog is valid for, and the client caches the response client-side. For high-fanout MCP servers — internal tooling reached by dozens or hundreds of agents — this collapses a meaningful chunk of the cold-start latency budget that's been eating tail-latency SLOs for two quarters.
OAuth + OIDC alignment closes the procurement-review loop. The single largest reason MCP integrations have stalled in enterprise security review is the auth story — every prior alternative required either bespoke token issuance, a custom identity model, or a non-standard handshake that the security team had to evaluate from scratch. OAuth + OIDC alignment means the security team gets to evaluate MCP auth using the same mental model, the same review checklist, and the same threat model they already use for every other integration on their network. The friction collapse is hard to overstate.
What MCP Apps and the Tasks extension actually change
Server-rendered UI inside an MCP context is a new product surface. MCP Apps lets the server ship interactive UI alongside its tool catalog — a connector for a hosted CRM can render the customer-edit form directly inside the agent's context, with the same auth scope as the tool call, the same audit trail, the same governance posture. That's a meaningfully different shape from "agent calls a tool, tool returns text, agent decides what to render." The right reading is that MCP Apps positions the MCP server as the canonical surface where the integration's UI lives, with the agent as the orchestration layer. For teams building internal tooling that's accessed through agents, this changes the design conversation from "how do we describe the tool to the model" to "how do we ship the integration's UI as a first-class agent-context surface."
The Tasks extension finally formalizes long-running work. Every team that's tried to run a Goal Mode-style agent against an MCP server has hit the same wall: the protocol assumed short-running tool calls, and long-running work had to be hand-rolled with polling endpoints, status check tools, and ad-hoc resumption logic. The Tasks extension makes the long-running case first-class — a task is started, runs asynchronously, surfaces progress and intermediate output, and completes with a structured result that the client can interpret without inventing the contract per server. For agentic workloads that run for minutes or hours, this is the missing primitive.
The extension model itself is the durable design choice. By splitting capabilities like Tasks and MCP Apps into separately-versioned extensions, the MCP team gave themselves (and the community) a way to ship new capability without rebuilding the protocol core. Implementers can adopt extensions incrementally, version them independently, and avoid the "every spec revision is a forklift upgrade" problem that earlier protocols have struggled with. The lifecycle policy that ships alongside the RC is what makes the extension model credible — implementers can build on 2026-07-28 with confidence that the spec they target will keep working.
What the RC doesn't change
Migration is real engineering work. Stateless-core support requires server-side changes (drop the session store, expose the new Mcp-Method routing surface, publish ttlMs for cacheable responses), client-side changes (route on the new header, honor the cache, drop the sticky-session assumption), and gateway/load-balancer changes (round-robin replaces sticky, packet inspection comes out, observability needs to be re-wired against the new request shape). Each layer is straightforward in isolation; coordinating the migration across the entire stack is real project work. Teams that wait until the SDKs ship support in early August will find themselves carrying both the legacy and the new stack through the rest of 2026.
The SDK tier gap matters. Tier 1 SDKs are expected to ship support inside the ten-week validation window. Tier 2 and community SDKs aren't on the same clock. If your stack depends on a Tier 2 SDK or a community fork, the migration runway is longer, and the dependency on the SDK maintainer's roadmap becomes a real planning constraint. Inventory the SDK tier for every MCP integration in your stack and plan against the actual ship timeline, not the headline July 28 date.
MCP Apps shifts UI-architecture ownership, with real downsides. Server-rendered UI inside the agent context means the MCP server vendor owns the integration UX. That's good when the vendor's UX team is competent and the agent context is well-designed; it's bad when the vendor's UX is brittle, the agent context renders poorly, or the customer wants to customize the experience. Teams adopting MCP Apps need to decide deliberately which integrations are best served by vendor-rendered UI and which are better served by the prior pattern of "the agent calls a tool and decides what to render."
Stateless does not mean no state. The protocol's stateless core covers the request/response transport. Application-level state — the user's session with the underlying system the MCP server fronts, the long-running task state managed via the Tasks extension, the cached tools/list response — is still real state that has to be managed somewhere. The win is that the protocol layer doesn't require the server to manage it via sticky sessions; the state management problem doesn't disappear, it just moves to a layer where you have better tools to handle it.
Where we'd push back on the framing
"Stateless protocol" is a load-balancer win, not a free architecture. The cost reduction from dropping sticky sessions is real. The complexity reduction at the application layer is real but smaller — the long-running task state, the cached tool catalog, and the user-session state still need stores, retention policies, and eviction logic. Teams celebrating the protocol revision should be careful not to assume the state-management work disappeared.
"Ten-week window" is a Tier 1 promise; your dependency chain may be longer. The MCP team's commitment to Tier 1 SDK support inside the window is credible. The full ecosystem — every third-party MCP server, every internal MCP server, every gateway product, every observability tool — operates on its own clock. The honest planning posture is "Tier 1 SDKs in early August; everything else through Q4."
MCP Apps will be misused before it's used well. Every "server can ship UI now" capability in the history of computing has gone through a phase where vendors over-rely on the surface and ship brittle, inconsistent UX inside customer products. MCP Apps will hit that phase. The discipline that separates the good adoption from the bad is whether the team building the MCP server treats the rendered UI as a first-class product surface with the same UX standards as any other front-end work — or as an afterthought bolted onto the tool catalog.
"Foundation we'll grow on for a long time" is the spec author's intent, not the market's guarantee. Two years of MCP momentum is good evidence the protocol is durable. It is not certainty. The teams that build on MCP today should still maintain a thin abstraction layer that could be re-pointed at a successor protocol if the market shifts. The architectural rule "don't couple to the protocol as if it's permanent" is wisdom that survives every spec revision.
What we'd build differently this week
- Inventory your remote MCP servers and their SDK tiers. For each one, answer: which SDK is it built on, what tier is that SDK, what's the realistic timeline for the maintainer to ship 2026-07-28 support. Use the answers to triage which servers can ride the Tier 1 timeline and which need a custom migration plan.
- Audit your sticky-session infrastructure with a migration lens. Every load balancer running session affinity for MCP traffic is a candidate for simplification. Inventory the operational cost of the sticky-session deployment (failover behavior, blue-green friction, scale-in pain) and the savings the stateless migration unlocks. The business case for the migration is usually in those numbers.
- Pilot the Tasks extension on one long-running workload. Pick the workload where the team has been hand-rolling the worst polling-and-resumption logic; rebuild it against the Tasks extension once the SDKs land; document the friction the new primitive removes. That documentation is the internal-evangelism artifact that justifies the broader migration.
- Decide your MCP Apps adoption posture before the first vendor ships UI. Which integrations should ship server-rendered UI through MCP Apps? Which should stay on the "agent calls tool, agent renders" pattern? Get the call right before a vendor's MCP App shows up uninvited in your agent context, not after.
- Re-evaluate your OAuth + OIDC integration for MCP-bound flows. The new authorization profile aligns MCP auth with the identity stack the security team already operates. Use the alignment to consolidate MCP token issuance into the same identity infrastructure as your other OAuth surfaces — same review, same audit, same revocation tooling.
Sonnet Code's take
The MCP 2026-07-28 RC is the moment the protocol stopped being a research-spec experiment and started being plumbing the enterprise architecture team can actually depend on. The stateless core is the cost-reduction story; MCP Apps and Tasks are the new-capability story; OAuth/OIDC alignment is the security-review story. Together, they make MCP credible as the integration layer between hosted AI products and enterprise systems for the next several years. The catch is the migration: every remote MCP server already in production was built against the prior assumptions, and the ten-week SDK validation window is the runway implementers have to start planning against now, not in July.
That's our wheelhouse. AI development at Sonnet Code is the engineering work that takes MCP from spec to production — the server implementations, the gateway changes, the load-balancer simplifications, the migration plans, the observability and rollback paths that turn a protocol revision into a stack a customer can run. We pair that with AI training engagements where the MCP-served toolset is the surface a tool-using agent acts against — the eval rubrics, the trajectory grading, the senior-practitioner review that grades whether the agent is using the MCP-exposed tools correctly, the supervision contract that catches the bad call before it ships. If your team is reading the RC this week and quietly noting that your remote MCP server is built on a sticky-session deployment that's been operationally expensive since day one, the next conversation isn't about whether to migrate. It's about who owns the migration plan, the SDK-tier audit, the rollout sequence, and the operational simplification you'll actually book once the legacy stack is decommissioned.
