In MCP's tasks extension, how does a client feed input to a task already running?

## The situation A long-running unit of work often cannot be fully specified up front. A migration hits an ambiguous record and needs a choice. A deployment reaches a gate and needs an approval. A crawler hits an authenticated page and needs a credential. Under MCP revision 2026-07-28 the server cannot simply ask: server-initiated JSON-RPC requests were removed in that revision, so there is no channel down which a running server routine can pose a question and await an answer. The Tasks extension (`io.modelcontextprotocol/tasks`) resolves this with a status plus a method. ## input_required, then tasks/update The task transitions to `input_required`. That is a live, non-terminal status: the work has not failed, it has parked. The client discovers it the same way it discovers any transition — by polling `tasks/get` with the `taskId`, or by receiving an optional `notifications/tasks` push on a `subscriptions/listen` stream if the server offers them. The client then calls `tasks/update`, naming the task and supplying the input the server asked for. The task resumes, typically back to `working`, and eventually reaches a terminal status. The direction of travel is what to remember. Nothing is pushed at the client demanding an answer; the client pulls the fact that input is wanted, and pushes the input back into an existing, identified unit of work. ## The contrast with the core protocol The core protocol has its own answer to "the server needs something from the client", and the two must not be confused. - **Core, synchronous call.** The server returns an interim result whose `resultType` is `"input_required"`. The client satisfies it and then **retries the original request with a new JSON-RPC id**. The original request is finished; a second, fresh request carries the answer forward. - **Task.** The task's *status* becomes `input_required`. The client calls `tasks/update`. The original `tools/call` returned long ago with a handle; the running work is a durable object identified by `taskId`, and it is mutated in place. So the same phrase appears in two roles: `input_required` is a `resultType` value on a synchronous interim result, and a *status* value in the task state machine. A candidate who says "you retry the tools/call" for a task has fused the two mechanisms. The tell is that retrying would start a second task, because a `tools/call` is a request to do work, not a reference to work already in progress. ## Declining In the core pattern, declining is expressed by simply not retrying — there is no error to send back. With a task, the analogous move is not to update it. A client that decides against supplying the input can leave the task parked, or call `tasks/cancel` to ask the server to wind it up, which is the cleaner choice because it lets the server release whatever it is holding. Leaving tasks parked indefinitely is how a server accumulates zombie state, so a well-behaved client cancels what it abandons. ## Practical consequences for clients 1. **You must poll or subscribe to notice.** A task parked in `input_required` is silent by construction. A client that fires a task and only checks back in an hour will have wasted the hour. Poll intervals should be tight enough that a parked task is noticed promptly. 2. **Human-in-the-loop latency is real.** If the input needs a person, the task may sit parked for minutes. The server's own timeouts for a parked task must accommodate that, or interactive tasks will die waiting for their users. 3. **Reconnects are harmless.** The `taskId` is an explicit server-minted handle, so a client that dropped its connection reconnects and calls `tasks/get`. This is the general 2026-07-28 shape — sessions and stream resumability were removed, and durable references are the replacement. 4. **Idempotency of the update.** A client that is unsure whether an update landed should re-read the status rather than blindly resending; if the task has already resumed, a second update for the same pause is at best redundant. ## Interview framing Say it in one sentence and then draw the contrast: a task that needs input parks in the `input_required` status and the client resolves it with `tasks/update` against the `taskId`, whereas an ordinary call that needs input is resolved by re-issuing the original request with a new id. Add that server-initiated requests do not exist in 2026-07-28, so neither path involves the server asking anything, and that declining is expressed by not updating — ideally followed by `tasks/cancel` so the server can clean up.