script_run on Sume MCP: what the sandbox cannot call, and its budgets

script_run on the hosted Sume MCP server runs a short JavaScript program on Sume's side. The program calls other Sume tools with await sume.call(name, args), and the whole run has a timeout of 5 to 55 seconds, a max_calls budget and a max_paid_calls budget. It cannot call the discovery tools or itself, so you do discovery first and hand the script concrete tool names.

What it is for

The point of the tool is to cut round trips. A coding agent that wants to check an account, list a few things and start two jobs would otherwise make many separate tool calls, each one a full model turn. With script_run, one tool call carries the loop, and the result comes back as a value, a calls[] journal of each inner call and the child jobs[] that were started.

Limits at a glance

The limits are the part to design around. They are stated in the tool's own description, so check tools_schema for the live values.

Zero is a useful number

Use max_paid_calls: 0 for any script that should only read. If a paid call slips in, the budget refuses it, and the journal shows where. This is a cleaner guardrail than a prompt that says "do not spend", because the limit is enforced by the tool and not by the model's mood.

A read-only script

The arguments below are for a read-only script. The code value is the JavaScript body, account_me is a read tool with no arguments, and the budgets leave no room for a paid call. Pass this object as the arguments of the script_run tool from your MCP client.

{
  "code": "const me = await sume.call('account_me', {}); return { me };",
  "timeout_seconds": 30,
  "max_calls": 3,
  "max_paid_calls": 0
}

When you do spend

If you do put paid calls in a script, keep the same habits as for direct calls. Each paid tool still wants an idempotency_key, dry_run=true previews the cost, and wallet admission is the real gate. Set max_paid_calls to the exact number you expect, so a bug in a loop cannot start twenty jobs.

Waiting for the result

Long jobs do not fit in a 55-second script, and they should not. Start the jobs inside the script, return their ids, and wait on them with jobs_wait afterwards. If a wait slice expires, wait again on the same ids and never create the job again.