A tool starts a continuous-integration pipeline that can take 40 minutes. The client and an intermediary proxy both drop connections that stay idle for long periods. Which approach handles this best?
Select an answer to reveal the explanation.
Short Explanation
It's the coat-check ticket approach: you hand over the job, get a ticket, and come back later instead of standing at the counter for 40 minutes. The trap is trying to keep one connection alive, because anything that drops it loses the request.
Full Explanation
The Tasks extension exists for long-running operations such as CI pipelines. When the client has opted in, the server can answer a tools/call with a task result containing a durable taskId, initial status and suggested polling interval. The client polls with tasks/get until a terminal status of completed, failed or cancelled, and because the handle is durable it survives disconnects and client restarts. Holding the response stream open is fragile: under revision 2026-07-28 a dropped HTTP response stream loses the request, so any timeout along the path forfeits the work and the client must reissue it with a new id. Progress notifications improve visibility but do not make the call survive a drop. resources/subscribe is a legacy method; change notifications now come through subscriptions/listen, and a resource subscription is not designed to carry a pipeline's outcome. Resumable streams using Last-Event-ID are explicitly not supported in this revision. Exam caveat: Tasks is an opt-in extension, so the server must never return a task to a client that did not declare support, and it should fall back to ordinary behaviour otherwise. Operational check: confirm both sides advertise io.modelcontextprotocol/tasks, start a run, then disconnect and resume polling with the stored taskId.