MCP's New Roadmap: Agent Identity, HTTP Unification, and Better Tool Results
The New MCP Roadmap
The Model Context Protocol (MCP) has published an updated roadmap for the next specification release and beyond, organized into five priority areas. These include agentic messaging primitives (server-initiated events, maturing the Tasks extension), HTTP-native transport unification (extending Streamable HTTP to stdio), agent identity and enterprise-ready security (DPoP, Workload Identity Federation), improved primitives (standardizing tool result contracts, progressive discovery), and improved SDK developer experience. The roadmap also outlines proposal prioritization, with SEPs in these areas getting expedited review.
A tools/call response can carry the same output in more than one form, and a server developer today has no way to know which form a given client will put in front of the model.
- rco8786
> With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload
Good. Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release.
- izend
I am very curious how many MCP servers will actually implement all of this:
"MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens.
The work here covers finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and WIMSE working groups, to help the underlying standards evolve with the building blocks that agent identity needs."
- cube00
I still struggle to see how a MCP endpoint is easier for agents to work with compared with a REST endpoint and a skills.md file.
- mmaunder
My dream was for MCP to allow services like ours (cybersecurity) to provide a self documenting endpoint with authentication, and we just give users a URL and it just frikkin works. Instead from day 1 it’s been multiple standards as they pivoted, a context hungry feature, and feels like a kludge. That burned the idea of MCP for me and I’ve had such success with local tools and APIs that it’ll take a lot for me to go back.
- mikeegg1
When I see "MCP" I still translate that to Master Control Program.
- rglover
The degree to which this idea has been overcomplicated is confusing. This could have been solved with some relatively simple patterns wrapped around HTTP and WebSockets (and if absolutely necessary, SSE).
- vatsachak
Why not just give the model a prompt?
Every gain in LLMs is either through increases in compute efficiency, Architecture or Harnesses...
The rest seems like bells and whistles
- skinfaxi
> We’re starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows.
Kind of late to the party. I've had to implement lazy loading of mcps in a couple of harnesses now but am moving to implement everything as code mode instead.