subscriptions/listen

subscriptions/listen is how a stateless protocol still delivers change notifications. Instead of a standing GET stream and per-resource subscribe calls, a client opens one long-lived POST whose response stream carries exactly the notification types it opted into: toolsListChanged, promptsListChanged, resourcesListChanged, and resourceSubscriptions. The server acknowledges and tags each notification with a subscription id. Request-scoped notifications such as progress and log messages stay on the originating request's response stream, keeping the listen stream purely for change signals.

The long-lived stream has a deployment cost that the changelog does not spell out. Hosts that cap request duration close the stream on their own schedule, and a client that treats every close as a fault will reconnect forever. Claude Code shipped a fix for exactly that on 2026-08-14, in v2.1.233: MCP v2 connections had been "endlessly reopening the subscriptions/listen stream against servers that terminate long-held streams on a fixed timeout (e.g. serverless hosts)". It is the first documented interop failure mode for this method, and it lands on the client side of a mechanism whose whole point was to work on ordinary HTTP infrastructure.