Sume MCP jobs_wait with 20 job_ids: wait_for any versus all

jobs_wait takes up to 20 job_ids and wait_for any or all. All is the default. Any returns early, but the other jobs keep running and billing. Examples inside.

5 min readSume
All posts

Pass job_ids with 1 to 20 ids and pick wait_for. all is the default and returns when every id is terminal or the slice ends. any returns as soon as one id finishes, but the rest keep running and keep billing. The answer is a job_wait_batch with a status snapshot for each id.

jobs_wait inputs, read 2026-10-08
InputValuesNote
job_idOne idResponse stays job_wait
job_ids1 to 20 idsResponse is job_wait_batch
wait_forall or anyDefault all
timeout_secondsDefault 50, cap 55Clamped, reported in wait_slice_clamped
include_resultstrue or falseAdds results[] for completed ids

Choosing any or all

Use all for a wave that must complete together, such as the scenes of one video. Use any when the first finished item lets you start downstream work, and keep a list of what is still running.

Behavior of each mode, read 2026-10-08
ModeReturns whenJobs still running
allEvery id is terminal, or the slice endsContinue if the slice ended
anyOne id is terminal, or the slice endsContinue, and still bill

Request

A batch wait is a single MCP tool call with these arguments.

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

Edge cases

If one id has been stopped by Sume operations, the wait answers at once with outcome: operator_stopped, and pending_job_ids names those still running. Waiting again on the stopped ids cannot change the answer. Terminal stopped jobs produce no output and their holds were refunded.

Plan limits also shape the wave: a Free workspace can have 1 job processing and 5 queued, so a 20-id wave only makes sense on larger plans or after earlier jobs finish.

Choosing the slice

The default slice is 50 seconds. A wave of image jobs often completes inside one slice; a wave of video jobs usually does not. Do not raise the value to fit a render; wait again. The server clamps anything above 55 and tells you in wait_slice_clamped.

Reading what comes back

Each entry in the snapshot carries that job's status. Act on terminal ones, remember the rest, and wait again on the remaining ids only. With include_results, completed entries come back with their results, and any that do not fit are listed in results_omitted.job_ids for a follow-up jobs_result.

A common mistake is to treat the first any return as the end of the wave and move on, forgetting that the others are still processing. Keep the list of unfinished ids in the agent's notes and wait on it until it is empty. Another is to mix workspaces: an id from a different workspace fails the entire call, so build the list from jobs your own session created.

Keep in mind that Sume's hosted endpoint is the same for every client in this series: https://mcp.sume.com/mcp, with OAuth consent on the MCP host or an API key in a header. What differs is each client's config keys, its timeout defaults and its approval prompts. When a connection misbehaves, first separate those two layers: test the endpoint with curl and your credential, and only then look at the client's settings.

Sources

More in Integrations

All Integrations posts

Written by Sume