fleet_delegate

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

With no annotations, the description carries the behavioral burden, and it discloses several important behaviors: the server reads files itself, output_path writes the answer to a file and returns only a preview, long tasks return a job_id, and node selection follows category-based routing with overflow. It leaves failure semantics, overwrite side effects, and the exact response envelope unspecified, but it covers the main operational behavior well.

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 dense but efficient: every sentence carries load, from the scoping sentence to the compressed category routing arrows. It is front-loaded with the core purpose and then adds behavioral detail without 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?

For an 11-parameter tool with no output schema, the description covers the main return modes (full result, preview with output_path, job_id for long tasks) and node routing, which is enough for an agent to call it correctly. It does not describe error handling, overwrite default behavior or structured output, but the input schema handles most parameter details and the description provides the missing context.

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 73%, so the description is not wholly responsible for parameters, but it adds real value: it explains output_path's write-and-preview behavior, clarifies category routing values, and notes that the worker sees only instruction, context, and files. Node and model override semantics are left to the schema, but the schema already documents those as normally-empty overrides.

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 ('Delegate ONE small task') and names the resource ('local model'). It clearly marks this as a single-task tool, distinguishing it from fleet_delegate_batch and connecting to fleet_job for long tasks. No ambiguity about what the tool does.

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 gives explicit usage context: use for a single small task, and if the task is long, expect a job_id to poll with fleet_job. Category routing provides guidance for node selection, and the 'ONE small task' scope strongly implies that multiple tasks belong elsewhere. It does not explicitly name fleet_delegate_batch as the alternative for multiple tasks, but the scoping makes the intended use clear.

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