MCP Tasks and elicitation: run a long job without losing control
MCP Tasks let a compatible server return a job handle while work continues. Elicitation lets that server ask you for missing information. Together they can support a long workflow, but both the client and server must implement the relevant capabilities.
Start with prerequisites ↓01 · Accepted
The server returns a task handle. That is not the output.
02 · Running or waiting
Follow status and answer a specific input request.
03 · Verified
Read the terminal outcome, then inspect the actual artifact.
Use the same job handle when checking an uncertain outcome. Starting again may create a second job.
1. Check the client and server before starting
The documented Claude Code path is a public beta requiring CLI v2.1.304 or later, a task-capable server and protocol revision 2026-07-28. Current eligibility includes the interactive terminal, but not the VS Code extension or desktop app. Provider, feature-flag and session restrictions still apply; the version number alone is insufficient. Check the Claude Code support conditions for your session.
Start in the main interactive conversation with a server you already trust. Confirm its documented task support and a harmless operation, such as exporting a test dataset. Installing a plugin that advertises MCP is not enough. If you are still choosing a server, use the MCP server guide first.
2. Define one result you can inspect
Before calling a tool, write down the input, output and acceptable side effects. Here is an editorial prompt to adapt to your server; it does not invent a tool name:
Use the connected server's documented export tool on the test dataset.
Create one export only. Report its task ID and current state.
Do not submit another export if the connection drops.
When it finishes, show the output location and record count.
If you need a choice, ask me before continuing.
A useful acceptance case has a known small input: for example, three synthetic records with unique IDs. Expect exactly those records in the returned artifact. A message saying “accepted” passes only the submission step.
3. Follow progress and answer elicitation
Use /tasks to inspect the job. If the server asks a question, close that view to see the elicitation dialog. Declining a question is not necessarily cancellation of the underlying work. These are documented CLI behaviors.
Read what the question changes: a destination, date range or format can materially change the output. For an unexpected request, decline and inspect the task rather than guessing. The elicitation specification distinguishes form input from URL-based flows. Form elicitation is not a place to request passwords or API keys. Check the destination and purpose before following an authentication URL.
For your first trial, record three observations: the accepted job handle, any question you answered, and the final server state. That makes it easier to distinguish a stalled job from one waiting for you.
4. Cancel or recover without duplicating work
Select the task in /tasks and press x to request cancellation. An ordinary Esc is not a general background-job stop button. Reconnect the server before trying to cancel a disconnected task. Remote work may continue after the CLI exits; a local stdio server normally stops with the process unless that server documents persistence. See CLI cancellation and resume behavior.
If the outcome is unknown, resume the same session and inspect the existing task before resubmitting. Check the destination for an already-created output. For operations that send, buy or modify records, ask the service owner how it handles duplicate requests; a fresh prompt is not an idempotency guarantee.
5. If you are building the server
Implement the extension negotiated by your client, not a mixture of examples from different protocol revisions. The current Tasks extension defines task state, polling and input handling. Keep a stable identifier and an explicit final outcome. Do not mark a job complete merely because it entered your queue.
Build a small acceptance matrix: normal completion, required user input, declined input, cancellation, disconnected client and repeated status checks. For each case, specify both the visible state and the service-side effect. Also test that one user cannot inspect another user's job. These are implementation checks to design, not results we obtained from a live server.
6. Verify the artifact and account for costs
Open the actual export and compare IDs and count with your fixture. Record incomplete or inaccessible outputs as failures even when the chat sounds confident. Save the job ID with your own notes so an operator can trace the same attempt.
MCP is a protocol, not a billing allowance. Your Claude subscription or model usage, the server's compute and any downstream API can have separate charges. Check the connected service's current limits before a long run. There is no universal “free background job” entitlement.
FAQ
Does every MCP plugin support Tasks?
No. Both the client session and server need the matching capability. A normal MCP tool can remain a synchronous call.
Does closing the terminal cancel a remote job?
Do not assume so. Inspect or cancel the original task through a supported client and confirm its server-side outcome.
Did you test a real export?
No. This is source-checked setup guidance and an original acceptance checklist; no server job or billable API call was executed.
Primary sources
Source-checked 2026-10-25. Published documentation, account availability and a hands-on workflow are separate evidence. Examples and checklists here are editorial material.