Magic Tools
Developer ToolsBy CooconAugust 23, 202611 views4 min read

MCP Just Published a New Roadmap: Agent Identity, DPoP, and Streamable HTTP Everywhere

MCP Just Published a New Roadmap: Agent Identity, DPoP, and Streamable HTTP Everywhere

On August 22, the Model Context Protocol team published an updated roadmap covering the next spec release and beyond. It's the clearest signal yet that MCP is moving from "client calls a tool" to "agent talks to agent."

"Modern agentic workloads no longer fit the standard request-and-response pattern."

That's the official line. Let's unpack it.

What problem is this roadmap solving?

MCP's biggest win over the past year was making "let an LLM call tools" a de facto standard. But agentic workloads have changed: loops run for hours, servers need to push streamed results, and work needs to be steered mid-flight. The old request-and-response pattern doesn't fit anymore.

The Core Maintainers built the roadmap together with community Working Groups, and organized it into five priority areas — each with named maintainers and at least one Working Group.

The five priority areas, side by side

Area Core content Key moves
Agentic messaging primitives Long loops, streamed pushes, mid-flight steering Mature Tasks extension (SEP-2663) into the spec
HTTP-native transport unification Remote and local servers on one transport Streamable HTTP over stdio
Agent identity & enterprise security Cloud agents with their own identity Finalize DPoP + Workload Identity Federation
Improved primitives Unified tool result contract, progressive discovery Standardize tools/call output
SDK developer experience Cross-language SDKs, spec conformance Better conformance testing

Agentic messaging: from "one question, one answer" to full supervision

This is the most substantive change on the roadmap. The official quote:

"We want to make sure that we not only offer the right primitives for the job, but also that they work well together."

Three concrete moves: server-initiated events (webhooks and channels, so clients stop polling for results), maturing the Tasks extension (SEP-2663, moving from experimental into the specification), and a composition review across the Agents, Transports, and Triggers & Events Working Groups.

The direct impact for developers: MCP servers can push events to clients instead of waiting to be asked "are we there yet?" Long-running tasks shift from polling to subscription.

Agent identity: the most "enterprise" piece of the roadmap

Today, MCP authorization is "a human clicks approve in a browser." That works for interactive clients — but more and more callers are agents running as cloud workloads: they have their own identity, act on behalf of a user who isn't present, or delegate narrower authority to sub-agents.

The plan: finalize Demonstrating Proof of Possession (DPoP, RFC 9449) and drive adoption, plus Workload Identity Federation (modelcontextprotocol/modelcontextprotocol PR #1933) and Enterprise-Managed Authorization (ID-JAG grant) — built on standard token exchange instead of pasted API keys and long-lived tokens.

In one sentence: agents get ID cards, not keychains.

Improved primitives: servers with a hundred tools make the model pay full price up front

Here's a sharp detail: connecting to a server with a hundred tools means the model pays for the entire surface before the user has asked a single question — and tool selection gets worse as the list grows.

The fix is progressive discovery: a server offers a small entry point and reveals more of its catalog as the conversation narrows. For servers with huge tool surfaces (cloud platforms, databases), this is a real optimization.

The counterargument: the roadmap is complete, but how long until it ships?

Optimistic view: SEP-2663, DPoP, and Workload Identity Federation aren't new proposals — they matured enough to become priorities. Pessimistic view: the previous roadmap (early 2026) listed server-initiated events, result type improvements, and agent identity as "on the horizon," and only now have they become priorities. Spec evolution is slower than the community hopes.

One more thing: SEPs inside the priority areas get expedited review; proposals outside aren't rejected outright, but "maintainer review time is scarce and goes to these areas first." If you're writing a SEP, pick your lane carefully.

What you can do today

  1. Read https://modelcontextprotocol.io/development/roadmap and find the Core Maintainers and Working Groups for the area you care about.
  2. If you build MCP servers: watch the Streamable HTTP unification — local servers running over stdio should eventually switch to HTTP seamlessly.
  3. If your server has a big tool surface: track progressive discovery, because it will change how you organize tools.

Pick the area that touches your stack and start following its Working Group — the spec is being written right now, with or without you.

FAQ

Q: When was the new MCP roadmap published? A: August 22, 2026, on the official MCP blog, with the full roadmap updated at modelcontextprotocol.io/development/roadmap.

Q: What are the five priority areas? A: Agentic messaging primitives, HTTP-native transport unification and hardening, agent identity and enterprise-ready security, improved primitives (tool result contract + progressive discovery), and SDK developer experience.

Q: What's the direct impact for regular MCP developers? A: Short term, server-initiated events and the Tasks extension turn long tasks from polling into subscription. Medium term, Streamable HTTP unifies local and remote transports. On security, DPoP and Workload Identity Federation replace pasted API keys.

✨ 本文由 DeepSeek 生成初稿,Claude 审核润色。

Sources:

Related Articles

Fable 5 Tops the NanoGPT Speedrun: 153 Autonomous Runs, 18 Models, and Who's Really Closing the Gap on Humans

Prime Intellect's NanoGPT Speedrun Frontier compares 18 frontier models across 153 autonomous runs. Fable 5 tops the board at 2,726 steps, closing 81.7% of the gap to the human record. Full leaderboard breakdown, harness analysis, and efficiency comparison.

developerAug 23, 20264 min
13

Someone spent 4 months building a Rust LSP that uses 100x less memory

One developer spent four months building Rust Glancer, a Rust LSP that stays under 100MB of memory — two orders of magnitude leaner than rust-analyzer, endorsed by matklad himself. The frozen-analysis-plus-on-demand-loading trade-off, the 1% vs 99% rowan debate, and who should actually switch.

developerAug 23, 20263 min
17

Dev Breakfast · 2026-08-23

Today's headline: a Rust LSP using two orders of magnitude less memory—Glancer makes 8GB machines viable again. Plus 6 more: Claude Code reportedly A/B testing lowered effort levels; MCP publishes a new roadmap with five priority areas; and more.

daily-intelAug 23, 20267 min
30

Qwen3.8-27B + DFlash 2 on a 24GB Mac mini: a Measured 1.8x, and Why You Won't Get the Official 3x

One week after DFlash 2 shipped, I got Qwen3.8-27B with speculative decoding fully working on a 24GB Mac mini M4: 6.5 tok/s to 11.7–12.2 tok/s at 4-bit, a stable 1.8–1.9x. This post covers the exact deployment commands, three controlled benchmark rounds, the GB-by-GB memory budget, and the three concrete reasons the official 2.7–3.4x number shrinks on consumer Apple Silicon.

qwendflash+6
ai-tutorialsAug 23, 20266 min
22

Published by Magic Tools