Rohit Ghumare · August 22, 2026 · 12 min read

MCP's New Roadmap: Events Without Sessions, Identity Without API Keys

On August 22, 2026, the Model Context Protocol's lead maintainers published a new roadmap, five months after the 2026-07-28 release deleted the protocol's sessions and its handshake. I wrote about that subtraction when it landed. This roadmap is the addition column: everything a sessionless protocol lost, being given back one primitive at a time, without giving back the session. A server can ask the client a question mid-call again, but the question is a result and the memory rides with the client. A server can push again, but the subscription is a request still in flight. An agent can hold a credential again, but the credential is bound to a key the thief does not have. Five priority areas, three of them mechanisms worth drawing.

Five months, one subtraction, four deliveries

The March roadmap named four areas: transport evolution and scalability, agent communication, governance maturation, and enterprise readiness. Reading the August post against the July changelog, most of it landed. Protocol-level sessions and the initialization handshake are gone (SEP-2575, SEP-2567). A client can call server/discover to learn versions and capabilities before doing anything else. List results carry ttlMs and cacheScope so a client can cache them (SEP-2549). Tasks moved into an official extension (SEP-2663). Server-initiated requests were replaced outright by Multi Round-Trip Requests (SEP-2322). Authorization gained issuer validation, issuer-bound client credentials, Client ID Metadata Documents as the preferred registration path, and a stable Enterprise-Managed Authorization extension. The governance items are real too: a contributor ladder, Working Groups that triage their own SEPs, and a feature lifecycle with a deprecation policy that the July deprecations were the first to follow.

That is the baseline the new roadmap starts from. It has five priority areas, each with named Core Maintainers and a Working Group, and the maintainers say SEPs inside those areas get expedited review while everything else waits in a longer queue. The table is the map; the rest of this essay walks the three areas where the mechanism is the story.

Condensed from the roadmap page (last updated 2026-08-22). The page calls itself "current thinking rather than firm commitments."

Elicitation without a waiting server

Start with the hardest thing the stateless core had to give up: a server asking the client a question in the middle of a tool call. Elicitation, sampling, and roots all worked that way, and all three were built on the server holding the call open while the answer came back on a separate request. The SEP that replaced them opens with the failure, and it is the failure from the load-balancer figure in the last essay, seen from the tool author's chair. The client's tools/call lands on instance A. A opens a stream and sends the elicitation request. The user answers, the client POSTs the answer, and the balancer sends it to instance B. "Server A must somehow discover the elicitation response delivered to server B." The two known fixes are a shared store (Redis, Postgres, DynamoDB) or sticky routing, and the SEP spends a page on why both are the wrong price for a weather tool. The store becomes a critical dependency, a bottleneck, and a garbage-collection problem, because a human might answer in a minute, a month, or never. Sticky routing breaks the load model and dies with the instance.

The replacement is almost rude in its simplicity. The server answers the original call with a result whose resultType is input_required. That result carries inputRequests, a map from server-chosen keys to ordinary elicitation or sampling requests, and optionally requestState, an opaque string. The original request is now over; nothing is held. The client collects the answers and sends a new tools/call with a new JSON-RPC id, the same arguments, an inputResponses map keyed the same way, and the requestState echoed back byte for byte. Whichever instance receives it reconstitutes the state from the request itself and either finishes or asks again. The SEP's own example is an Azure DevOps rule chain: resolving a bug requires a resolution, and a resolution of Duplicate requires the original item, so the server asks twice, and on the second round it packs the already-collected answer into requestState so that "it is available regardless of which server instance handles the next retry."

Three details carry the security of that design, and they are in the spec as MUSTs. The client must never inspect or modify requestState; it is an opaque blob. The server must always validate it, because the client is an untrusted intermediary that can hand back anything. And if the state carries anything specific to a user, the server must bind it to that user cryptographically and check the binding on the retry, because an authenticated attacker can replay a state string that was minted for someone else. The SEP suggests AES-GCM or a signed JWT, and it is worth noticing that the pattern is an old friend: this is a stateless web session cookie, invented again for JSON-RPC. The web learned to sign its cookies in the 2000s. MCP tool authors get to learn it in 2026, with the reasons written down first.

