MCP 2026-07-28 Spec: What Changed and What It Means for Enterprise Deployments

What Is the MCP 2026-07-28 Spec and What Changed?

The snippet answer first: the MCP 2026-07-28 specification is the next major release of the Model Context Protocol, final on July 28, 2026. The headline changes: a stateless protocol core (no more sessions or handshakes), MCP Apps (server-rendered interactive UIs), a redesigned Tasks extension for long-running work, and OAuth/OIDC-aligned authorization - plus MCP’s first formal deprecation policy.

One caveat before we go deeper: as of publication, the final spec has not landed yet. Everything below reflects the release candidate locked on May 21, 2026, which is explicitly published for validation, not further feature work. The RC-to-final window exists so SDK maintainers can test against real workloads, so material changes between now and July 28 are unlikely - but check the final spec text before betting production code on any single detail.

Why This Release Matters More Than the Version Number Suggests

Spec releases usually interest protocol nerds and nobody else. This one is different, for three reasons.

It is the first spec release under neutral governance. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded with OpenAI and Block and backed by Google, Microsoft, AWS, and Cloudflare. The previous spec (2025-11-25) shipped weeks before that move. The 2026-07-28 release is the first full specification cycle run under the new governance - complete with a public release candidate, a formal proposal process, tiered SDK expectations, and a deprecation policy. That is what “no longer a single vendor’s project” looks like in practice.

The adoption base is enormous. By the time of the AAIF donation, MCP counted over 97 million monthly SDK downloads and more than 10,000 active servers, with first-class support in ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor, and VS Code. A breaking-change-happy spec release against that installed base would be a disaster. This release is engineered to avoid exactly that, and the engineering shows.

It fixes the things enterprises actually complained about. Sticky sessions that fought your load balancer. Authorization that every server implemented slightly differently. No story for work that takes longer than a request timeout. No guarantee about what would still work next year. Each of those has a direct answer in this release. If you have read our Model Context Protocol enterprise guide, this spec addresses most of the operational caveats in it.

Let’s take the changes one at a time.

The Stateless Core: MCP Finally Fits Your Infrastructure

The single biggest change: MCP becomes stateless at the protocol layer. The initialize/initialized handshake is gone. The Mcp-Session-Id header is gone. Protocol-level session management is gone entirely.

In its place:

• Every request is self-describing. Client metadata - protocol version, capabilities, client info - moves from a one-time handshake into per-request fields, so any server instance can handle any request cold.
• Capability discovery becomes a method. A new server/discover call replaces upfront capability negotiation.
• Routing metadata travels in headers. New Mcp-Method and Mcp-Name headers let load balancers, gateways, and rate limiters route on the operation without inspecting the request body.

Why should anyone outside the protocol team care? Because stateful MCP was genuinely painful to operate at scale. Under the current spec, running MCP servers behind a load balancer meant sticky sessions, a shared session store, or deep packet inspection at the gateway. Serverless deployments - where instances appear and vanish per request - fought the protocol’s assumption of a persistent session. Teams worked around it; the workarounds were the tax.

Under 2026-07-28, an MCP server is just an HTTP service. Round-robin load balancing works. Cloud Run, Lambda, and Azure Container Apps work without session gymnastics. Horizontal autoscaling works. As the SDK beta announcement puts it, “any server instance can handle any request.”

One important nuance: stateless protocol does not mean stateless application. If your server manages a shopping cart or a multi-step workflow, the spec’s answer is the explicit-handle pattern - a tool returns an identifier, and the model passes it back as an ordinary argument on later calls. State becomes visible and auditable instead of hiding inside a session. For enterprise audit trails, that is a feature, not a compromise.

MCP Apps: Servers Get a User Interface

MCP Apps let a server ship interactive HTML interfaces that host applications render in a sandboxed iframe. Think of a data-visualization server that returns an actual chart you can filter, or an approval tool that renders a proper review panel instead of a wall of JSON.

The design is more conservative than “servers can inject web pages” sounds:

