By MCP went stateless on July 28. That spec shipped with a wave of breaking changes — every production server had to migrate. Twenty-five days later, on August 22, the maintainers published the roadmap for what comes next. If you’re building agents, MCP servers, or anything that connects the two, this document deserves more attention than it’s getting. Five priority areas. Here’s what they actually mean for your architecture.
1. Stop Building Polling Workarounds — Server Events Are Coming
The 2026-07-28 spec made MCP stateless, which is the right architectural move. It also left a gap: there’s no push mechanism. If your agent needs to know when something changes on the server, it has to poll. The roadmap’s first priority directly addresses this with server-initiated events — webhooks and channels — so agents stop wasting cycles asking “anything new yet?”
The Triggers and Events Working Group is actively speccing the callback mechanism, subscription lifecycle, delivery guarantees, and event ordering. This is real work in progress, not vaporware. The practical advice: if you’re wiring up long-polling as a temporary fix, don’t invest in it. Design the interface you’ll eventually need; don’t couple your server to a pattern that’s already marked for replacement.
2. API Keys Are the Wrong Bet for Production MCP Servers
The current auth story for MCP is pasted API keys and long-lived tokens. That works fine for a local dev tool talking to your own services. It’s a liability the moment an agent is running as a cloud workload, acting on behalf of a user who isn’t there, or delegating to a sub-agent.
The roadmap is explicit about where this is going: DPoP (Demonstrating Proof of Possession) binds a token to a cryptographic key so a stolen token can’t be replayed. Workload Identity Federation lets a running agent exchange its platform identity for short-lived access instead of carrying a static API key. The ID-JAG grant brings enterprise identity providers into the MCP auth flow. Standard token exchange handles cross-domain delegation without turning one long-lived secret into a master key.
If you’re building an MCP server that will connect to enterprise systems, design around the assumption that long-lived API keys are going away. The protocol is moving toward zero-trust agent identity built on existing standards — and the migration will be easier if you haven’t hardcoded API key assumptions throughout your auth layer.
3. The 100K-Token Context Problem Has a Protocol-Level Solution
By Q1 2026, a typical production agent was connecting to between five and twenty MCP servers. Each server exposes five to fifty tools with JSON schemas that rarely run under 300 tokens. Before the user types a single word, the agent’s context window is burning through roughly 100,000 tokens on tool definitions.
The roadmap names the fix: progressive tool discovery. Instead of dumping an entire tool catalog into context at session start, a server exposes a small entry point — a search_tools tool — and reveals more as the conversation narrows. The maintainers are putting protocol-level support behind this pattern because it’s becoming a genuine scalability problem. If your server exposes 50 or more tools, start thinking about progressive disclosure now, before the protocol formalizes it around you.
4. The Tasks Extension Is the Safe Bet for Long-Running Work
Tasks moved from experimental to an official extension (SEP-2663) in the 2026-07-28 spec. The redesign replaced the blocking tasks/result call with polling via tasks/get, added tasks/update for client-to-server input during a task, and removed tasks/list. Servers can now return task handles unsolicited — no per-request opt-in required.
The extension is identified as io.modelcontextprotocol/tasks, and the roadmap puts it explicitly on the path to core protocol inclusion. Don’t wire up custom task management patterns when the protocol is actively maturing a standard one. The Tasks extension is the right abstraction; build on it.
5. One Transport Model for Local and Remote
MCP currently maintains two transport pipelines: stdio for local servers, Streamable HTTP for remote ones. Every HTTP-native feature needs a second stdio-specific design, and SDKs duplicate protocol metadata across both. The roadmap’s fix is Streamable HTTP as the single binding, spoken over HTTP/2 over stdio for local servers — one transport model, less SDK complexity. If you’re maintaining MCP SDK integrations, this abstraction is about to simplify significantly.
What to Do Right Now
The roadmap was published August 22 and hasn’t gotten the attention it deserves. But that’s exactly when architecture decisions matter most — before the spec ships, not after.
- Building an MCP server: Don’t invest in custom push implementations — design the interface for webhooks now.
- Handling auth: Move toward short-lived tokens. Design around Workload Identity, not API keys.
- Large tool catalog (50+ tools): Start prototyping progressive discovery patterns before the protocol formalizes it.
- Long-running agent operations: Build on the Tasks extension (
io.modelcontextprotocol/tasks). It’s on the path to the core.
One more thing: the roadmap includes a 12-month minimum between deprecation and removal. After the disruption of the 2026-07-28 spec, this is a meaningful stability commitment. You can plan to it.
