script_run limits: timeout 5-55 s, max_calls and max_paid_calls

script_run is the hosted Sume MCP tool for batching: it runs a short JavaScript program on Sume's side, the program calls other listed tools in a loop, in parallel or conditionally, and returns one value. Three limits bound it: timeout_seconds from 5 to 55, max_calls, and max_paid_calls. The docs give no default values for the last two, so set them explicitly.

Use it when a turn needs three or more independent calls of the same shape, such as one tts_create per sentence or one generate_image per scene. One tool result replaces many, which also shortens the prompt your model reads on the next turn.

What it is and is not

Inside the script, await sume.call(name, arguments) runs any listed tool with the same gates, redaction and errors as a direct call. That is the important part for spend: a script is not a back door.

Designing around the 55-second ceiling

A script that waits for a video to finish will hit the ceiling. Submit inside the script, return the jobs[], and wait outside it with jobs_wait. The script's job is the fan-out, not the polling.

For the paid limit, estimate the cost first. Say a script submits six scenes at the Sume list rate for a 5-second Wan 3.0 720p clip: 5 x $0.125 = $0.625 each, $3.75 for six. Setting max_paid_calls to 6 stops a runaway loop at six submits, and a per-call max_spend_usd caps each one. The two limits protect against different mistakes: one counts calls, the other counts dollars.

A checklist before you let a model write the script

The model writes the script text, so put the controls in the instructions and verify them in the journal.

• Call tools_schema for script_run and read the argument names for your session.
• Require max_paid_calls and a unique idempotency_key per paid call in the prompt.
• Read the calls[] journal after each run and compare it to the count you expected.
• Pass the returned jobs[] to jobs_wait in slices rather than one long wait.

Why not just let the model loop

A model that issues six tool calls one turn at a time pays for six round trips and re-reads the whole conversation each time. A script does the fan-out in one call. The cost of that convenience is that a mistake is multiplied: a bad argument shape repeats across every iteration. Keep the first run small, with a low max_calls, read the journal, and only then raise the numbers.

The script also cannot discover tools, so the model must already know the exact names and argument shapes from tools_schema. Ask for the schemas before the script, not inside it.