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.

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.
| Piece | What the overview says |
|---|---|
| Statuses | working, input_required, completed, failed, cancelled |
| Polling | tasks/get with the taskId |
| Extra input | the client answers with tasks/update |
| Cancel | tasks/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 outputDo 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
- Unsupported MCP protocol version: the 400 from Sume's server
Sume's MCP endpoint answers an MCP-Protocol-Version it does not support with HTTP 400 and code -32600. Here is what the 2026-07-28 spec tells a client to do.
- MiniMax H3 4-second clips: MiniMax says 4, Sume says 5
MiniMax lists 4–15 seconds for H3, but Sume's docs and pricing code start at 5 seconds. Send 5 or more, and trim to 4 afterwards if you need it.
- MiniMax H3 768p: why 720p is refused and what to send instead
MiniMax H3 renders natively at 768p, not 720p. Sume refuses resolution 720p on H3 and H3 Max and tells you to use 768p. The accepted values per id.
- MiniMax H3 aspect ratios: 21:9 to 9:16, and when adaptive works
MiniMax H3 makes six aspect ratios, from 21:9 to 9:16. Which ones Sume accepts, where adaptive is allowed, and how frame images set the ratio.
Written by Sume