In MCP's tasks extension, what task statuses exist and which of them are terminal?

## The five statuses The Tasks extension in MCP revision 2026-07-28 (`io.modelcontextprotocol/tasks`) models a long-running unit of work as a small state machine with five statuses: | Status | Meaning | Terminal? | |---|---|---| | `working` | The server is executing the work. | No | | `input_required` | Execution is paused pending something from the client. | No | | `completed` | The work finished successfully; the result is available. | Yes | | `failed` | The work ended unsuccessfully. | Yes | | `cancelled` | The work stopped because cancellation was requested. | Yes | The distinction that matters operationally is live versus terminal. `working` and `input_required` are live: the client's job is not finished, and it must either keep polling `tasks/get` or act. `completed`, `failed` and `cancelled` are terminal: the state machine will not move again, and the client stops watching. ## Why input_required is a status and not an error A task can discover halfway through that it needs a decision, a credential, or a directory listing. Rather than failing, it parks in `input_required`. The client, seeing that status, supplies what is needed with `tasks/update`, and the task resumes — typically back to `working`. This is deliberately different from how the core protocol handles the same need. A plain `tools/call` that needs client input comes back as an interim result and the client resolves it by re-issuing the original request. A task is already running and already has a durable identity, so re-issuing anything would be wrong; the client feeds the running task through `tasks/update` instead. Candidates who have only read about the core pattern often try to describe a retry here, and that is a real discriminator. ## Cancellation is cooperative `tasks/cancel` is a **request** to stop, addressed to the server by `taskId`. It is not a kill switch. The server may need to unwind a transaction, finish an atomic step, or release a lock before it can stop, and some work simply cannot be interrupted at an arbitrary point. Two consequences follow: 1. A client should not assume the task is over the instant it calls `tasks/cancel`. It should keep reading the status until it becomes terminal. 2. The terminal status after a cancel request is not necessarily `cancelled`. A task that was already finishing may land on `completed`, and one that broke while unwinding may land on `failed`. Treating `cancelled` as the only possible outcome of a cancel is a common bug. Cooperative cancellation is the same philosophy MCP applies elsewhere: `notifications/cancelled` on an ordinary request is likewise advisory, and closing a Streamable HTTP response stream signals cancellation of that request without promising the server has stopped. ## How the client observes transitions Polling `tasks/get` with the `taskId` is the baseline and always available. It works identically over stdio and Streamable HTTP, and it survives reconnects, because the `taskId` is an explicit server-minted handle rather than connection state — the shape 2026-07-28 mandates now that protocol-level sessions are gone. Optionally, a server may push `notifications/tasks` over a `subscriptions/listen` stream, so the client learns of transitions without a tight poll loop. That is an optimisation. A robust client still polls on reconnect, because a notification delivered while its stream was down is simply gone — 2026-07-28 removed stream resumability entirely. ## Retention and the terminal state A terminal status does not mean the task record vanishes instantly; the client normally needs one more `tasks/get` to collect the result of a `completed` task. But nor can a server keep every finished task forever. How long a completed task's result remains fetchable is a server policy question, and a client that walks away without collecting the result of a task it started should expect that result to be reclaimed eventually. Designing that retention window — long enough for a client that slept and reconnected, short enough to bound storage — is a real operational decision when you run a task-capable MCP server. ## Interview framing Name the five statuses cleanly, split them into two live and three terminal, and volunteer two nuances: `input_required` is resolved with `tasks/update` rather than by retrying anything, and `tasks/cancel` is a cooperative request whose eventual terminal status might not be `cancelled`. That combination shows you have thought about the state machine rather than memorised a list.