MCP tasks extension and Sume job statuses: mapping for render tools

The MCP tasks extension and a Sume job solve the same problem, a call that outlives a request, and the concepts line up one to one. In 2026-07-28, experimental tasks moved to the official extension io.modelcontextprotocol/tasks: the blocking tasks/result is replaced by polling tasks/get plus tasks/update, tasks/list is removed, and a server may return a task handle unsolicited. The details are in the changelog, read 2026-10-03.

The mapping

The table pairs each task concept from the changelog with the closest Sume construct. Sume's docs do not say that its server implements the tasks extension, so read this as a design comparison and not as a compatibility claim.

Where they differ

A Sume job has five statuses: queued, processing, completed, failed and canceled. The last three are terminal. queued is a normal accepted state and not an error, because workspace concurrency limits apply when a worker moves the job to processing.

Sume jobs are also owned. A job belongs to its workspace and to the member whose key or Agent turn created it, and only that member can cancel it. Another member's job returns 404 not_found from an API key. If you adopt tasks on your own server, decide the same ownership rule before you expose a list call.

Polling without waste

The Sume docs recommend exponential backoff and stopping on a terminal status. They also say not to resubmit the original paid request because a local process timed out. That advice carries over to task polling: the handle is the recovery path.

For a wave of renders, one batch wait is better than many single waits. jobs_wait accepts 1 to 20 ids and an optional wait_for of all or any, and with include_results: true it returns completed results in the same answer.

{
  "job_ids": ["job_a", "job_b", "job_c"],
  "wait_for": "all",
  "timeout_seconds": 50,
  "include_results": true
}

What to take from it

Design the handle first. If your tool returns a stable, owned, durable id and every follow-up takes it, you can sit behind either a task wrapper or a plain job API and change your mind later. The id is what outlives the connection, whatever the protocol calls it.