Run a Wiro workflow

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

Annotations declare the mutation/non-idempotent profile, and the description goes well beyond them: per-step billing to the wallet, a $0.50 balance prerequisite per model step, the fact that a started run cannot be stopped and keeps going, and breakpoint/resume semantics. This is precisely the cost and irreversibility context an agent needs before a non-idempotent write.

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 and front-loaded: purpose first, then cost warning, then breakpoint mechanics, then continuation rules. Nearly every clause earns its place, though the input-key sourcing sentence and the balance prerequisite make it a long single paragraph that could be broken up for scanability.

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?

For a paid, non-idempotent, open-world run trigger, the description covers cost, prerequisites, irreversibility, partial-execution testing, and continuation. An output schema exists, so return values needn't be described, and nothing an agent needs to call this safely is missing.

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 coverage is 100%, so baseline is 3, but the description adds real routing value: it tells the agent where to source `input` keys (get_workflow, create_workflow, save_workflow_from_agent) and frames `breakpoint_node_id` as the testing mechanism tied to layer boundaries and resume. It doesn't restate the 0-600 range or URL-slug form, which the schema already handles.

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?

Opens with a specific verb and resource ("Start a workflow run") plus a scope qualifier ("wait for it up to `wait_seconds`"). It is clearly distinguishable from siblings like wait_for_workflow_run, resume_workflow_run, and create_workflow, each of which it explicitly names or implies.

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 explicit when-to-use conditions ("only when the user asked for this run, and tell them the estimate first"), an alternative for long runs ("continue with wait_for_workflow_run"), and a hard prohibition ("never call run_workflow again for the same job"). This is a full routing decision tree.

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