download_output

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

Annotations only include destructiveHint=false, which the description does not contradict. The description adds useful behavioral context: it defaults to output.pdf and the schema notes 'Never overwrites.' However, it doesn't disclose what happens if no compile has been run, whether the artifact is a file or directory, or any side effects. With minimal annotations, the description carries some burden but provides only partial transparency.

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?

Three short sentences, each earning its place: what it does, the precondition, and the default. Front-loaded with the action and resource.

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 simple download tool with one required parameter and no output schema, the description is mostly complete. Gaps: no mention of error behavior if compile hasn't run, no mention of whether the artifact name must match a file in the compile output, and no explicit alternative routing to download_file/download_project. Still, the core usage is clear.

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 50%: output_path is documented in the schema, artifact is not. The description adds meaning for artifact by stating the default 'output.pdf', which is helpful. It doesn't explain what artifact values are valid beyond the default, but the schema already covers output_path's semantics. Baseline 3 is appropriate.

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 states a specific verb ('Download') and resource ('an artifact from the last compile'), and distinguishes it from sibling download tools by tying it to the compile step. It doesn't explicitly name sibling alternatives, but the context is clear enough.

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 a clear precondition: 'Run compile first.' This tells the agent when the tool is valid. It doesn't explicitly say when to use download_output vs download_file or download_project, but the compile-specific context implies the distinction.

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