Two boundaries keep the mechanism small. Only four client requests may come back input_required: tools/call, prompts/get, resources/read, and tasks/result. Everything else (lists, ping, cancel, complete) is single-shot by rule. And the ephemeral flow is for ephemeral tools. A tool that accumulates real state, an agent, a VM, a job that must keep computing while the user thinks, uses Tasks instead: the task status flips to input_required, the client reads the requests from tasks/result, and answers with a new method, tasks/input_response. Same data structures, different lifetime. The SEP is honest about the cost to programmers: the old await elicit() style inside a tool function becomes legacy, and the new style is a function that takes state in, does work, and either returns a result or returns an incomplete response. Less pleasant to write. Portable from a single stdio process to a fleet without a rewrite.

Push without a session

The other thing sessions used to buy was the server's ability to talk first. In the 2025 transport a client opened a long-lived GET and the server pushed notifications down it. In 2026-07-28 that GET is gone and subscriptions/listen replaced it: a client sends one request with a notifications filter (toolsListChanged, resourceSubscriptions by URI, and so on), the server acknowledges with a subscription id in _meta that equals the JSON-RPC id of the request, and every later notification carries that id so a client on stdio can demultiplex several streams over one pipe. The server may not send a notification type the client did not ask for. When a stdio connection drops, the client re-sends subscriptions/listen, because "the server holds no subscription state across reconnections." Push, without a session, by making the subscription itself a request that is still in flight.

The roadmap's first area is what that leaves unsolved. Tasks report progress by being polled. Subscriptions deliver change notifications while a stream is open. Progress notifications ride along with a request. The maintainers' own diagnosis: "three answers to 'the server isn't done yet' that don't share a lifecycle, a cancellation model, or an error surface." Two deliverables follow. Server-initiated events through channels and subscriptions, including webhooks, so a client that kicked off a long task is not paying to poll for the end of it. And a composition review across the Agents, Transports, and Triggers & Events groups so that Tasks and Triggers fit each other before either hardens into the core spec. If that sounds familiar, it is because A2A solved the same triangle with one task state machine, one streaming rule set, and one webhook contract, and paid for it with a heavier spec. MCP is trying to get there by composition, from the stateless side.

One transport, spoken over stdin

The transport area reads like a maintenance note until you see what it removes. After July, a remote server is "a normal HTTP workload," and the protocol now leans on HTTP headers and status codes for transport-level facts. But there are two transports. Every HTTP-native feature needs a second stdio design or does not work locally; SDKs keep two pipelines; and the same metadata is now duplicated across headers and message fields that servers have to cross-validate. The proposal is Streamable HTTP as the single binding, spoken over stdin and stdout for local servers, with HTTP/2 giving multiplexing while the subprocess keeps its lifecycle and security guarantees. One pipeline, and the local server becomes a special case of the remote one instead of a separate dialect. The caching thread continues from SEP-2549: ETags on primitive results, "in particular tool calls," which would let a client skip re-reading a result it already holds. And the scope note at the end, capability scoping for tool lists after SEP-2575, is the hook the next section hangs on.

Identity for callers who are not in the room

Here is the sentence that dates the current authorization spec: "MCP authorization today is built around a person approving access in a browser." The person consents, the client gets a token, the token is a bearer token, and the server trusts whoever presents it. That model fit a desktop client in 2025. It does not fit the callers the roadmap lists: a cloud workload with its own identity, an agent acting for a user who is not present, a parent agent delegating narrower authority to sub-agents. What fills the gap today is "pasted API keys and long-lived tokens," and the roadmap says so.

The plan has three standards in it, all borrowed. Demonstrating Proof of Possession (RFC 9449) binds an access token to a key pair the client holds. Workload Identity Federation (SEP-1933) lets a workload prove who it is without a pasted secret. The Identity Assertion JWT Authorization Grant behind Enterprise-Managed Authorization, plus RFC 8693 token exchange, let an agent carry a user's delegated authority and narrow it for a sub-agent. The maintainers say they will work inside the IETF OAuth and WIMSE groups rather than around them, and they float human-presence attestation, a way for a server to tell an interactive client from a headless agent, as a topic the forming Working Group may pick up.

