MCP's Updated Roadmap Targets the Three Things Blocking Production Agents: Async Tasks, Agent Identity, and One HTTP Transport
The Model Context Protocol refreshed its official roadmap on August 22 with five priority areas for the next 6-12 months. The headline moves: server-initiated events, DPoP and workload identity to kill pasted API keys, and HTTP/2 over stdio as a single transport.
The Model Context Protocol’s core maintainers published a refreshed roadmap on August 22, laying out five priority areas for the next six to twelve months. Read together, they describe a protocol done proving the concept and now grinding through what actually blocks production deployments: long-running work, agent authentication, and a transport story that stopped making sense.
The most consequential area is agentic messaging. MCP has accumulated three overlapping answers to “the server isn’t done yet” — Tasks, subscriptions/listen, and progress notifications — spread across separate working groups. The maintainers name the risk plainly: three primitives that don’t share a lifecycle, a cancellation model, or an error surface. This cycle commits to server-initiated events, including webhooks, so servers can tell clients when async work finishes instead of forcing expensive client-side polling. The Tasks extension (SEP-2663) keeps moving toward inclusion in the core protocol.
Identity is the second big bet. MCP authorization was designed around a person approving access in a browser. Increasingly the caller is a cloud workload with its own identity, acting for a user who isn’t present — or spawning sub-agents that should get narrower authority than their parent. Today’s servers lean on pasted API keys and long-lived refresh tokens. The new Agent Identity working group will finalize DPoP (Demonstrating Proof of Possession) and build delegation on existing standards: Workload Identity Federation (SEP-1933), the ID-JAG assertion grant, and RFC 8693 token exchange, coordinated with the IETF OAuth working groups. If your MCP server still authenticates with a token in an env var, this is the part of the spec to watch.
The transport plan is the most opinionated. The July 28 spec release made a remote MCP server a normal HTTP workload — but every HTTP-native feature still needs a second stdio-specific design, and SDKs maintain two transport pipelines. The proposed fix: Streamable HTTP as the single binding, spoken as HTTP/2 over stdin/stdout for local servers. One transport model, standard HTTP practice on top, including ETag-based caching for tool call results.
Rounding out the list: a redesign of the confusing tools/call dual return shape (content vs structuredContent), progressive discovery so clients learn tools as needed instead of ingesting full catalogs up front, and an experiment generating SDKs directly from the spec plus a conformance suite.
None of this is a firm commitment — the maintainers say so explicitly. But SEPs inside these areas get expedited review, which makes the roadmap a reliable map of where the protocol’s scarce review time goes. For anyone building agents on MCP, the direction is clear: fewer primitives that compose better, and identity that survives an enterprise security review.