mission_run

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

No annotations are provided, so the description carries the full burden, and it covers the key runtime behaviors: server-side continuation after client timeout, step-count semantics (dispatches vs retry budget), resumability, and report/proof output. This is exactly the kind of operational nuance an agent needs before calling.

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?

Each sentence conveys a distinct, high-value fact: purpose, resumability, step semantics, timeout behavior, and response shape. The information is front-loaded and dense without being rambling.

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 complex control-loop tool with no annotations and many siblings, the description is unusually complete: it covers the loop's purpose, continuation, timeout safety, step counting, and response structure. It does not elaborate on the optional repo parameter or map every sibling relationship, but the core selection and invocation guidance is present.

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%, but the description provides essential semantics for max_steps, clarifying that it counts dispatches and does not consume the feature attempt budget. mission_id and repo are recognizable from their titles, so the only genuinely ambiguous parameter is explained.

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 opens with a specific action ('Advance the mission control loop') and enumerates its inner steps, clearly identifying this as the main driving tool rather than a single validation or retry tool. It distinguishes mission_run from siblings like mission_validate and mission_retry_feature by framing them as parts of the loop it advances.

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 explicitly states that the call is resumable and that an in-progress mission should be continued by calling again. It also gives a concrete when-not-to-reissue rule: after a client-side timeout, poll mission_events instead, preventing duplicate dispatch.

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