jobs_wait include_results: skip the second read, handle omitted ids

On Sume's remote MCP, jobs_wait with include_results: true returns the jobs_result answer for every id that completed, inside results[], so a wave needs no separate result read. When the results are too big for one answer, the ids that did not fit are named in results_omitted.job_ids, and you read those with one batch jobs_result.

That makes the common agent loop two calls instead of three: submit, then one wait that also returns what finished. This post covers what is documented about the option and how to handle the omitted ids.

What does include_results change?

Without it, jobs_wait returns a status snapshot per id and you follow up with jobs_result. With it, completed ids come back with the same entries a batch jobs_result returns. The Jobs and results page states that this is the same shape, so a parser written for batch jobs_result entries works on results[] too.

It is documented as a flag on the wait, not as a change to the wait itself, so keep treating the slice rules (wait_for, timeout_seconds, wait_slice_expired) the way you already do.

What is results_omitted?

Results are not guaranteed to fit in one tool answer. When they do not, the Jobs and results page says the ids that did not fit are named under results_omitted.job_ids; the docs do not give the size threshold, so do not hard-code one.

Per the docs, you read those ids with one batch jobs_result. Treat them as ids whose results you have not read yet, not as failures.

What is a safe loop with wait_for any?

With wait_for: "any" the wait returns as soon as one id is terminal, but it still reports every id, and the remaining jobs continue and still bill. Combining that with include_results means each pass can hand you finished work while the rest keep running.

A loop that follows the documented fields:

• Call jobs_wait with job_ids, wait_for: "any" and include_results: true.
• Store every entry in results[] by job id.
• If results_omitted.job_ids is present, call jobs_result once with those ids.
• Remove stored ids from your pending list and wait again on what remains.
• If you get wait_slice_expired, retry jobs_wait with the same ids. Never resubmit the paid create.

When is the old two-call pattern still better?

If you only need statuses for a progress display, skip include_results and keep the wait light. Add it on the pass where you expect completions and want the artifacts in the same answer. A wave that is mostly long-running video will usually see few completions per slice, so the savings come from image or audio waves where many ids finish together.

What should I watch for?

Unknown or foreign-workspace ids fail the whole call, so a typo in one id costs you the entire wait. Validate ids before sending them.

Also remember that a finished job is not the same as a good result for your purpose. Whether the clip suits your brief is still a review step.

One more boundary: a stopped id (outcome operator_stopped) is terminal and produces no output, and re-issuing the wait on it cannot change the answer. If you are batching a large wave, read the parallel jobs_wait any versus all post to choose between the two wait modes, and keep the 20-id ceiling in mind when you split a bigger fan-out.