A client's report-generation request keeps receiving notifications/progress every few seconds, but after two hours no final response has arrived. The team is redesigning the client's timeout policy. Which policy matches the MCP guidance?
Select an answer to reveal the explanation.
Short Explanation
Progress updates are like a contractor texting "still working on it!" — nice, but you still set a final deadline. Resetting the clock is fine; an endless clock isn't. The trap is believing chatter equals completion.
Full Explanation
The cancellation pattern's timeout guidance says implementations should establish timeouts for all sent requests to prevent hung connections and resource exhaustion. When no result or error has arrived within the timeout, the sender should cancel the request and stop waiting. Implementations may reset the timeout clock when a progress notification for that request arrives, because progress implies work is actually happening, but they should always enforce a maximum timeout regardless of progress, to limit the impact of a misbehaving client or server. Cancelling means closing the response stream on Streamable HTTP or sending notifications/cancelled on stdio. Disabling the timeout while progress continues lets a server that emits progress forever hold resources indefinitely, the exact scenario the maximum timeout exists for. ttlMs is a caching freshness hint for list and read results and says nothing about how long a call may run. ping was removed from the protocol in this revision, so it cannot serve as a liveness check. Exam caveat: for genuinely long work, the Tasks extension is the better design, returning a durable handle that the client polls. Operational check: configure a per-request timeout with an absolute maximum and confirm in testing that a request emitting endless progress is cancelled when the maximum elapses.