Skip to main content
Glama

resume_run

Continue a paused or spending-limit-stopped run by answering an external stage or suggesting a new total for a paid run; completed stages replay from disk at no cost.

Instructions

Resume a paused run after its external stage was answered (submit_stage does this for you), or a run its spending limit stopped (a paid run asks the person for a new, higher total; max_usd is the figure suggested). Completed stages replay from disk and cost nothing.

Input Schema

NameRequiredDescriptionDefault
runYes
max_usdNothe figure to suggest as the run's new total, a positive number. A paid run its limit stopped asks the person for the new total in the dialog; this figure is only the suggestion. For a chain with no paid seat it raises the ceiling for the rest of this run, and "none" removes it. "none" is refused where the user set COUNCIL_MAX_USD_LIMIT; a figure above that limit is refused; 0 is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.3
    • removedInput schema / properties / allow_secret_shaped
      Removed value: -{
      -  "description": "continue a run the outbound key scan stopped (STOPPED-secret.md) and send the key-shaped text anyway; saved with the run from then on. Off unless given.",
      -  "type": "boolean"
      -}
    • changedInput schema / properties / max_usd / description
      Previous value: -"raise the per-run ceiling for the rest of this run, a positive number. \"none\" removes it (refused if the user set COUNCIL_MAX_USD_LIMIT); 0 is refused."New value: +"the figure to suggest as the run's new total, a positive number. A paid run its limit stopped asks the person for the new total in the dialog; this figure is only the suggestion. For a chain with no paid seat it raises the ceiling for the rest of this run, and \"none\" removes it. \"none\" is refused where the user set COUNCIL_MAX_USD_LIMIT; a figure above that limit is refused; 0 is refused."
  2. First observedv0.8.1

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does real work: it discloses that completed stages replay from disk at zero cost, and that a paid run triggers an interactive dialog asking the person for a new total with max_usd as only a suggestion. It does not cover failure behavior (e.g. what happens when the run is not paused) or whether resumption is idempotent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the verb, and every clause adds information about a distinct resume path or cost behavior. The phrasing 'a run its spending limit stopped' is slightly awkward and costs a re-read, but nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation with no annotations and no output schema, it covers both invocation triggers, the cost/caching model, the interactive prompt, and the sibling relationship. Gaps remain around error conditions and what the caller gets back, but the essentials for correct invocation are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

max_usd is thoroughly documented in the schema itself, and the description only restates that it is the suggested figure. The 'run' parameter has no schema description at 50% coverage, and the description never clarifies that it is the run identifier or its accepted format, leaving the undocumented half unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource ('Resume a paused run') with the two distinct pause causes enumerated (external stage answered, spending limit hit). It also differentiates itself from the sibling submit_stage, which covers the first case automatically, so an agent can pick between them without reading either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states both conditions that warrant a resume and explicitly names submit_stage as the alternative for the external-stage case, effectively telling the agent when this tool is redundant. The spending-limit path is spelled out as the genuinely distinct use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.