Context
notifications/tasks carries a complete DetailedTask, "identical to what tasks/get would have returned at that moment" (specification/2026-07-28/tasks.md:477). Clients "MAY continue polling tasks/get in addition to subscribing … but need not do so" (:505).- In core MCP 2026-07-28, an abrupt transport drop ends a subscription (
basic/patterns/subscriptions.mdx:125). The client "MAY treat [it] as a trigger to reconnect" (:157-158). On stdio it "MUST re-send subscriptions/listen", and the server "holds no subscription state across reconnections" (:160-162).
- SSE resumability was removed on purpose in this revision (SEP-2575,
changelog.mdx:28). This issue doesn't ask to bring it back. Snapshot notifications make it unnecessary for tasks, with one exception, below.
The gap
A client that follows :505 and relies on notifications alone can do this:
subscriptions/listen with taskIds: [T], and the ack confirms T.- The transport drops.
T moves working → completed (or → input_required) while no stream exists. The notification has nowhere to go.- The client reconnects and re-sends
subscriptions/listen for T, and the server acks.
T is terminal, so nothing further ever changes. The client never receives a notification and waits until ttlMs expires.
For input_required, the task also stalls server-side, because the client never sees inputRequests.
Proposal (either line settles it)
- Server side: "After acknowledging a
subscriptions/listen that includes taskIds, the server SHOULD send one notifications/tasks carrying the current DetailedTask for each acknowledged task ID." This is snapshot-on-subscribe, the same shape A2A's SubscribeToTask uses.
- Client side: "A client that (re-)establishes a subscription MUST call
tasks/get once for each task ID in the acknowledgement before relying on notifications alone." This needs no server change and fits the "need not poll" text as long as that text gets this qualifier.
lastUpdatedAt (tasks.md:133) already lets a client discard a stale snapshot if both a poll and a notification arrive, so either option is safe to combine with polling.
Context
notifications/taskscarries a completeDetailedTask, "identical to whattasks/getwould have returned at that moment" (specification/2026-07-28/tasks.md:477). Clients "MAY continue pollingtasks/getin addition to subscribing … but need not do so" (:505).basic/patterns/subscriptions.mdx:125). The client "MAY treat [it] as a trigger to reconnect" (:157-158). On stdio it "MUST re-sendsubscriptions/listen", and the server "holds no subscription state across reconnections" (:160-162).changelog.mdx:28). This issue doesn't ask to bring it back. Snapshot notifications make it unnecessary for tasks, with one exception, below.The gap
A client that follows
:505and relies on notifications alone can do this:subscriptions/listenwithtaskIds: [T], and the ack confirmsT.Tmovesworking → completed(or→ input_required) while no stream exists. The notification has nowhere to go.subscriptions/listenforT, and the server acks.Tis terminal, so nothing further ever changes. The client never receives a notification and waits untilttlMsexpires.For
input_required, the task also stalls server-side, because the client never seesinputRequests.Proposal (either line settles it)
subscriptions/listenthat includestaskIds, the server SHOULD send onenotifications/taskscarrying the currentDetailedTaskfor each acknowledged task ID." This is snapshot-on-subscribe, the same shape A2A'sSubscribeToTaskuses.tasks/getonce for each task ID in the acknowledgement before relying on notifications alone." This needs no server change and fits the "need not poll" text as long as that text gets this qualifier.lastUpdatedAt(tasks.md:133) already lets a client discard a stale snapshot if both a poll and a notification arrive, so either option is safe to combine with polling.