The Subscription Stream: Notifications, Progress, and Cancellation
A notification never gets a reply, so it has to say on its own which conversation it belongs to: the long-lived stream that opened it, or the one request that is still waiting on it. Tell a notification from a request and explain why the receiver must never answer one. Open a subscriptions/listen stream, read its acknowledgment, and demultiplex the notifications it carries by subscriptionId. Separate stream notifications (list changed, resource updated) from request scoped notifications (progress, message) by the channel each one travels on, not by guessing. Track a progress notification's token and total, and explain why its progress value must keep increasing. Cancel a request or a subscription on each transport, and handle the race between a cancellation and a message that was already on its way. Most of MCP is one request, one reply. A client asks, a server answers, and the exchange is done. That shape does not fit everything a server needs to tell a client. Some information is ongoing: the tool list changed, a subscribed resource was written, a prompt was added. A single reply cannot carry "keep telling me about this," because a reply closes the request it belongs to. Other information is ambient: a call that takes thirty seconds can usefully report that it is a fifth of the way done, but…
The Subscription Stream: Notifications, Progress, and Cancellation: A notification never gets a reply, so it has to say on its own which conversation it…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.