MCP Tasks extension: does Sume use it for long jobs?

No. Sume's hosted MCP server has no task handles. A paid create returns a job id, and you poll it with jobs_status or jobs_wait, then read jobs_result.

4 min readSume
All posts

No. Sume's hosted MCP server does not implement the Tasks extension. Its request handler answers initialize, ping, tools/list and tools/call and rejects other methods as unknown, so there is no tasks/get to call. Long work on Sume runs as jobs: the create call returns a job id, and you poll it with jobs_status or jobs_wait, then read jobs_result.

The Tasks side is from the MCP project's Tasks overview and the 2026-07-28 key changes, read 2026-09-29. The Sume side is the MCP tools and gates page and the hosted server code.

What does the Tasks extension add?

The 2026-07-28 revision moved experimental tasks out of the core protocol into an official extension named io.modelcontextprotocol/tasks. A server that decides a request will run long returns a task handle instead of the result. The handle carries a taskId, a status, a TTL and a suggested polling interval, and the client then polls tasks/get.

It is opt-in on both sides. The client lists io.modelcontextprotocol/tasks in its per-request capabilities, and the server advertises the same extension in its server/discover capabilities. Sume's dispatcher has no server/discover method either, and its tools/list answer carries only the tools, so a client has nothing to negotiate against.

From the MCP Tasks overview, read 2026-09-29.
PieceWhat the overview says
Statusesworking, input_required, completed, failed, cancelled
Pollingtasks/get with the taskId
Extra inputthe client answers with tasks/update
Canceltasks/cancel, cooperative: the server is not obliged to stop

What does Sume do instead?

The docs' paid-flow playbook is a job flow, not a task flow: call the tool with dry_run=true and review the preview, repeat it without dry_run to submit, poll with jobs_status or jobs_wait, then read jobs_result. The read tools are jobs_list, jobs_get, jobs_status, jobs_result, jobs_events and jobs_wait.

The job id is a durable handle much like a taskId. It survives a dropped connection, and you can ask about it from a new session. jobs_cancel is a write tool that needs an idempotency_key.

# after a paid create returned a job id:
# jobs_status  { "job_id": "<id>" }
# jobs_wait    { "job_id": "<id>" }   # returns within a slice; call again if not done
# jobs_result  { "job_id": "<id>" }   # read the finished output

Do I need to change my client?

Not for Sume. A client that supports the Tasks extension only uses it when the server offers it, so against Sume it takes the ordinary tool path. Write the wait loop against the job tools. The current hosted jobs_wait holds a request for at most 55 seconds, so treat a not-yet-done answer as a reason to call it again on the same id, never as a failure and never as a reason to resubmit the paid create.

The Sume docs list only the job tools for waiting, so those are the supported way to do it today.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume