A client opened a subscriptions/listen stream and waits there for progress notifications about a long tools/call that it sent with a progressToken. No progress arrives on the listen stream. Why not?
Select an answer to reveal the explanation.
Short Explanation
Progress belongs to the call it describes, like a delivery tracker tied to one package. You'll find it on that call's own response stream, not on your general subscription feed. Looking in the wrong place is the whole trap.
Full Explanation
The Streamable HTTP specification distinguishes two kinds of server notifications. Request-scoped notifications, such as notifications/progress and notifications/message, MUST relate to the originating client request and are sent on that request's SSE response stream before the final response. Long-lived change notifications, such as tool list changes and resource updates, are delivered on the response stream of a subscriptions/listen request. The specification states explicitly that request-scoped notifications like progress and log messages are not delivered on the listen stream; they flow only on the response stream of the request they relate to. The client therefore needs to read the tools/call response stream. Linking progress to a logging capability confuses two utilities; progress is opted into with a progressToken and has no dependency on logging, which is itself deprecated. Sending progress only after the final response contradicts the rules, since progress must precede completion and must stop once the operation completes. No progress filter exists in subscriptions/listen; its fields are toolsListChanged, promptsListChanged, resourcesListChanged and resourceSubscriptions. Exam caveat: on stdio all messages share stdout, so progress arrives on the same channel as everything else and is matched by its progressToken. Operational check: watch the tools/call response stream and confirm progress notifications carrying the token appear there before the final result.