The Updated MCP Roadmap: Agents, Transport and Enterprise Security

The Model Context Protocol (MCP) team has released an updated roadmap that charts the direction of work on the protocol for the months ahead. The document was put together by the core maintainers along with the community and working groups, and it is broken down into five priority areas. A number of tasks have graduated into the priority list from among those that the previous roadmap only sketched out as long-term goals — among them server-initiated events, better result types, and agent identity.

Primitives for agents

Modern agentic workloads no longer fit the “request–response” mold: loops run longer, servers return streaming results, and the process sometimes needs to be steered on the fly. MCP responds to this with Tasks, subscriptions, and progress notifications. Now the authors want not only to offer the right primitives but to make them work together seamlessly. This includes server-side events (webhooks and channels, so that clients don't have to poll the server in a loop) and taking the Tasks extension all the way to inclusion in the specification.

A unified transport

Since the July 28, 2026 release, a remote MCP server is no different from an ordinary HTTP workload, and it can be hosted on any infrastructure already used for APIs. The model scales well, and the plan now is to extend it to other deployment modes, including local servers running over Streamable HTTP on top of stdio. Unifying the transport is meant to simplify the development of both clients and servers.

Agent identity and enterprise security

Today, authorization in MCP is built around a human confirming access in a browser. But increasingly the calls come from agents — cloud workloads with their own identity, acting on behalf of an absent user or delegating authority to sub-agents. MCP needs a standard way to recognize and trust such agents, drawing on existing standards rather than on manually inserted API keys and long-lived tokens. The work covers finalizing the DPoP mechanism, federating workload identity, and closer collaboration with the IETF's OAuth working groups.

Primitives and SDK ergonomics

Calling tools — where most developers begin — has largely proven itself, but handling results needs more work: a response may carry the same output in several forms, and the server doesn't know which of them the client will show the model. The solution will be a single, clear contract. A separate problem is the growing number of tools: connecting to a server with a hundred tools forces the model to “pay” for that entire surface before the first question is even asked. The answer will be progressive disclosure of the catalog as the conversation narrows. Finally, the team is investing in the ergonomics and accuracy of the SDK documentation — all the more so now that code for MCP is increasingly written by pointing an agent at its own libraries.

Source: Hacker News