Read twelve narration takes at once: jobs_result partial success

To read twelve finished narration takes in one call over Sume's MCP server, pass their ids to jobs_result as job_ids. It accepts 1 to 20 ids and returns a job_result_batch with results[] in request order, each entry carrying ok plus either a value or a typed error. Partial success is normal, so check ok on every entry and never treat one failure as a verdict on the rest. This follows the jobs and results docs, read 2026-10-03.

What does a batch result look like?

Per entry, a TTS take's value is the job result; read the audio artifact from it as you would a single jobs_result.

How do I handle the unfinished one?

Re-read only partial_failure.failed_job_ids, or wait again with jobs_wait on those ids. Never resubmit the paid tts_create because one entry was not completed. The snippet below shows the split between ready and retry on a sample batch; the data is made up to show the shape.

results = [
    {"ok": True, "value": {"job_id": "job_a", "audio_url": "https://media.sume.com/artifacts/a.wav"}},
    {"ok": False, "error": {"code": "job_not_completed", "job_id": "job_b"}},
    {"ok": True, "value": {"job_id": "job_c", "audio_url": "https://media.sume.com/artifacts/c.wav"}},
]

done = [r["value"]["audio_url"] for r in results if r["ok"]]
retry = [r["error"]["job_id"] for r in results if not r["ok"]]
print("ready:", done)
print("read again:", retry)

Where should I stop?

• jobs_wait with include_results: true returns the results of every id that completed, so a wave often needs no separate read. Ids whose results are too large for one answer come back in results_omitted.job_ids.
• The 20-id ceiling applies to both calls; twelve sentences fit, but a 30-sentence script needs two batches.
• I did not test large batches against a client's output limit, so size your batch to what your client can display.