A client is polling a long-running task created through the Tasks extension. A tasks/get response now shows status input_required along with an inputRequests map containing a confirmation elicitation. What should the client do next?
Select an answer to reveal the explanation.
Short Explanation
The task has paused at a checkpoint and is holding out a clipboard for your signature. You read what it needs, answer, and pass it back with tasks/update; polling picks up from there. The trap is treating the pause as the end of the road.
Full Explanation
In the Tasks extension, input_required means the server needs client input before the task can continue, and the tasks/get response includes an inputRequests map, such as an elicitation for user confirmation. The client presents those requests to the user or model, collects the responses and submits them through tasks/update with the taskId and the inputResponses. Polling with tasks/get then continues until the task reaches a terminal status. This keeps mid-flight interaction inside client-initiated requests, with no second connection and no unsolicited server-to-client messages. tasks/result was the blocking retrieval method of the older core experimental tasks and has been replaced by polling, and servers do not send separate elicitation requests. Retrying the original tools/call is the pattern for a plain multi round-trip request, not for a task; here it would start new work while the original task stays paused. input_required is not terminal; only completed, failed and cancelled are, so cancelling discards work that only needed an answer. Exam caveat: tasks/cancel is cooperative, meaning the server acknowledges the intent but is not obliged to stop. Operational check: drive a task into input_required in a test and confirm the client sends tasks/update and that subsequent tasks/get calls show the task back in working.