MCP jobs_wait wait_deadline_exceeded vs wait_canceled: what to do

The jobs_wait tool on Sume's hosted MCP server holds a call open until jobs finish. It waits 50 seconds by default and 55 at most, and takes one job id or a batch of 1 to 20. Most of the time it ends in a normal result. If the wait runs out, you get a result with timed_out set to true, which is a scheduling fact and not a failure. Two other outcomes are real errors, and they are easy to confuse: wait_deadline_exceeded and wait_canceled.

What each code means

Both come back as a tool error with http_status 503, retryable true and next_action poll_status. The server chooses between them with one test: if the request's abort signal fired, the code is wait_canceled; for any other interruption inside the wait it is wait_deadline_exceeded.

So wait_canceled says your side or the transport ended the call, for example a client timeout shorter than the wait, or a user pressing stop. wait_deadline_exceeded says the wait was cut short without an abort from you. In neither case did anything happen to the job.

The one thing never to do

Do not call the paid create tool again. The job id you hold is still the job. A second create is a second charge unless you resend the original idempotency_key. The error text even says so in the busy case: keep one jobs_wait for all pending job ids and do not submit replacement jobs.

If your client has a request timeout, set it above the wait you ask for. A 30 second client timeout and a 50 second default wait will produce wait_canceled on every long video. Either raise the client timeout past 55 seconds or pass a smaller timeout on the call.

A safe loop

Treat all of these as the same thing: still working. Track the ids you submitted, call jobs_wait with wait_for set to all, and repeat until every job reports a terminal status. Use include_results only when you are ready to read output, because large results fill the model context.

• Wait on all pending ids in one call, not one call per id.
• On a 503 or timed_out, wait again; add a short pause after repeated errors.
• After about three errors in a row, read GET /v1/jobs/{id}/status once to confirm the status.
• Never replace a pending job with a new create.