MCP 2026: How the Model Context Protocol Becomes the Standard for AI Agents

📷 "Why and How You Should Build Easy Free No-code AI Agents Now: companies are hiring them instead of you!" by MarkGri is marked with CC0 1.0. To view the terms, visit https://creativecommons.org/publicdomain/zero/1.0/.

The Model Context Protocol (MCP) has evolved from an Anthropic experiment into a central building block of agentic AI infrastructure in just two years. OpenAI, Microsoft, Google, and Amazon now support the standard. However, with its growing adoption in production environments, the protocol’s weaknesses have also become visible. July 2026 marks a turning point: With version 2026-07-28, MCP is fundamentally revised—and above all, becomes stateless.

From Local Tool Protocol to Enterprise Infrastructure

At the end of 2024, Anthropic introduced MCP as an open protocol that allows AI models standardized access to external tools, files, and data sources. Instead of writing custom integrations for each system, teams can deploy their services as MCP servers. This saves time and creates interoperability.

What began as a simple solution for local tool calls is now used in serious production environments. Large and small companies operate MCP servers for workflows ranging from CRM queries to ERP integrations and complex multi-step approval processes. However, this development brought to light a number of problems that the maintainers are now addressing in a new roadmap.

The Four Priorities of the 2026 MCP Roadmap

In March 2026, David Soria Parra, Lead Maintainer of MCP, published the updated roadmap. It defines four focus areas where development capacity is concentrated:

1. Transport Evolution and Scalability Previously, MCP relied on stateful sessions. A client had to establish a session, obtain a session ID, and direct all subsequent requests to the same server instance—a hindrance to horizontal scaling behind load balancers. The solution: a stateless protocol core that does without session management.

2. Agent Communication The Tasks function (SEP-1686) enables asynchronous, long-running tasks. However, production use revealed gaps in retry logic and execution policies. These are now being closed.

3. Governance Maturation Currently, every specification proposal (SEP) must be reviewed by all core maintainers—a bottleneck. A contributor ladder and a delegation model for working groups are intended to remedy this.

4. Enterprise Readiness Audit trails, SSO authentication, gateway behavior, and portable configuration—the typical requirements of companies are being systematically addressed, though initially defined less concretely to incorporate user experiences.

Release Candidate 2026-07-28: A New Foundation

On May 21, 2026, the release candidate for the new specification was published, which will be finalized on July 28, 2026. The changes are the most extensive since the protocol’s launch.

The core: MCP is now stateless at the protocol level. The previous initialize handshake and session ID are omitted (SEP-2575, SEP-2567). Instead, protocol version, client information, and capabilities travel in a _meta field with each request. New HTTP headers like Mcp-Method and Mcp-Name enable routing based on the operation without needing to parse the request body.

An MCP server that previously required sticky sessions, a shared session store, and deep packet inspection at the gateway can now be easily operated behind a simple round-robin load balancer. Listening results (tools/list) are cacheable with ttlMs and cacheScope specifications—analogous to HTTP Cache-Control.

The practical impact: A client can direct any request to any server instance without a prior handshake. The initialize/initialized exchange is eliminated (SEP-2575); the protocol version and client capabilities travel in the _meta field. For stateful applications, there is an explicit handle pattern: A tool generates an ID (e.g., a basket_id) that the model passes as an argument to subsequent calls. This makes the state visible and auditable for the model—a win over hidden session state in the transport layer.

Extensions, Apps, and a Deprecation Model

For the first time, the release candidate introduces a formal extensions framework. Extensions are identified via reverse-DNS IDs, versioned in their own repositories, and developed independently of the core specification. The version delivers two official extensions:

MCP Apps (SEP-1865): Servers can deliver interactive HTML interfaces that the host renders in a sandboxed iframe—ideal for approval workflows where a human must confirm before an action.
Tasks (SEP-2133): Asynchronous task processing evolves from an experimental core feature to a full-fledged extension, with clear lifecycle rules for retries and result retention.

A formal deprecation process ensures the protocol can continue to evolve without breaking existing implementations. Additionally, authorization has been revised: The new specification brings OAuth and OpenID Connect support, specifically targeting the one-to-many deployment typical for agentic systems—one client (the agent) connects to many servers (CRM, ERP, database). And with standardized W3C Trace Context Propagation in _meta, distributed call chains across multiple MCP servers can be traced in OpenTelemetry backends.

Conclusion

July 2026 is a decisive month for MCP. By moving away from stateful sessions, introducing an extensions framework, and clarifying governance issues, the protocol lays the foundation for broad enterprise adoption. The direction is clear: MCP is evolving from a tool protocol for AI experiments into a production-ready standard infrastructure for agentic AI. Teams using MCP today benefit from an architecture that scales with the same principles as the HTTP API ecosystem—proven, observable, and cost-efficient.

Sources

🌐 Machine-translated from the German original, editorially reviewed. 🤖 Written with AI assistance.