MCP 2026-07-28: What Changes for Your AI Agents
MCP 2026-07-28 is the release candidate for the largest revision of the Model Context Protocol since its November 2024 launch. Stateless architecture, formalized extensions, MCP Apps, graduated Tasks, and deprecations with 12-month notice windows: the final spec ships July 28, 2026, after a 10-week validation window. Here is what concretely changes for your agents and servers.
Source:
blog.modelcontextprotocol.io
· Published May 21, 2026
MCP: a technology born from developer frustration
November 2024. David Soria Parra, an engineer at Anthropic, grows tired of copying the same code between Claude Desktop and his IDE. Together with Justin Spahr-Summers, he formalizes a straightforward idea: an open protocol to connect AI models to tools and data sources, once and for all. The Model Context Protocol launches on November 25, 2024, with initial Python and TypeScript SDKs.
The technical motivation behind MCP is what the two engineers call the “M×N problem”: without a common standard, connecting M models to N tools produces an M×N combinatorial explosion of custom integrations. MCP reduces that to M+N. A server written once can be consumed by any client that follows the spec.
Adoption was rapid — very rapid. By February 2025, just three months after launch, over 1,000 community MCP servers already exist. In March 2025, OpenAI officially adopts the protocol and integrates it into ChatGPT Desktop. Google DeepMind confirms MCP support in Gemini. Dozens of platforms follow: GitHub, Replit, Linear, Zapier, Sourcegraph, Block. In December 2025, Anthropic transfers governance to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, co-founded with Block and OpenAI. In April 2026, the first MCP Dev Summit North America draws 1,200 developers to New York City. Today, over 16,000 MCP servers are referenced across the community.
In under 18 months, MCP has become the de facto standard for connecting AI agents to the outside world. The 2026-07-28 version is not a cosmetic update: it is the first major revision of a protocol that thousands of production servers use every day. What is at stake in this spec is MCP’s ability to scale to modern distributed infrastructure while remaining backward-compatible for existing integrators.
What does this update change at its core?
The 2026-07-28 version is described by the MCP team as “the largest revision of the protocol since launch.” Three axes structure the update: removal of protocol-level session management (shift to stateless architecture), formalization of an extensions system for optional capabilities, and a sustainable governance framework with a feature lifecycle policy and mandatory conformance.
The release candidate was locked on May 21, 2026. The final spec is expected on July 28, 2026, after a 10-week validation window during which SDK maintainers validate changes against production workloads. Python and TypeScript SDKs update in parallel. For integrators, the good news is that deprecations (Roots, Sampling, Logging) carry a minimum 12-month window before effective removal.
Stateless architecture: toward native load balancing
The deepest change in spec 2026-07-28 touches session management. In previous versions, clients had to send an Mcp-Session-Id header and complete an initialization handshake before using a server. This shared-state dependency created significant infrastructure constraints: mandatory sticky routing, distributed session storage, and the inability to scale horizontally without coordination.
The new spec eliminates all of that. An MCP call now looks like:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/callEach request is self-contained. Any server instance can handle it. Client information (context, metadata) is transmitted via _meta fields on every request rather than once during session initialization. From an infrastructure standpoint, you can put a standard load balancer in front of your MCP server fleet without special configuration, and scale each instance independently.
Two new headers complement this change: Mcp-Method and Mcp-Name. They allow gateways and reverse proxies to route MCP requests without parsing the JSON body. You can route tools/call to a different server pool than resources/read at the network level, without application-layer parsing.
How are server-to-client communications redesigned?
Previous MCP versions used Server-Sent Events (SSE) for server-to-client data streams. This approach shared the same problems as session management: persistent connections that are hard to proxy, incompatible with stateless architectures, and problematic behind certain load balancers.
Spec 2026-07-28 replaces SSE with a multi-round-trip request model. When a server needs client input (user confirmation, option selection, additional data), it returns a structured response rather than maintaining a persistent connection:
{
"resultType": "inputRequired",
"inputRequests": {...},
"requestState": "..."
}The client receives this response, collects the required input, and sends a new request including the requestState returned by the server. The state is opaque to the client: it echoes it verbatim. Any server instance can resume the conversation from that state. This approach is consistent with stateless architecture: conversation continuity is carried by the client, not the server.
W3C Trace Context support via _meta fields completes these changes: each request can carry OpenTelemetry-compatible trace identifiers, enabling you to follow an agent call across multiple MCP servers and external services in a single distributed trace.
The extensions framework: MCP becomes modular
One limitation of the original spec was the absence of an official mechanism for optional capabilities. Teams had to either wait for the spec to absorb their need, or implement non-standardized conventions. Spec 2026-07-28 introduces a formalized extensions system.
Extensions use reverse-DNS identifiers (e.g., com.example.my-extension) to avoid naming conflicts. They negotiate activation through capability maps exchanged during discovery. Each extension has its own versioning independent of the main protocol, allowing it to evolve without blocking MCP releases.
The SEP (Spec Enhancement Proposal) process gains a “Standards Track” category for extensions intended to become interoperable standards. Standards Track extensions must include a conformance suite: concrete test scenarios that implementations must pass to claim compliance. Two inaugural extensions enter directly under this regime.
MCP Apps and Tasks: the two first official extensions
MCP Apps lets servers expose HTML interfaces directly within tool definitions. The host (Claude Desktop, an IDE, an agentic application) renders these interfaces in a sandboxed iframe. All user interactions within the interface go through standard JSON-RPC protocol, matching regular tool calls: no side channels, no direct communication between the iframe and the outside. It is a clean way to embed configurable UIs (forms, dashboards, visualizations) inside agents without leaving the MCP security model.
The Tasks extension formalizes what was experimental for several months. The lifecycle is redesigned: a server responds to a tool call with a task handle rather than an immediate result. The client then drives execution via tasks/get, tasks/update, and tasks/cancel. Task creation is now server-initiated (not client-initiated), which better fits long-running workflows where the server knows better than the client when asynchronous execution is needed. tasks/list is removed: its dependency on session state made it incompatible with stateless architecture.
Authorization, governance and conformance
Six authorization SEPs strengthen alignment with OAuth 2.0 and OpenID Connect. Key points: mandatory iss parameter validation per RFC 9207, application type declaration during Dynamic Client Registration, credential binding to issuing authorization servers, and clarification of scope accumulation during privilege escalation. These changes are primarily aimed at enterprise deployments where authorization chain security is critical.
On governance, three mechanisms structure the protocol’s future evolution. The Feature Lifecycle Policy defines a three-stage cycle: Active, Deprecated (with public announcement and documented migration path), then Removed (after a minimum 12 months). This 12-month notice is an explicit guarantee for integrators. The extensions framework lets optional capabilities mature independently. Standards Track SEPs now require a conformance suite: a server or client cannot claim compliance with an extension without passing its test scenarios.
What features are being removed, and why?
Three capabilities enter deprecated status with spec 2026-07-28:
- Roots: replaced by tool parameters or resource URIs. The “root context” concept was ambiguous and rarely used consistently across implementations.
- Sampling: the mechanism allowing an MCP server to trigger LLM calls through the client is deprecated. The recommended replacement is to call the LLM provider API directly from the server. This reflects a cleaner separation of concerns: MCP handles tool-to-model communication, not generation itself.
- Logging: replaced by stderr or OpenTelemetry. MCP-native logs created a session-state dependency and duplicated standard observability tooling.
Effective removal will happen no earlier than 12 months after final spec publication, meaning July 2027 at the earliest. Time to plan your migration.
JSON Schema 2020-12: more expressive tool definitions
MCP tool schemas previously supported a limited subset of JSON Schema. Spec 2026-07-28 upgrades to full JSON Schema 2020-12: composition operators (oneOf, anyOf, allOf), conditional schemas (if/then/else), references and definitions ($ref, $defs). Tool output schemas are no longer constrained either.
This opens concrete possibilities: a tool can now declare that its input parameters are mutually exclusive (oneOf), that certain fields are required only under specific conditions (conditional schemas), or reuse complex type definitions across multiple tools via $ref. For developers building tools with rich data types, this is a significant improvement.
One minor breaking change to note: missing-resource error codes change from JSON-RPC -32002 to -32602 (standard invalid parameter). If your code explicitly tests for this error code, update it.
FAQ
Will my agents keep working with older MCP servers?
If your agents use an updated MCP client that supports 2026-07-28, they can still communicate with servers implementing earlier versions such as 2024-11-05. Version negotiation happens via the MCP-Protocol-Version header: the client announces its version, the server responds with the version it supports, and both sides settle on the highest shared version. This backward compatibility is intentional and documented in the spec.
The real breakage risk lies in deprecated features. If your agent code depends on Sampling or Roots, you have until at least July 2027 to migrate. Servers that have not yet migrated to 2026-07-28 will continue to expose these capabilities normally.
Can an MCP server expose both spec versions simultaneously?
The spec does not prohibit it, but it is not the recommended pattern. The standard approach is for a server to declare the versions it supports in its capabilities response. A client that understands 2026-07-28 can then choose to downgrade to 2024-11-05 if the server does not yet support the new version.
For integrators who want to migrate progressively, the cleanest path is deploying the new SDK version (which handles version negotiation automatically) and validating that your handlers remain compatible. The removal of sessions and SSE is the change requiring the most attention: if your server used session state to track multi-turn conversations, you will need to refactor that logic to be carried client-side via requestState.
MCP Apps: is this a response to conversational interfaces in agents?
Partly. MCP Apps solves a concrete problem: MCP tools could previously only expose structured data (JSON). For tools that benefit from a visual interface (complex configuration, result visualization, selection from a long list), developers had to either pass everything as text parameters or step outside the MCP framework. The extension now lets you embed a minimal UI directly in the tool definition, while keeping the MCP security sandbox intact.
Sampling is deprecated: how do I replace that behavior?
Sampling allowed an MCP server to ask the client to make an LLM call on its behalf and receive the response. The recommended replacement is to call the LLM provider API directly from the server. If your server needs LLM generation, it should manage its own API credentials and its own calls, independently of the MCP client. This is architecturally cleaner, but it requires the server to have access to LLM credentials, which implies a review of your security model.
Conclusion
Spec 2026-07-28 is evidence that MCP succeeded in its initial bet: enough adoption for its architectural limits to become visible in production. The shift to stateless architecture is not an ideological choice; it is a direct response to constraints that thousands of deployments have surfaced. The extensions framework prepares MCP to grow without every new capability requiring a vote from all maintainers. The next 18 months will likely see a proliferation of Standards Track extensions around observability, multi-tenant security, and audio/video capabilities. MCP is no longer an experimental protocol: it is infrastructure.
For more context, our press review on MCP and agentic AI from May 2026 covered how MCP established itself as a context engineering standard.
