Tasks

Asynchronous task execution for long-running MCP operations.

Adapted from Tasks. Spec and docs: experimental-ext-tasks / related Tasks extension SEPs.

Tasks keep hosts responsive when tools cannot finish within a single request timeout.

Executive summary

When work may take seconds to hours, servers return a durable taskId instead of blocking. Clients poll (tasks/get), supply mid-flight input (tasks/update), and retrieve the final result after reconnects.

Why not just block?

• Connection and intermediary timeouts
• Crash resilience via durable IDs
• Progress visibility (working, input_required, …)
• Mid-flight elicitation without a second ad-hoc channel
• Server decides per request whether to create a task

Lifecycle statuses

Status	Meaning
working	In progress
input_required	Needs client/user input (inputRequests)
completed	Terminal success (result)
failed	Terminal error (error)
cancelled	Cancel acknowledged (cooperative)

Client checklist

1. Advertise io.modelcontextprotocol/tasks in per-request capabilities.
2. Accept either a normal result or CreateTaskResult (resultType: "task").
3. Poll with tasks/get using pollIntervalMs.
4. Handle input_required via tasks/update.
5. Persist taskId across restarts.
6. Optionally subscribe to notifications/tasks.

Server checklist

1. Advertise the extension in server/discover.
2. Never return a task to clients that did not opt in.
3. Create the task durably before responding.
4. Honour cancellation when possible (cooperative).

Good fit

CI pipelines, batch jobs, human approvals, wrappers around external job APIs, unreliable networks.

Negative cases

• Returning tasks without client capability → protocol violation.
• Non-durable task store → lost work on server restart.
• Ignoring input_required on the client → stuck forever.

Key takeaways

• Tasks = durable async handles for MCP requests.
• Opt-in on both sides; poll or subscribe until terminal.
• Ideal for HITL and long jobs.

What to do next

See the official Tasks overview and Extensions overview.