• Templates are declared ahead of time. Tools declare their UI templates up front, so hosts can prefetch, cache, and security-review them before anything renders.
• The UI speaks MCP, not arbitrary JavaScript-to-host magic. A rendered interface talks back to the host over the same JSON-RPC protocol as everything else, which means every UI-initiated action goes through the same audit and consent path as a direct tool call.

For enterprises, that second point is the one to underline in your security review. A button click inside an MCP App is not a side channel around your approval gates - it is a tool call, logged and governed like any other. If you build internal agent tooling, MCP Apps is the difference between “our agent works but the experience is a chat transcript” and something your business users will actually adopt.

The Tasks Extension: Long-Running Work, Redesigned

Agents increasingly do work that outlives a request: generate a report, run a batch job, wait for a human sign-off. The 2025-11-25 spec shipped an experimental Tasks API for this; production use surfaced enough problems that the 2026-07-28 release redesigns it and graduates it into an official Tasks extension.

The new shape fits the stateless model: a server can answer a tools/call with a task handle instead of a final result, and the client drives the lifecycle from there with tasks/get, tasks/update, and tasks/cancel. No persistent stream required - which matters, because the old design leaned on long-lived SSE connections that were exactly the kind of state the new core removes.

Two things to note:

1. This is the one genuine migration in the release. If you built against the experimental 2025-11-25 Tasks API, your code needs updating. Everyone else is unaffected.
2. Tasks shipping as an extension is itself news. The 2026-07-28 spec introduces an extensions framework - capabilities negotiated through an extensions map, living in their own repositories with delegated maintainers, versioning independently of the core spec. Tasks and MCP Apps are the first big residents. The core stays small; the ecosystem gets a sanctioned way to grow.

If you are weighing where task-style delegation belongs in your architecture - inside MCP, or between peer agents - our MCP vs A2A comparison walks through that boundary in detail.

OAuth/OIDC Alignment: The Enterprise Auth Story

This is the section to forward to your identity team, because it is the part of the release that changes procurement conversations.

MCP authorization has been OAuth-based since 2025, but the details left room for insecure implementations and enterprise friction. The 2026-07-28 release hardens authorization through a set of proposals that pull MCP into line with standard OAuth and OpenID Connect practice:

• Issuer validation is mandatory. Clients must validate the iss parameter (per RFC 9207) to close the OAuth mix-up attack, where a client is tricked into sending credentials to the wrong authorization server.
• Credentials bind to a specific authorization server. Tokens obtained from one issuer cannot silently be replayed against another.
• Registration gets OIDC-shaped. Clients declare an OpenID Connect application_type during registration, and refresh-token and scope-accumulation behavior is clarified so implementations stop guessing.

Alongside the core spec, the Enterprise-Managed Authorization extension went stable in June 2026. This is the piece enterprise buyers have been waiting for: organizations can centrally manage authorization for MCP servers, and end users access all connected MCP servers through a single login. No more per-server OAuth dances, no more shadow consent screens your security team has never reviewed.

The combined effect: MCP authorization becomes something an identity team can govern with the tools they already run - their IdP, their conditional access policies, their audit pipeline. In our experience building agent integrations for UAE enterprises, auth is where MCP projects stall in security review. This release removes most of the legitimate objections. What it does not remove: your obligation to scope credentials per server and per agent. Least privilege is still a design decision, not a protocol feature.

The Deprecation Policy: What Breaks, What Is Guaranteed

The least glamorous change may be the most important for anyone signing off on MCP as enterprise infrastructure.

The 2026-07-28 release introduces MCP’s first formal deprecation policy. Three long-standing features - Roots, Sampling, and Logging - enter deprecation in this release. The guarantee attached: deprecated methods continue to work in this specification version and in every version published within a year of it, and actual removal requires a separate, explicit proposal.

And what breaks on release day? Per the MCP team, nothing: “For existing clients and servers nothing breaks today, and nothing breaks on July 28 either.” New-spec servers answer the legacy initialize handshake alongside server/discover, so clients still on 2025-11-25 keep connecting. The spec ships with a full changelog against 2025-11-25 so you can diff exactly what moved.

