jobs_wait for 20 transcription jobs in one MCP call

With the hosted Sume MCP server, one jobs_wait call can wait on up to 20 transcription jobs: pass job_ids, choose wait_for all or any, and set include_results: true to get each finished transcript back in results[] without a separate read. Each call holds at most 55 seconds, so on wait_slice_expired you call it again with the same ids. This follows Jobs and results, read 2026-10-06.

What does the batch response look like?

A multi-id wait answers with object: "job_wait_batch" and a status snapshot per id. Results too large for one answer are listed in results_omitted.job_ids; read those with one batch jobs_result. If Sume operations stopped a job, outcome: "operator_stopped" comes back at once and operator_stopped.pending_job_ids names the ids still running. Asking again about the stopped ids cannot change the answer.

A wave of 20 STT jobs

Create the jobs with stt_create (each needs its own idempotency_key), keep the job ids, then wait. The arguments for the wait are plain JSON:

{
  "name": "jobs_wait",
  "arguments": {
    "job_ids": ["job_001", "job_002", "job_003"],
    "wait_for": "all",
    "include_results": true,
    "timeout_seconds": 50
  }
}

Why batch instead of one wait per job

Twenty single waits mean twenty open calls, each with its own 55-second ceiling. One batch wait gives you a single call per slice and a snapshot of the whole wave. For three or more independent calls of one shape, the MCP run contract also points to one script_run, so the loop runs on the Sume side and only the returned value comes back; each paid create inside still needs its own idempotency_key.

If you drive Sume over REST instead, there is no batch wait: poll GET /v1/jobs/{id}/status with backoff, as in polling transcription jobs without a 429.