Sume jobs_wait with 20 ids: one unknown id fails the whole call

On Sume's hosted MCP, a batch jobs_wait with job_ids fails as a whole if any one id is unknown or belongs to another workspace. The docs say it plainly: unknown or foreign-workspace ids cause the full call to fail. The call accepts 1 to 20 ids, and an id that is a typo, a job from a different workspace, or a job that another member made in another thread will not give you a partial answer for the good ids.

That behavior is different from the batch jobs_result call, which keeps going on partial failure. The two calls look alike, but their error rules are not the same, so an agent that learned one should not assume the other.

This is a design choice with a reason. A wait that could not tell you about one id would have to guess at it, and the server avoids inventing a job outcome. The error tells you to fix the list instead.

What a good batch call returns

The batch form returns an object of type job_wait_batch with a status snapshot for each requested id. Choose wait_for: "all" (the default) to return when every id is terminal, or "any" to return when the first one is. With any, the other jobs keep running and keep billing.

In a batch, each id keeps its own snapshot, so an agent can see which jobs finished and which are still running. After a wave of parallel creates, one batch wait replaces N single waits and uses one wait slot instead of many.

Why an id might be invalid

A job can be read by a key only if the member of that key created it, so an id copied from a teammate's thread is a common cause of the failure. All other reads get 404 not_found.

The ownership rule makes the second and third item hard to spot by eye, because the ids look fine. A key reads only what its member created, so use the same key or session that submitted the jobs for the whole lifecycle.

• A typo or a truncated id from a log line.
• An id from a different workspace, for example another environment.
• An id created by another member, read with an API key.
• A mixed list where an agent merged ids from two sessions.

Check the ids first

The answer for a safe batch is to validate before the long wait. One cheap pass over the ids with jobs_status, or one jobs_list call, tells you which ids are readable. Remove the bad ones and call the batch wait with the rest. The pass costs a few reads and saves a 55-second slice that would end in an error.

Keep the id list as data in the agent's state, not as text copied from a transcript. Ids that were saved at submit time, straight from the job envelope, avoid the typo case entirely. A script can also check that the list has between 1 and 20 entries before it calls the tool, because a longer list is rejected with a message that the call supports at most 20 ids.

The comparison below shows the two batch calls side by side.

Remember that a failure of the batch wait says nothing about the jobs. They run and bill whether or not the wait succeeds. After you fix the list, call the wait again; do not resubmit anything.

Putting the pieces together

For a wave of generation jobs, use one batch wait with include_results: true so a completed wave comes back with its results, and read any id named in results_omitted.job_ids with one batch jobs_result. See Jobs and results for the details and the 55-second slice rule, and MCP tools and gates for the jobs tool group.