For a protocol barely twenty months old, this is the moment it starts behaving like infrastructure: predictable lifecycle, published guarantees, compatibility bridges. It is the same maturation arc we track across the agent stack in our AI agent framework comparison - the platforms that win enterprise workloads are the ones that stop breaking their users.

Migration Guidance: What to Do Before and After July 28

If you run MCP servers or clients today, here is the practical sequence.

Before July 28:

1. Inventory your MCP surface. List every server you run, every client that connects, which SDK and version each uses, and whether anything touched the experimental 2025 Tasks API. That last group is your only mandatory migration.
2. Start testing against the beta SDKs. Betas for Python, TypeScript, Go, and C# are already out. The TypeScript SDK ships an automated codemod (v1-to-v2) that handles much of the mechanical refactoring; Python v2 has a dedicated migration guide; Go and C# migrations are gentler, with no package split.
3. Loop in your identity team now. Review the Enterprise-Managed Authorization extension against your IdP setup. If MCP servers are on your 2026 roadmap, central auth should be designed in, not bolted on.
4. Do not panic-migrate. Nothing forces a release-day cutover. Dual-mode support means old and new coexist.

After July 28:

1. Read the final spec changelog against the RC before shipping anything you built during the beta window.
2. Upgrade SDKs deliberately, starting with new servers (build them stateless-native from day one) and internally owned servers, leaving vendor-supplied servers to their vendors’ timelines.
3. Revisit your deployment architecture. The stateless core is an invitation: if you provisioned sticky sessions, session stores, or oversized always-on instances purely to satisfy the old protocol, you can now simplify and often cut cost.
4. Track the deprecation clock. If your servers rely on Roots, Sampling, or Logging, you have at least a year of guaranteed support - use it to plan replacements, not to forget.

What This Means for UAE Enterprises

For organizations building AI agents in the UAE, this release lands at a convenient moment - agent adoption here is policy-driven and accelerating, and the questions boards ask are governance questions.

Data residency gets easier to argue. The stateless core means MCP servers deploy cleanly onto whatever infrastructure your residency posture requires - UAE-region cloud, on-premises, sovereign platforms - behind standard load balancers, without protocol-specific session plumbing that complicates architecture reviews. A stateless HTTP service is a shape your infrastructure and security teams already know how to host, isolate, and audit.

PDPL compliance gains real hooks. Under the UAE Personal Data Protection Law, you need to demonstrate control over who accesses personal data and how. The OAuth/OIDC alignment plus Enterprise-Managed Authorization gives you centrally governed, IdP-enforced, auditable access to every MCP server touching personal data - a far stronger answer than the per-server token sprawl of 2025. The explicit-handle pattern helps too: application state passed as visible arguments is state you can log, review, and minimize.

The governance angle carries weight in procurement. UAE government and enterprise buyers consistently prefer standards with neutral stewardship over single-vendor protocols. MCP under the Agentic AI Foundation - with Anthropic, OpenAI, and Block as co-founders and hyperscaler backing - plus a formal deprecation policy is a materially easier “why this protocol” slide than it was a year ago. If your AI committee stalled on protocol risk in 2025, this release is the update that reopens the conversation.

The Bottom Line

The MCP 2026-07-28 spec is a maturity release: it makes MCP servers cheaper to operate (stateless core), richer to use (MCP Apps), capable of real work (Tasks), governable by identity teams (OAuth/OIDC plus enterprise auth), and safe to depend on (deprecation policy) - all without breaking the thousands of servers already running. The right move for most teams is calm and concrete: inventory now, test the beta SDKs, involve your identity team, and build anything new stateless-native.

NomadX is an AI agents consultancy in Dubai that builds MCP servers and agent integrations for UAE and GCC enterprises. If you want a migration plan for your MCP estate before July 28 - or a first server built right on the new spec - book a free 30-minute consultation.