Auditing agent tool calls: MCP log advice, Sume script_run journal
The MCP spec tells clients to log tool usage for audit. For Sume's script_run, the response includes a calls[] journal and child jobs[] to use with jobs_wait.

The MCP spec says clients SHOULD log tool usage for audit, show inputs before calling, and implement timeouts. When an agent batches many Sume calls into one script_run, the audit trail is partly built for you: the response contains a calls[] journal of what the script called, the returned value, and the child jobs[] to wait on.
What script_run gives you
script_run runs a short JavaScript program on the Sume side. Inside, await sume.call(name, arguments) runs any listed tool with the same gates, redaction and errors as a direct call. Paid creates still need their own idempotency_key. Limits are timeout_seconds (5 to 55), max_calls and max_paid_calls. A script cannot call discovery tools or itself.
What it does not give you
The journal describes one run of one script. It is not a workspace-wide audit log, and the docs do not say it is retained. Keep your own record of the request id, the idempotency key and the job ids, and avoid logging signed URLs, OAuth tokens or API keys, which the safe-automation guidance lists as unsafe.
| Piece | Source | Note |
|---|---|---|
| Tool-call log | Your client (spec advice) | Client-side |
| calls[] journal | script_run response | Per script run |
| Child jobs[] | script_run response | Use with jobs_wait |
| Billing record | Your usage records | Authoritative spend |
Practical setting
Set max_paid_calls before the first run of any script that creates media. Store the journal next to the job ids so a reviewer can match each paid call to a result.
Sources
Related posts
More in Agents
- Mistral Large 4 preview: Sume's agent model field takes one value
Mistral Large 4 is reported in preview. Sume lists no Mistral Large id; Agent Completions accepts only sume-agent. What to send instead, and what it bills.
- One webhook handler for Sume agent, Format and schedule runs
A single receiver can handle all three Sume run types: verify the HMAC over timestamp.body, dedupe on request_id, and branch on outcome (ok, degraded, error).
- Polling a Sume agent run: next_action values and backoff
Poll Sume runs by branching on next_action (poll_status, retry_later, none), using status_url and result_url, backing off on 429 and 503.
- Scheduled or Format API: does the clock or your user start the run?
A Sume Scheduled run fires on a cron; a Format run fires when your backend calls it. Same agent, same receipt, new trigger. How to choose without dupes.
Written by Sume