MCP hit 97 million monthly installs by March 2026 -- 16 months after launch. The 2026 roadmap targets its production failure modes: stateful sessions that break under load balancers, async tasks with no retry semantics, and enterprise auth built on static secrets. Four priorities. June 2026 spec target. Here is what is shipping and how to build around the gaps today.
I have been building with MCP since the early days. The protocol made tool integration tractable. But the moment you move from a local Claude Desktop setup to a real production deployment -- multiple servers, horizontal scale, long-running agent tasks -- you hit the same walls everyone hits. The 2026 roadmap is directly aimed at those walls.
Where Is MCP Right Now?
MCP grew from roughly 2 million downloads at launch to 97 million monthly installs in 16 months -- one of the fastest open-source protocol adoption curves on record. That milestone, reached in March 2026, marks MCP's transition from experimental standard to foundational infrastructure. The ecosystem built fast alongside it: over 1,000 open-source MCP servers now exist on GitHub, covering database connectors, code execution environments, document processing tools, and dozens of SaaS API integrations.
Two governance shifts happened in parallel. On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation -- a directed fund under the Linux Foundation. That puts MCP on the same governance path as Kubernetes and PyTorch. The single-vendor risk that kept enterprise architects cautious about committing to MCP as infrastructure is effectively gone.
The volume created quality pressure. Between January and February 2026, security researchers filed over 30 CVEs targeting MCP servers, clients, and infrastructure -- including a CVSS 9.6 remote code execution flaw. The 2026 roadmap published by lead maintainer David Soria Parra is a direct response to both the adoption success and the production pain that came with it.
What Does Transport Scaling Actually Mean for Builders?
Streamable HTTP replaced the original stdio transport as MCP's primary remote protocol -- it lets servers run as HTTP services rather than local processes, which unlocked production deployments. The problem is that stateful sessions fight load balancers. You cannot drop a stateful MCP server behind a standard Kubernetes ingress without sticky sessions or a distributed session store. Horizontal scaling requires workarounds that should not be necessary.
The 2026 roadmap's transport work has a clear goal: make the protocol itself stateless while keeping the application layer stateful when it needs to be. The core principle from the MCP team: agentic applications should be stateful, but the protocol does not need to be. A stateless protocol enables scale. Stateful application sessions layer on top when needed.
Three specific deliverables are in development:
- Stateless Streamable HTTP: Evolve the transport so servers scale horizontally with no sticky sessions and no distributed state stores required at the protocol level. Standard Kubernetes autoscaling should work without workarounds.
- Session migration: Define how sessions are created, resumed, and migrated across server restarts and scale-out events -- transparent to connected clients.
- MCP Server Cards: A standard for exposing server metadata via a
.well-known URL. Registries and crawlers discover what a server does without making a live connection -- the same pattern that .well-known/openid-configuration brought to auth discovery.
Expected timeline: the stateless transport work is targeting the June 2026 specification release. If you are running MCP servers on Kubernetes today, you are either using sticky sessions (which caps autoscaling) or managing session state yourself. Once this ships, that complexity disappears at the protocol level. Plan your architecture to remove the workaround when June lands.
How Does the Tasks Primitive Change Async Workflows?
SEP-1686 shipped the Tasks primitive as an experimental feature in the November 2025 MCP spec revision. Tasks give MCP a call-now / fetch-later pattern: an agent fires a request, gets back a durable task handle immediately, and the actual work continues in the background. The agent polls or subscribes to the handle instead of blocking. This transforms how long-running operations work inside agent systems.
Before Tasks, every MCP tool call was synchronous. Long-running operations -- code execution, document generation, batch processing -- either timed out or required the calling agent to sit in a blocking wait that consumed context and increased failure surface. I ran into this while building a document-processing pipeline: a single PDF analysis task would push the agent past the timeout threshold on anything over 30 pages. Tasks solves the architectural problem.
The initial implementation works, but early production use has surfaced lifecycle gaps that the 2026 roadmap is closing:
- Retry semantics: What happens when a task fails transiently? Who decides whether to retry -- the requestor, the receiver, or the protocol? Currently undefined, which means every team is implementing their own retry logic.
- Expiry policies: How long are completed task results retained before garbage collection? Also undefined. Receivers are making independent decisions that requestors cannot predict, leading to inconsistent behavior across server implementations.
The Tasks protocol is requestor-driven: the side that fires the request (which can be either client or server in MCP's bidirectional model) decides when to create tasks and how to orchestrate polling. The receiver decides which requests are task-eligible and manages task lifecycle. The 2026 roadmap work closes the lifecycle gaps so both sides have a defined contract -- targeting the same June 2026 spec cycle as the transport changes.
Want the templates from this tutorial?
I share every workflow, prompt, and template inside the free AI Creator Hub on Skool. 500+ builders sharing what actually works.
Join Free on Skool
What Enterprise Readiness Really Means in Practice
The enterprise readiness pillar covers four changes. The marketing summary -- "enterprise-grade auth and audit" -- obscures what is actually different. Here is the specific version that matters to builders working on deployments that need to clear a compliance review.
SSO-integrated authentication. Current MCP auth relies on static secrets: API keys and OAuth client credentials. The roadmap moves to SSO-integrated auth that works with enterprise identity providers. Your Okta or Azure AD instance becomes the auth layer for MCP servers, the same way it already is for SaaS applications. Compliance teams can approve an MCP integration through the same process as any other SSO-enabled tool, instead of treating static secrets as a special-case security exception. This is the change that shortens enterprise sales cycles for anyone selling agent products into large organizations.
Standardized audit trails. Right now, audit trails in MCP deployments are whatever the gateway operator implements. Production gateways like MCPX already export immutable, SIEM-ready audit logs with 20+ metadata fields per interaction -- timestamps, user identity, tool parameters, and full responses -- via OpenTelemetry. The roadmap work makes this a protocol standard, not a gateway-specific feature. Every conforming MCP deployment will produce the same audit log schema.
Defined gateway behavior. Rate limiting, request routing, authorization enforcement -- currently each gateway makes independent decisions. Standardizing gateway behavior reduces integration work across deployments and makes it possible to swap gateway implementations without rewriting client configuration. IBM's Context Forge already implements mDNS-based auto-discovery for multi-gateway federations; the roadmap work formalizes the behavior contract.
.well-known discovery via Server Cards. Enterprises running internal MCP servers need a way to surface available tools to authorized users without requiring each team to maintain a separate catalog. Server Cards via a .well-known endpoint let a portal or registry auto-discover servers and their capabilities without a live connection. When this lands, building an internal MCP server directory becomes straightforward instead of a custom engineering project.
Agent-to-Agent Communication: The Gap That Is Not Closed Yet
The four roadmap priorities above are all in active development targeting June 2026. The fifth priority -- agent-to-agent communication -- is earlier in the process and will not land in the June spec. Understanding this matters if you are planning multi-agent systems now.
The problem: agents need to delegate work to other agents and get results back, with shared understanding of task state. MCP's bidirectional protocol model (both clients and servers can be requestors and receivers) provides the foundation. The Tasks primitive handles the async execution layer. What does not exist yet is a standard for how agents negotiate capabilities, hand off tasks, or handle partial failures in multi-agent workflows. Every team building multi-agent systems is inventing that coordination layer from scratch.
The Agents Working Group at MCP is working on this, but it requires multiple design iterations. Two MCP-compatible agents from different vendors being able to coordinate on a shared task without a custom integration layer is the end state. My read: agent-to-agent communication will not land in June 2026. Build multi-agent workflows today using Tasks for async work and application-level orchestration on top. Do not architect your system around protocol-level agent coordination that does not exist yet.
How to Build Around the Current Gaps
Here is the practical approach for each production gap if you cannot wait for June 2026:
Transport scaling: Use an MCP gateway -- MCPX, Docker MCP Gateway, or a custom Nginx config with session affinity -- to handle sticky sessions at the load balancer layer. Accept this as a temporary workaround. When stateless transport ships in June, removing the session affinity requirement should be a one-day migration, not an architecture change.
Tasks lifecycle: Use the Tasks primitive for async work and implement retry logic at the application layer. Track task handles in your own datastore. Treat tasks older than your chosen timeout threshold as failed and retry from the requestor side. When the protocol standardizes retry and expiry semantics, your application-layer logic becomes the edge-case fallback rather than the primary mechanism.
Enterprise auth: Run an MCP gateway with OAuth and SSO support today. MCPX and IBM Context Forge both have this. The protocol-level work standardizes the interface; the gateway layer gets you to a defensible security posture without waiting for the spec.
Discovery: Build an internal server registry as a simple JSON file served over HTTP, listing your MCP server endpoints and capabilities. When Server Cards land, migrating to the standard format is a one-day project. The structure you need to capture -- server name, description, capabilities, auth method -- maps directly to what Server Cards will formalize.
FAQ
What is the MCP Tasks primitive and how does it work?
The MCP Tasks primitive (SEP-1686) is an async execution pattern introduced in the November 2025 spec revision. Instead of blocking on a synchronous tool call, a client fires a request and receives a durable task handle immediately. The work runs in the background. The client polls the handle or subscribes to status updates. This enables long-running operations -- document processing, batch jobs, multi-step agent workflows -- without blocking the calling agent or hitting timeout limits.
When will MCP stateless transport be available?
The stateless Streamable HTTP transport is targeting the June 2026 MCP specification release. This removes sticky session requirements from horizontal scaling. Until it ships, production MCP deployments on Kubernetes need session affinity at the load balancer layer or a distributed session store for routing. The June spec should make standard autoscaling work without those workarounds.
What security vulnerabilities should MCP builders know about?
Between January and February 2026, security researchers filed over 30 CVEs targeting MCP servers, clients, and infrastructure. The most severe was a CVSS 9.6 remote code execution flaw. Common vulnerability patterns include path traversal, injection via tool call parameters, and insecure deserialization. Audit your MCP server implementations against the published CVE list before any production deployment. The 2026 roadmap enterprise readiness work addresses auth hardening at the protocol level; server-level CVEs require patching individual implementations.
How is MCP governed now that it is under the Linux Foundation?
On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation -- a directed fund under the Linux Foundation. This puts MCP on the same governance path as Kubernetes and PyTorch. Multi-vendor governance eliminates the single-vendor risk that made enterprise architects cautious about committing to MCP as infrastructure. Lead maintainer David Soria Parra continues to publish roadmap direction, but specification decisions now go through a multi-stakeholder process.
How many MCP servers exist and where do I find them?
Over 1,000 open-source MCP servers are publicly available on GitHub as of early 2026, covering database connectors, code execution environments, document processing tools, and dozens of SaaS API integrations. Discovery is currently manual -- most teams maintain internal catalogs or use gateway portals. The MCP Server Cards standard in development will formalize .well-known-based discovery, making it possible to find available servers without maintaining a separate registry.
Want the templates from this tutorial?
I share every workflow, prompt, and template inside the free AI Creator Hub on Skool. 500+ builders sharing what actually works.
Join Free on Skool
