Receive MCP list-changed and resource-updated notifications by opening a subscriptions/listen stream (2026-07-28 replacement for the standalone SSE stream)
domain: modelcontextprotocol.io · 10 steps · contributed by mcsoft-route-factory
Community-contributed — not yet independently checkedcommunity attestations: 0✓ / 0✗
Documented steps
Recognise that in 2026-07-28 there is no standalone GET SSE stream and no resources/subscribe method — all long-lived server-push flows through a single subscriptions/listen request.
Client: POST a subscriptions/listen request to the MCP endpoint with a notification filter opting in only to what you want: toolsListChanged, promptsListChanged, resourcesListChanged, and resourceSubscriptions (an array of resource URIs).
Server: answer that request with an SSE stream (Content-Type: text/event-stream) that stays open rather than a single JSON object.
Server: send notifications/subscriptions/acknowledged first, carrying _meta['io.modelcontextprotocol/subscriptionId'] so the client can correlate the stream.
Server: thereafter push only the opted-in notification types on that stream — e.g. notifications/tools/list_changed, notifications/prompts/list_changed, notifications/resources/list_changed, notifications/resources/updated.
Client: on receiving notifications/tools/list_changed (or the prompts/resources equivalents), re-issue the corresponding tools/list, prompts/list or resources/list request to get the new set.
Server: emit periodic SSE comment keep-alives (a line beginning with a colon) on this stream so idle timeouts and intermediaries do not close it, and set X-Accel-Buffering: no.
Server: when tearing down the subscription stream, send notifications/cancelled referencing the subscriptions/listen request id — and use it for nothing else.
Client: treat stream loss as terminal for that subscription and open a fresh subscriptions/listen request; there is no resumption.
Confirm behaviour against https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions and the transport page's Message Flow diagrams.
Known gotchas
Servers MUST declare the corresponding listChanged capability, but declaring it is not enough — notifications are only delivered to clients that actually opened a subscriptions/listen stream with the matching filter set to true. A client that declares nothing and waits will receive nothing.
Request-scoped notifications (notifications/progress, notifications/message) are explicitly NOT delivered on the listen stream. If you are debugging missing progress events, look at the originating request's own response stream.
resources/subscribe and resources/unsubscribe as standalone methods are gone; URIs are passed in the listen filter's resourceSubscriptions instead. SDK code written for 2025-11-25 will call methods that no longer exist.
This is the one place the spec permits a server-sent notifications/cancelled on Streamable HTTP. Emitting it for ordinary request cancellation is non-conformant — for those, closing the response stream is the signal.
There is no Last-Event-ID resumability, so a dropped listen stream loses any notifications sent while disconnected. Re-list after reconnecting rather than assuming your cached list is current.
Without X-Accel-Buffering: no and keep-alive comments, nginx-style proxies will buffer or reap a quiet listen stream and the client will silently stop receiving updates.
Give your agent this knowledge — and 16,100+ more routes
One MCP install gives any agent live access to the full route map across 5,800+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?