The New MCP Roadmap: Five Priorities, One HTTP Transport to Rule Them All (0822)
The New MCP Roadmap: Five Priorities, One HTTP Transport
If you're wiring MCP servers into Claude, Cursor, or your own agents, yesterday's roadmap update from the MCP team is worth three minutes of your time.
The short version: MCP is shifting from a tool you authorize in a browser to a cloud-native protocol that agents use on their own. That's not my editorializing — it's where all five priority areas point.
The five priority areas
The roadmap breaks into five buckets, each owned by Core Maintainers plus a Working Group:
- Agentic messaging primitives
- HTTP-native transport unification and hardening
- Agent identity and enterprise-ready security
- Improved primitives
- Improved SDK developer experience
I'll dig into the three that matter most. The other two are polish.
Priority 1: long-running work no longer fits request-response
One line in the roadmap nails it, so I'll quote it verbatim:
Modern agentic workloads no longer fit the standard request-and-response pattern.
Agent loops now run longer, servers push streamed results, and you need to steer work mid-flight. MCP has already shipped Tasks, subscriptions/listen, and progress notifications to cover this. This round is about making them work together cleanly — server-initiated events (webhooks and channels so clients stop polling), and maturing the Tasks extension (SEP-2663) so it can move into the spec.
What it means for you: if you're polling for long-task results today, get ready to delete that. Polling is the ugliest hack in MCP, and the team is finally going to kill it.
Priority 2: HTTP everywhere, stdio included
Of the five areas, here's the signal I'm watching closest. Verbatim:
With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload.
Translation: a remote MCP server is just an HTTP service now. Host it wherever you host your APIs. This round pushes further — local servers speaking Streamable HTTP over stdio, so there's one transport to rule them all.
For teams, the bar for operating an MCP server drops to "can you run Nginx or K8s."
One counter-intuitive caveat: don't rush to migrate your stdio servers. Streamable HTTP over stdio is still in progress. Wait for the SDKs to catch up — migrating now is volunteering for pain.
Priority 3: agent identity — say goodbye to pasted API keys
Enterprise-flavored as it sounds, I'd argue this one decides whether MCP stays a toy or actually makes it into production.
Today, MCP authorization is built around a human approving access in a browser. The roadmap names the problem directly:
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.
The fix isn't another bespoke scheme — it's standing on existing standards:
- Finalize and drive adoption of DPoP (Demonstrating Proof of Possession, RFC 9449)
- Define an opinionated path for agent identity and delegation via Workload Identity Federation
- Keep aligning with IETF OAuth and WIMSE working groups
Bottom line: API keys and long-lived tokens are on their way out of MCP's identity story, replaced by proof-of-possession and identity federation. Good riddance — the key-pasting model never scaled to agent scenarios anyway.
Priorities 4 & 5: primitives and SDK polish
Improved primitives targets two concrete annoyances:
- A
tools/callresponse can carry the same output in multiple forms, and the server dev has no idea which form a given client will feed the model → standardize one clear contract - Connecting to a server with a hundred tools means the model pays for the whole surface before the user asks anything → progressive discovery, so a server exposes a small entry point and reveals more as the conversation narrows
Improved SDK developer experience comes down to one line: more developers now build MCP clients/servers by pointing an agent at the libraries, so API clarity and doc accuracy directly decide whether the code works.
What this means for SEPs
The roadmap also sets the rules for SEP (Specification Enhancement Proposals):
Proposals outside them aren't rejected automatically, but maintainer review time is scarce and goes to the roadmap first.
Proposals inside the five areas get expedited review. Others aren't auto-rejected, but they wait. If you're drafting a SEP, find your priority area and work the relevant Working Group first — don't cold-drop it.
What you can do today
- Audit your MCP servers for polling — if you're polling for results, watch Tasks and server-initiated events and prepare to switch
- If you deploy remote MCP for a team, treat it as a plain HTTP service and reuse your existing API hosting, not a bespoke deploy script
- If you have agent identity needs (cloud agents, sub-agent delegation), start tracking DPoP and Workload Identity Federation instead of stacking more API-key patches
FAQ
Q: Did Anthropic dictate this roadmap unilaterally? No. The post says it was developed by the Core Maintainers together with community maintainers and Working Groups. Every area names its responsible Core Maintainers, and contributors can reach them on Discord.
Q: Should I migrate my stdio MCP servers right now? No. Streamable HTTP over stdio is still in flight, and existing stdio servers keep working. Wait for SDK support to mature before migrating.
Q: What is progressive discovery and why does it matter? It lets a server show the model a small entry point (a few tools) and reveal more only as the conversation narrows. It fixes the problem where a hundred-tool server makes model selection worse and burns tokens before the user even asks a question.
Sources:
