resume_run

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

No annotations are provided, so the description carries the full disclosure burden. It usefully explains that failed items are retried and unprocessed ones finished, and clarifies the wait flag's blocking behavior, but omits whether the call is idempotent, what state it mutates on the existing run, and any permission requirements.

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

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

Purpose is front-loaded in one sentence, followed by a compact Args block with no filler. The structure is efficient, though the Args list is a slightly verbose way to convey three short hints.

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

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

An output schema exists, so return values need not be explained, and the description covers the core mutation behavior plus the wait-mode return. Remaining gaps (idempotency, effect on already-completed items) are minor for a resume tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: run_id ('the run to resume'), concurrency ('parallel questions in flight'), and wait ('block until finished and return the report') are each given meaning beyond the bare type. It could still clarify the concurrency default of 4.

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

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

The description states a specific verb and resource: retry failed items and finish unprocessed ones on a run. It is clearly distinguishable from start_run (new run) and run_status/get_report (read-only inspection), though it does not name those siblings explicitly.

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

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

It gives a clear when-to-use condition: 'after an interruption or rate-limit errors.' However, it names no alternatives or exclusions (e.g. when to call start_run vs resume_run), so the routing guidance is incomplete.

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