Updated:
The Model Context Protocol (MCP) published its final 2026-07-28 specification on July 28, 2026 — the largest revision of the protocol since its launch — delivering a stateless core that removes sticky sessions, two official extensions for async agent work and server-rendered UIs, and hardened OAuth 2.0-aligned authorization. Businesses running AI agents via MCP-connected tools face breaking changes in error codes and deprecated features, but gain dramatically simpler infrastructure requirements.
What Changed: Stateless Core Replaces Session Model
MCP’s previous specification (2025-11-25) required every AI client to open a session with an initialize handshake, receive an Mcp-Session-Id, and maintain a sticky connection to the same server instance. The 2026-07-28 spec removes that model entirely.
Per the official MCP blog, a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway “can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server’s ttlMs permits.” The practical result: teams running AI agents at scale face substantially lower infrastructure costs because any request can now go to any server instance, like regular HTTP.
Two new required headers replace the session mechanism: MCP-Protocol-Version and Mcp-Method must appear on every request (SEP-2243).
Two Official Extensions: Tasks and MCP Apps
The 2026-07-28 spec ships with two official extensions that address longstanding gaps for business AI workflows.
Tasks (SEP-2663) provides a standardized way to handle long-running agent work. A server can respond to a tool call with a task handle; the client tracks progress with tasks/get, tasks/update, and tasks/cancel. This eliminates the need to hold an HTTP connection open for multi-hour operations such as batch analysis jobs or extended coding tasks — a key requirement for production AI agents running business automation workflows.
MCP Apps (SEP-1865) allows MCP servers to ship interactive HTML UI components that host applications render in a sandboxed iframe. An MCP tool can display its own form or dashboard directly inside the AI interface. Client adoption timelines are per-vendor; the spec defines the capability but does not guarantee immediate availability in Claude, Cursor, or other MCP clients.
Three Features Deprecated — 12-Month Removal Window
The 2026-07-28 spec deprecates three core MCP features, each replaced by a leaner alternative:
- Roots — replaced by tool parameters
- Sampling — replaced by direct LLM APIs
- Logging — replaced by stderr output or OpenTelemetry
The MCP feature lifecycle policy guarantees a minimum 12-month window between deprecation and removal. Teams should not build new functionality on these three features, but existing deployments have time to migrate.
Breaking Changes Business Teams Should Flag Now
The 2026-07-28 spec introduces two breaking changes that require active code review:
- Error code change: The error returned for a missing resource changes from MCP-custom
-32002to JSON-RPC standard-32602. Any application matching on the literal error code-32002will silently miss missing-resource errors after upgrading. - Tool schema expansion:
inputSchemanow supports full JSON Schema 2020-12, includingoneOf,anyOf, and$ref(SEP-2106). Parsers that assume a flat schema may need updates.
Teams that shipped against the experimental Tasks API in the 2025-11-25 spec must also migrate to the new Tasks lifecycle defined in SEP-2663.
Who Governs MCP and Why That Matters
MCP is a project of LF Projects (Linux Foundation) — not owned by Anthropic or any single vendor. The protocol’s maintainers, David Soria Parra and Den Delimarsky, describe the 2026-07-28 release as delivering “on the 2026 roadmap: 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, authorization that aligns more closely with OAuth 2.0 and OpenID Connect deployments, a formal deprecation policy so the protocol can evolve without breaking what you’ve built.”
MCP clients include Claude Code, Claude Cowork, Cursor, VS Code Copilot, and Windsurf. Any AI tool that connects agents to external data sources — CRM systems, file storage, databases, or APIs — is likely using MCP as the transport layer. Business IT teams evaluating AI automation platforms should ask vendors for explicit 2026-07-28 compatibility confirmation before committing to new deployments.
September 2026 Update: The New MCP Roadmap Names Five Priorities After the Stateless Release
MCP’s Core Maintainers published a new roadmap on August 22, 2026, replacing the March 2026 plan that the 2026-07-28 specification largely delivered. The new roadmap sets five priority areas for the next six to twelve months, and any Specification Enhancement Proposal (SEP) that falls inside them gets expedited review.
Lead maintainers David Soria Parra and Den Delimarsky wrote that the March roadmap’s four goals — transport evolution and scalability, agent communication, governance maturation, and enterprise readiness — saw “significant progress” in five months, with the bulk landing in the 2026-07-28 release covered above. Governance changed alongside the spec: the project formally adopted a Contributor Ladder, Working Groups now triage SEPs in their own area instead of routing every proposal through the full core-maintainer group, and the deprecations described above were the first to follow the new feature lifecycle policy. The roadmap page itself carries a caveat that it “reflects current thinking rather than firm commitments.”
The five priority areas
- Agentic messaging primitives — server-initiated events (webhooks and channels via the Triggers & Events Working Group) so clients stop polling for results, plus a composition review so Tasks, subscriptions, and progress notifications share one lifecycle and cancellation model. Tasks (SEP-2663) is expected to move from extension into the core protocol.
- HTTP-native transport unification and hardening — Streamable HTTP as the single transport binding, spoken over stdio for local servers (the maintainers expect HTTP/2 over stdio to work), and ETag-style caching extended from list results to tool-call results.
- Agent identity and enterprise-ready security — a new Agent Identity Working Group is forming to finalize Demonstrating Proof of Possession (DPoP) and define how an agent reaches an MCP server with its own workload identity or a user-delegated one, via Workload Identity Federation (SEP-1933), the ID-JAG grant behind Enterprise-Managed Authorization, and RFC 8693 token exchange. The maintainers’ stated problem: today’s MCP authorization “assumes a person with a browser at consent time,” while real callers are increasingly unattended cloud agents relying on pasted API keys and long-lived refresh tokens.
- Improved primitives — redesigning the
tools/callresult shape, because returning bothcontentandstructuredContenthas produced diverging client implementations, and a “progressive discovery” effort so a server with a hundred tools can expose a small entry point instead of loading the model with its entire catalog up front. - Improved SDK developer experience — a formal extension contract for SDKs and an experiment generating a Tier 1 SDK and its quickstarts directly from the specification, validated against the conformance test suite.
What the roadmap changes for business AI buyers
Two items on this roadmap map directly onto enterprise procurement questions. The agent-identity work is the protocol-level answer to the agentic AI security risks that IT teams currently mitigate with gateway controls and shared credentials — once DPoP and delegated identity land, an MCP server can distinguish a headless agent acting for an absent employee from a person clicking “approve” in a browser. Progressive discovery addresses cost: every tool a server exposes is paid for in model context before the user asks anything, and the maintainers say tool selection degrades as catalogs grow, so vendors that ship large MCP tool sets should be asked how they plan to adopt it.
The Enterprise-Managed Authorization extension, which the roadmap builds on, is already stable as of the 2026-07-28 cycle — teams that need corporate-identity-bound access to MCP servers do not have to wait for the roadmap items to ship.
For context: our coverage of the March 2026 roadmap that this one replaces — MCP goes stateless: what the new roadmap means for AI agents — and of the A2A and MCP consolidation under the Linux Foundation.
Our Take
2026-07-28 spec removes that constraint, and the August roadmap shows where the remaining friction sits: identity for unattended agents and tool catalogs that bloat model context. Neither is solved yet — the roadmap is explicit that it is “current thinking rather than firm commitments” — so buyers should treat DPoP and progressive-discovery support as questions to put to vendors over the next twelve months, not as features to expect at contract signing.Frequently Asked Questions
What is the Model Context Protocol (MCP)?
The Model Context Protocol is an open standard, governed as a Linux Foundation (LF Projects) project, that defines how AI clients such as Claude Code, Cursor, and VS Code Copilot connect to external tools and data sources like CRMs, file storage, and databases. The current specification version is 2026-07-28.
What changed in the MCP 2026-07-28 specification?
The 2026-07-28 spec removed protocol-level sessions and the initialization handshake so servers scale horizontally on ordinary HTTP (SEP-2575, SEP-2567), added two required headers (MCP-Protocol-Version and Mcp-Method), shipped Tasks (SEP-2663) and MCP Apps (SEP-1865) as official extensions, deprecated Roots, Sampling, and Logging with a 12-month removal window, and changed the missing-resource error code from -32002 to -32602.
What are the five priority areas in the August 2026 MCP roadmap?
The roadmap published on August 22, 2026 names five areas: agentic messaging primitives, HTTP-native transport unification and hardening, agent identity and enterprise-ready security, improved primitives (tool result shape and progressive discovery), and improved SDK developer experience. SEPs inside these areas receive expedited review.
Does MCP support agent identity and single sign-on for enterprises?
Enterprise-Managed Authorization, which binds MCP access to a corporate identity provider through the ID-JAG grant, is already a stable extension. Agent-specific identity — DPoP, Workload Identity Federation (SEP-1933), and RFC 8693 token exchange — is a roadmap priority being worked on by a newly forming Agent Identity Working Group and is not yet part of the specification.
Do existing MCP servers need to change for the new roadmap?
No. The roadmap describes future specification work; existing servers built on the 2026-07-28 spec keep working. Teams should, however, stop building new functionality on the deprecated Roots, Sampling, and Logging features, which the feature lifecycle policy guarantees at least 12 months before removal.
How can a business propose a change to MCP?
Changes are submitted as Specification Enhancement Proposals (SEPs). The maintainers advise identifying which of the five priority areas a proposal belongs to and raising it with the relevant Working Group first — SEPs with a Working Group behind them and a clear line to the roadmap move fastest.
Sources: MCP Blog — 2026-07-28 Release · MCP Blog — The New MCP Roadmap (Aug 22, 2026) · modelcontextprotocol.io/development/roadmap
