A tool starts a CI pipeline that typically runs for twenty minutes. The client should not hold a connection open that long and must be able to check the outcome even after the client restarts. Both sides support the relevant extension. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
It's a restaurant pager: they give you a buzzer instead of making you stand at the counter, and you check it whenever you like. The task ID is that buzzer, and it still works after you restart. The trap is just holding the line open and hoping.
Full Explanation
Tasks are an official extension, io.modelcontextprotocol/tasks, built for long-running operations such as CI pipelines. The client declares the extension in its per-request capabilities and the server advertises it through server/discover. When the server decides a request will be long-running, it returns a CreateTaskResult, with resultType "task", containing a durable taskId, an initial status, a TTL and a suggested polling interval. The client then calls tasks/get until the status reaches completed, failed or cancelled, and the completed result contains what the original call would have returned. Because the taskId is durable, a client that restarts can persist it and resume polling. Holding the response stream open for twenty minutes is what Tasks exist to avoid: intermediaries and client timeouts make long-lived requests fragile, and a dropped stream loses the request. requestState belongs to multi round-trip retries and is not a polling mechanism for long jobs, so repeatedly resending tools/call risks starting duplicate pipelines. There is no notifications/tools/result message in the protocol. Exam caveat: Tasks replaced the older core experimental tasks, including the blocking tasks/result and tasks/list. Operational check: start a pipeline, restart the client, and confirm it resumes polling with the saved taskId until a terminal status.