jobs_wait with timeout_seconds 0: a single status snapshot on Sume MCP

On Sume's hosted MCP server, jobs_wait with timeout_seconds: 0 reads the status of the job one time and returns at once, whether the job is terminal or not. The parser accepts 0 to 600 for timeout_seconds, and the remote server clamps the value to 55 (the default when you omit it is 50). The other timing field, interval_seconds, accepts 1 to 60 and defaults to 5.

So the same tool covers two uses: a short snapshot when the value is 0, and a held request of up to 55 seconds when it is not.

Why spell these numbers out? Older schemas advertised 300 and 600 seconds, and the server keeps accepting those values so callers that learned them do not break. The result is a clamp with a note, instead of an error.

The two timing inputs

Here is how the two inputs behave, from the parsing code and the docs.

Notice the last row. The wait you get is the minimum of what you asked for and the cap of 55, so the requested value and the applied value are both reported in the answer, which lets an agent see what really happened.

Why a zero wait is useful

jobs_status also returns the status of one job, so why use a zero wait? Because jobs_wait can take a batch of up to 20 ids in one call, and a zero-second batch is a cheap way to get one snapshot of a whole wave. It returns a job_wait_batch object with a status for each requested id, and it works well as a first look before an agent decides whether to wait or to do other work.

What the interval does

When the wait is longer than 0, interval_seconds is the sweep period inside the slice. The server also keeps its own floor: a caller cannot ask for a tighter sweep than the host fallback. In practice, you should leave interval_seconds alone. The wait also wakes on a completion event for the id, so a job that finishes mid-slice ends the wait without waiting out the interval.

The default sweep is 5 seconds with a small random extra, and the server uses a host-wide fallback that a caller cannot undercut. That keeps a crowd of agents from polling the API at a tight rate.

What a clamp means

A clamp is information, not an error. If your agent asks for 300 or 600, the server waits the capped slice and says so in wait_slice_clamped. The guidance in the answer is to keep re-issuing jobs_wait with the same ids in 45 to 55 second slices until the job is terminal, never to ask for a longer slice, and never to resubmit the paid create.

If you only ever remember one rule, make it this: a longer slice is never the answer. A wait is a single HTTP request held open with nothing moving, and edges close such requests, so two 50-second waits are safer than one 100-second wish.

A snapshot call for three jobs:

One more use of the zero wait is a health check in a loop that runs between other work. The agent calls it with all pending ids, reads the snapshot, and goes back to what it was doing.

{
  "job_ids": ["job_a", "job_b", "job_c"],
  "timeout_seconds": 0,
  "wait_for": "all"
}

Using the snapshot

Use the result to decide: if every id is terminal, read the results with one batch jobs_result; if not, call again with the default slice. The status table and slice rule are on Jobs and results, and the tool group is listed on MCP tools and gates.