DPoP is the one to understand mechanically, because it changes what a stolen credential is worth. With a bearer token, the string is the secret: anyone who reads it from a proxy log, a crash dump, or a browser's cookie jar can use it. The same failure class made news this week in a different product: BleepingComputer reported on August 30 that infostealer malware was lifting authenticated Claude sessions from users' machines and spending their usage, and the vendor's email noted the attacker "may not need to go through the normal password and 2FA login process again." That is what a bearer credential is: possession is authorization. Under DPoP the client generates a key pair, and every request carries a short proof JWT signed with the private key: htm (the HTTP method), htu (the URL), iat (when), jti (a unique id, single use), and ath (a hash of the access token). The token itself carries cnf.jkt, the thumbprint of the public key. A server checks the signature, the thumbprint, the method, the URL, the freshness, and whether it has seen that jti before. Steal the token and you still cannot mint a proof. Steal a proof and it is signed over one method and one URL and burns on first use.

None of that is MCP-specific, which is the point of the roadmap's phrasing: "built on existing standards rather than pasted API keys." The MCP work is deciding how a server advertises that it requires DPoP, how a client that is a cloud workload obtains its first token without a browser, and how the delegated token for a sub-agent gets narrower than its parent's. The WIMSE coordination matters here: workload identity is a problem every service mesh has, and an MCP-only answer would be a mistake the maintainers are visibly trying not to make.

The catalog tax

Tool calling held up; tool results did not. A tools/call result may carry content and structuredContent at the same time, and a server author "has no way to know which form a given client will put in front of the model." Implementations diverged. The fix is a redesign of the result shape into one contract, which the forming Core Primitives group owns, alongside a decision on content annotations: the spec has audience and priority annotations that could settle what the model sees and what only the human sees, most implementers never adopted them, and the roadmap says plainly that if they are not useful they should be deprecated.

The bigger item is discovery. The roadmap's sentence is the one that every MCP-heavy harness already knows from its own bill: "Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows." Progressive discovery is the proposed answer on the server side: a small entry point, and a way to reveal more of the catalog as the conversation narrows, with a defined interaction with the ETag caching work. Harnesses have been doing a version of this from the client side, deferring tool schemas and loading them on demand, and the resident-versus-deferred split in Claude Code's context is the same idea one layer up. Putting it in the protocol means a server can shape its own surface instead of hoping every client prunes it.

SDKs generated from the spec

The last area is quiet and, for anyone who has shipped an MCP server by pointing an agent at an SDK, the most consequential. Today the SDKs, reference servers, and quickstarts are maintained by hand, and the roadmap admits the shape of the problem: "many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction." Two deliverables. An extension contract that says which role an extension binds (host, client, server, agent), what each does when the capability is declared, what an SDK must support natively, and how extensions are packaged and versioned, with auth split out as its own area. And an experiment: generate a candidate Tier 1 SDK and its quickstarts from the specification, validate both against the conformance suite, and publish which layers should be deterministic codegen and which model-assisted. If it works, the spec becomes the source of truth and the SDKs get regenerated per release instead of repaired after it. Spec ambiguities that break generation get filed as documentation bugs. That is a governance change dressed as tooling.

What to do this quarter

If you write tools, write them ephemeral-first. Return input_required instead of awaiting an answer inside the handler, put anything you need across rounds into requestState, encrypt or sign it, and bind it to the user if it says anything about the user. The retry may land on a machine that has never seen the first call; design for that and you get horizontal scale for free. Reserve Tasks for work that must keep running while the human thinks.

If you push, use subscriptions/listen with a narrow filter and handle the reconnect case by re-subscribing. If you poll Tasks today, the Triggers & Events group is where the webhook and channel primitives are being drafted; that is the place to say what your client needs. If you operate a remote server, start on DPoP now: the roadmap says the Working Group's job is adoption, which means the spec is close enough to build against and your bearer tokens are the thing it is designed to retire. If you publish a large catalog, group it: a small, well-described entry point with the rest reachable on request is what progressive discovery will formalize, and clients will reward it before the SEP lands. And if you have a proposal, name its priority area and bring the Working Group with it. The maintainers said the quiet part: review time is scarce, and it goes to these five areas first.