Re-render Sora prompts from an agent: jobs_wait takes 20 ids

If an agent is re-rendering a list of saved Sora prompts through Sume's hosted MCP server, give it a batch rhythm. Per the jobs guide, jobs_wait accepts 1 to 20 job_ids with wait_for set to all or any, and include_results: true returns finished results in the same answer. Submit generate_video for 20 prompts with idempotency keys, wait once, read once, and move on. When a wait slice expires, wait again with the same ids.

Why 20 and why short slices

Remote MCP calls hold at most 55 seconds, with a 50 second default. The docs explain that a longer HTTP hold dies at the edge before it answers, while the job keeps running and billing. So a ten-minute render is repeated waits, not one long one.

Instruct the agent explicitly

Agents improvise when told only to "render these". Spell out the loop: check the balance, run dry_run on the first prompt, submit up to the wave size, record every job id, call jobs_wait with include_results, then call a batch jobs_result for ids named in results_omitted. Tell it that wait_for: any still reports every id and that remaining jobs continue and still bill.

• Every paid write needs an idempotency_key per prompt.
• Optional max_spend_usd caps a single call.
• Report media.sume.com URLs, not signed URLs.

Failure modes to name in the prompt

A 524 or similar edge status on jobs_wait is a transport failure, never a job outcome; re-issue the wait or read jobs_status once. Partial success is normal in a batch result: read ok per entry. And an operator_stopped outcome means Sume operations stopped a job, which is terminal with the hold refunded. For wave sizing, follow the admission guide, and check MCP tools and gates for the tool list.