volante_run

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It discloses that the tool plans a DAG, filters hard mismatches, executes one-shot or in an agentic loop, synthesizes one final answer, and returns status, cost, and route evidence. It also discloses routing behavior for each `prefer` option, going well beyond what annotations could provide.

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?

The description is front-loaded with the core purpose, followed by a structured bulleted list for `prefer` options. Every sentence adds value: the first paragraph explains the orchestration pipeline, return values, and execution modes; the second focuses on the parameter semantics. No fluff or redundancy.

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?

Given the tool's orchestration complexity and the absence of sibling tools, the description covers all essential aspects: input (goal, prefer), execution behavior (DAG planning, routing, one-shot/agentic loop), and output (answer, status, cost, route evidence). The output schema further supplements return details, so nothing critical 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 description coverage is 0%, so the description must compensate. It does so for `prefer` by enumerating all valid values and their semantics, and for `goal` by using the uppercase placeholder in the context of orchestration, making it clear it is the high-level task. The only minor gap is that `goal` is not explicitly defined as a string, but the schema already provides the type.

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 'Orchestrate GOAL across the configured models', using a specific verb and resource, and then clearly details the workflow: planning a task DAG, filtering capability mismatches, routing sub-tasks, running them, and synthesizing a final answer. This makes the tool's purpose unmistakable even without named siblings.

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?

The description implicitly tells when to use this tool—when a complex goal must be broken into sub-tasks and routed across models. It also explains the `prefer` routing objectives (quality, cheap, local, cash_protect_quota) and the default, giving clear decision context. It does not explicitly state when not to use it, but no alternatives or siblings exist, so this is acceptable.

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