A server is being shut down for planned maintenance while several clients hold open subscriptions/listen streams. The clients should be able to tell that their subscriptions ended deliberately rather than through an unexpected disconnect. What should the server do for each stream?
Select an answer to reveal the explanation.
Short Explanation
Ending a phone call with "goodbye" versus the line just going dead — your caller knows which one means "we're done" and which means "call back." The listen request's final result is that goodbye. The trap is assuming silence reads as a clean ending.
Full Explanation
A subscriptions/listen request is a long-lived JSON-RPC request whose response stream carries notifications. When the server ends a subscription on its own initiative, for example during shutdown, it should respond to the original listen request with a completion result, correlated by the request's id and carrying io.modelcontextprotocol/subscriptionId in _meta, and then close the stream. That response is what distinguishes a graceful end from an abrupt transport drop, which carries no response and which a client may treat as a trigger to reconnect. Re-sending the acknowledgment notification is wrong because acknowledged is defined only as the first message confirming the agreed filter, not as a termination signal. Closing silently gives clients no way to tell maintenance from a crash, so they will likely reconnect into a server that is going away. A -32601 error means method not found, which misstates the situation and would mislead the client about the server's capabilities. Exam caveat: on stdio, a client that reconnects must re-send subscriptions/listen, because the server keeps no subscription state across reconnections. Operational check: during a controlled shutdown test, confirm each listen stream receives a result with resultType "complete" before the connection closes.