MCP roadmap prioritizes agent messaging, HTTP transport unification, and workload identity
- The updated MCP roadmap sets five priorities for the next specification release and later work: agent messaging, HTTP transport, agent identity and security, improved primitives, and SDK developer experience.
- MCP plans to mature the Tasks extension (SEP-2663) for inclusion in the specification, while adding server-initiated events such as webhooks and channels so clients need not poll for long-running results.
- After the 2026-07-28 release, remote MCP servers use the same HTTP model as other web workloads; the roadmap aims to extend Streamable HTTP to local servers over stdio and unify transport choices.
- For noninteractive agents, MCP plans standardized agent identity and delegation using DPoP, Workload Identity Federation, the ID-JAG grant for Enterprise-Managed Authorization, and token exchange rather than API keys or long-lived tokens.
Hacker News opinions
I have already had to lazily load MCPs in a couple of harnesses. This progressive discovery work feels late, and I am moving toward code mode instead.
What do you mean by code mode?
The messaging direction reminds me of the actor model, especially long-running work and server-originated events.
I am curious how many MCP servers will actually implement this identity stack. DPoP, workload identity federation, ID-JAG, token exchange, and OAuth standards work is a lot to absorb.
An MCP server does not need to implement every security option itself. An auth proxy such as agentgateway can handle that layer for MCP servers.
This feels overengineered. Why not just use OAuth?
Browser approval is already a bottleneck for serious agent use, so agent identities and delegated authority are directionally necessary. Agents will end up doing much of the migration work too.
I see two possible paths: workloads using established credentials with RFC 7523 and OIDC discovery, or DPoP requiring signed proof on each request. I am not sure whether existing non-human identity systems can scale with DPoP or whether the paths split.
I hope many servers adopt it. Fully enabled agents could remove a lot of human-in-the-loop steps, though projects like projects.dev also show how many security problems remain.
Making remote MCP look like ordinary HTTP is good. The original bespoke protocol choice was a bad idea.
I have not needed MCP despite building AI software. Regular HTTP APIs plus OpenAPI are enough for my agents, and they retain decades of tooling and normal HTTP semantics instead of JSON-RPC POST payloads and custom introspection.
I added an MCP to my personal finance app and connected Claude mainly for testing. While discussing gardening purchases, it brought up my home-improvement budget, then my retirement plan, which made the broader context useful in a way I did not expect.
Developers may not need MCP, but nontechnical customers will not use Claude skills through a CLI. If they need ChatGPT or Claude Desktop to access a CRM or ERP product, MCP is a practical integration route.
The changing spec makes existing work expensive to maintain. MCP looks like it is becoming stateless, and I now understand why senior developers told me to wait three years before relying on new technology.
Stateful MCP in version 1 was deployment-unfriendly because it required persistence. It still looks like a complicated way to expose an OpenAPI service to AI.