run

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers: it flags the plan prerequisite, that the call is long-running, that it streams progress, and that it checkpoints per step. It does not contradict any structured data. Minor gaps remain around failure modes and post-run return behavior, but for a mutation/execution tool with zero annotation coverage this is strong disclosure.

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?

Two sentences with zero wasted words. The first is front-loaded with the core purpose and pipeline, and the second efficiently packs the parameter semantics plus the three key behavioral notes. Every clause earns its place.

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?

Complete for an execution-loop tool: purpose, all cap parameters, the plan prerequisite, and runtime behaviors (long-running, streaming, checkpoints) are all covered. Missing only a note on what the agent receives on completion or on failure/rollback behavior, which matter given there is no output schema to fall back on. Minor gap, not a blocking one.

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 for 3 of 4 parameters: it explains that 'until' stops after N tasks and that 'max_agent_calls' and 'max_budget_usd' cap spend. Only project_id is left implicit, which is reasonable given the plan prerequisite. This adds genuine meaning beyond the bare type names in the schema.

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 ('Run') and a concrete resource: the subagent-driven execution loop, spelled out as 'implementer -> server-verified TDD gate -> reviewer, per task'. This pipeline description cleanly differentiates the tool from siblings like make_plan, approve_plan, status, and health, so an agent can select it correctly without opening the schema.

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 clear context on prerequisite state: 'Requires an approved plan', which implicitly routes the agent to call this only after approve_plan. It also explains the purpose of the cap parameters. However, it does not explicitly name alternatives or list when-not-to-use conditions, so the guidance is contextual rather than exclusionary.

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