The Load-Bearing Line: Request-Response No Longer Fits the Work
The roadmap opens with the judgment that "modern agentic workloads no longer fit the standard request-and-response pattern." Tasks that run for tens of minutes, results that stream as they arrive, a user steering mid-flight — inside a strict question-and-answer frame, all of that gets simulated by a client polling in a loop. The existing Tasks extension (SEP-2663), subscriptions and progress notifications are patches over that gap; what comes next is events the server initiates itself, via webhooks and channels, pushing results the moment they exist. The Tasks extension is also slated to move out of experimental status and into the specification proper.
Transport Converges, Identity Changes Tracks
The transport work continues from the July 28 spec release. With protocol-level sessions removed there, remote MCP servers can be deployed and scaled horizontally like ordinary HTTP workloads; the goal now is to bring local servers into the same transport — Streamable HTTP over stdio — so remote and local stop being two separate mental models. Identity is the deeper change. Today's authorization flow assumes a person is standing behind it, clicking approve in a browser. An agent running as a cloud workload needs an identity that can be recognized, not a long-lived API key. The named mechanisms are DPoP (RFC 9449, which binds a token to a key its holder proves possession of), workload identity federation, and the ID-JAG grant from the now-stable enterprise-managed authorization extension, with maintainers working inside the IETF OAuth and WIMSE groups on the underlying standards. For enterprises, this decides whether a call into an internal system can be audited down to which workload made it.
A Hundred Tools Is a Bill
The fourth priority contains the most concrete line in the document: connecting to a server with a hundred tools means "the model pays for that entire surface before the user has asked a single question." The answer is progressive discovery — a server reveals its catalog gradually as the conversation narrows, rather than dumping everything into context at connect time — alongside standardizing the tool-result contract so implementations stop inventing their own return shapes. If you maintain an MCP server, the practical use of this document is as a proposal filter: a change that lands in one of the five areas has a much better path through the SEP process, and anything outside them isn't forbidden, just unqueued. Don't skip past the missing dates either — this is a statement of priorities, not a release schedule.