When is opening an MCP subscriptions/listen stream worth its cost?

## The trade In MCP revision **2026-07-28** there is no ambient push channel, so every notification a client receives is one it paid for by holding a `subscriptions/listen` request open. That request is long-lived by design: over Streamable HTTP it is a POST whose response stream stays open, over stdio it is an outstanding request on the shared channel. Multiply it by every client-server pair a host maintains and it becomes a real fleet-level number, since the host runs one client per connected server. What you buy is **promptness**. What you pay is a held-open request, plus the code to supervise it: acknowledgement timeouts, reconnect, resynchronisation. ## When it earns its keep - **The client renders server state a human watches.** A tool palette, a resource browser, an editor showing a watched file. Here a stale view is a visible bug, and polling fast enough to hide it costs more than the stream. - **Change is rare but must be noticed quickly.** Polling has the worst shape for this: almost every poll is wasted, and the one that matters still arrives up to an interval late. A subscription inverts that. - **The watched set is small and specific.** `resourceSubscriptions` lets a client name exactly the URIs it is displaying, so the notification volume is proportional to what the user is actually looking at. ## When to skip it - **Headless or batch agents.** A run that lists tools once at the start and finishes in minutes gains nothing from a stream; re-listing at the start of the next run is sufficient. - **Servers whose catalogues are effectively static.** If a server's tool set changes on deploy, the notification will fire approximately never, and the client can rely on re-listing when a cached list expires. - **Clients with an existing refresh trigger.** If the UI already re-lists when the user opens a panel, the stream is duplicating a path that is already correct. ## Facts that shape the decision First, **notifications are signals, not payloads**. `notifications/tools/list_changed` does not carry the new tools; the client re-calls `tools/list`. So a subscription does not replace the list call, it only tells you when to make it. If your client would have re-listed on a reasonable schedule anyway, the marginal value is just the reduction in staleness window. Second, **the filter is granular in one direction only**. You can watch individual resources by URI, but tools and prompts are watched at list granularity. A server with a volatile tool set will therefore wake every subscribed client on every change, whether or not the change affects what that client uses. Third, **there is no replay**. Resumability was removed in 2026-07-28, so a stream that breaks loses whatever happened during the gap. A subscription-based client must still have a re-list path for recovery — which means the polling code you hoped to delete does not entirely go away. Fourth, **the subscription costs nothing in server state semantics**. MCP is stateless per request, and the tool, prompt and resource sets must not vary per connection (they may vary by the authorization presented), so a subscription is a delivery arrangement, not a scoping mechanism. Nobody gets a private view of the server by subscribing. ## Operating a fleet of streams If you do adopt subscriptions across many servers, decide up front: - **Filter discipline.** Subscribe to what you render, not to everything the server offers. A default of "all four filter fields on" is how a client ends up waking on churn it ignores. - **Lifecycle ownership.** One supervisor per connection that opens the stream, waits for `notifications/subscriptions/acknowledged`, resynchronises caches, and reopens with backoff. Feature code should declare intent, not manage streams. - **Graceful shedding on the server side.** A server under pressure can end a stream cleanly with an empty `SubscriptionsListenResult` rather than dropping connections, and clients should treat that as a signal to back off rather than reconnect instantly. - **Idle policy.** A stream for a panel the user closed an hour ago is pure cost; tie subscription lifetime to what is actually on screen. ## Interview framing This is a judgment question, so answer as a judgment: name what the stream buys (promptness on state a user watches), name what it costs (a held-open request per client-server pair plus supervision code), and give the disqualifier (a headless or batch client that re-lists anyway). Then show you know the mechanics that constrain the choice — signals rather than payloads, per-resource but not per-tool granularity, and no replay after a break, so the re-list path survives either way.