Resume a Wiro workflow run

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

Annotations only cover the safety profile, and the description goes well beyond them: steps replay with the original inputs/settings, workflow edits apply only to new runs, completed steps are preserved and not re-charged, and failed/skipped/unrun steps are re-billed to the original paying wallet. For a non-idempotent, open-world mutation with real billing consequences, that is exactly the missing context.

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?

Dense but front-loaded: purpose first, then replay semantics, then billing, then the confirmation policy, then the hard precondition. Every sentence carries operational information; nothing is filler.

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 described. The description covers the remaining agent-critical unknowns — cost implications, step replay behavior, user-confirmation requirement, and the canResume precondition — leaving nothing needed to call it correctly.

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 100% and all three parameters are documented in the schema, including full breakpoint_node_id inheritance/null semantics. The description adds only the 'same run token' framing, so the schema is doing the heavy lifting — baseline 3.

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?

States a specific verb (continue/resume) and resource (workflow run) plus the precise precondition: a run that failed or stopped at a breakpoint, on the same run token. That clearly separates it from run_workflow (new runs) and wait_for_workflow_run (polling).

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?

Gives an explicit gate ('use it only when wait_for_workflow_run reports canResume: true') and explicit interaction policy ('ask the user before resuming, unless they asked you to continue this run; then give the expected cost in one line and resume'). Both when-to-use and when-to-ask are spelled out.

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