The Model Context Protocol published its 2026 roadmap today, the same day that the July spec went stateless. If that spec was about cleaning up the protocol’s plumbing, this roadmap is about what gets built once the pipes are solid: five priority areas, no fixed release dates, and a governance shift that signals the MCP 2026 roadmap has officially moved MCP past Anthropic’s internal project phase into industry-maintained infrastructure.
Here is what matters and what developers need to track.
Agent Identity Is MCP’s Biggest Missing Piece #
MCP’s current authorization model relies on browser-based OAuth flows. That works when a human approves a connection. However, it falls apart entirely when your agent runs as a cloud workload — a Kubernetes pod, a Lambda function, a Cloud Run service — that has no browser and no human in the loop. Today, the workaround is static credentials, which is exactly as bad as it sounds.
The roadmap targets this directly with two active proposals. SEP-1932 covers DPoP (Demonstrating Proof of Possession), which cryptographically binds tokens to the client that requested them. Stolen tokens cannot be replayed — an attacker who intercepts a token does not have the matching private key. SEP-1933 covers Workload Identity Federation: instead of rotating static secrets, agents authenticate using existing cloud provider identities (AWS IAM, GCP Workload Identity, Azure Managed Identity). No new credentials to manage. No rotation schedule to miss.
Both are classified as “on the horizon” — active SEPs with Working Group attention, not guaranteed this cycle. Nevertheless, 78% of enterprise AI teams already have MCP in production, and most are managing the identity gap with workarounds. When these proposals ship, those workarounds go away. Workload Identity Federation across cloud providers is already well understood in the industry — MCP adopting it is overdue, not experimental.
Progressive Discovery Fixes the Context Window Problem #
Here is the math that production teams are hitting. An agent connecting to 10 MCP servers, each exposing 20 tools, with average JSON schemas of 500 tokens each, consumes 100,000 tokens before the user types a word. Moreover, tool selection accuracy drops from above 90% at 5–7 tools to around 13% at 100+ tools. These are not hypothetical numbers — they come from production deployments at scale.
Progressive discovery addresses this at the protocol level. Instead of front- the full tool catalog at session start, servers expose a small entry point that expands as the conversation narrows. Full schemas load on demand when an agent actually needs the tool. The current pattern forces every team to hack around context saturation independently; progressive discovery standardizes the solution. For teams running large enterprise MCP deployments, this is one of the most immediately useful changes on the roadmap.
Related:[MCP Just Went Stateless: What the 2026-07-28 Spec Changes]
No More Release Dates — Working Groups Own Delivery #
The roadmap explicitly abandons release-based timelines. “Working Groups drive the timeline for their deliverables” is the exact language used, and it changes how developers should plan against the spec. This is not a warning sign — it is how mature open standards actually work. The Linux kernel does not ship on a schedule tied to one person’s review queue. MCP, now governed by the Agentic AI Foundation under the Linux Foundation, is following the same model.
Consequently, the mechanics matter. Working Groups with a proven track record can now accept Specification Enhancement Proposals (SEPs) and publish extension updates within their domain without a full core-maintainer review cycle. A formal contributor ladder exists: community participant, WG contributor, WG facilitator, lead maintainer, core maintainer. Every Working Group runs a public charter with scope, deliverables, and success criteria — reviewed quarterly. If your team needs a feature, the path to shipping it is joining a Working Group, not waiting for a core team release window.
The tradeoff is real: if your team planned roadmaps against fixed MCP spec versions, that model needs to change. Track individual SEPs through Working Groups instead of waiting for a spec release announcement.
Tasks Gets Retry Logic; Transport Split Closes #
Two additional roadmap items, both worth tracking. The Tasks extension — which handles long-running async tool calls — shipped experimental in the July spec. Production use revealed concrete gaps: no retry semantics for transient failures, no expiry policy for completed task results. The roadmap closes both. Furthermore, if you are building agents that call tools with real execution time (file processing, code execution, external APIs with unreliable latency), retry semantics directly affect reliability at scale.
On transport: the July spec made remote MCP servers standard HTTP workloads. The roadmap extends the same model to local servers via Streamable HTTP over stdio, closing the two-transport-pattern split that has made deployment mental models more complex than necessary. The roadmap also adds .well-known metadata discovery, so server capabilities are discoverable without a live connection — cleaner API gateway and service mesh integration follows directly from that.
What Developers Should Do Now #
Three concrete actions if MCP is part of your stack. First, track SEP-1932 and SEP-1933 closely — agent identity is the most consequential change coming, and migrating off static credentials will require planning time before the proposals ship. Second, if you are hitting context window saturation from tool catalog size, evaluate how you would restructure server tool exposure to work well with progressive discovery once it arrives — the protocol will support it, but server-side changes are on you. Third, if your team needs a specific feature, review the official MCP 2026 roadmap and engage the relevant Working Group — participation is open, and WGs now have authority to ship without waiting for the core team.
Key Takeaways #
- Agent identity via DPoP and Workload Identity Federation is MCP’s most impactful upcoming change — cloud agents running on static credentials finally get a proper fix
- Progressive discovery addresses the tool catalog context window problem at the protocol level, not through per-team workarounds
- MCP now operates on Working Group-driven delivery — track SEPs, not spec release announcements
- Tasks extension gets retry semantics and expiry policies; the local/remote transport split closes this cycle
- To influence what ships, join a Working Group — the governance model now gives WGs authority to ship independently of the core team