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

Annotations already assert read-only, non-destructive, idempotent. The description adds meaningful behavior: it locates an existing render, doesn't re-cut anything, and return a zip bundle. This goes beyond the annotation and clarifies that the tool has no side effects on the underlying score.

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?

Every sentence contributes a non-redundant point: the trigger, the zip contents, the editorial workflow, the same-args rule, and the no-recut guarantee. The structure front-loads the core purpose and provides the essential operational fact in bold. No wasted words.

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?

The description is complete enough given no output schema and seven parameters: it explains what the output is, how each file is intentionally named, and the exact call context to retrieve the correct render. The gap is not describing potential errors or whether all optional args need to be repeated, but the explicit 'same arguments' rule makes this a strong foundation.

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 low (43%), so the main burden falls on the description. It compenses with a he unique invocation contract: 'Call this with THE SAME arguments you passed to score_my_video — that is how it finds the right render'. This adds meaning to all params without mapping each one; it also specifically calls out brief and video_url as same values.

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 the verb (hand over), the resource (finished score files), and clearly lists the output bundle: zip with scored video, per-section M4As, and cue sheet. This distinguishes it from scoring or analysis tools like score_my_video or analyze_video.

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 specifies the necessary trigger condition ('once the user is happy') and tells the agent to call it with exactly the same arguments passed to score_my_video, which is strong usage guidance. It doesn't explicitly name exclusions or alternatives such as 'if revisions are needed, use feedback', but in the observable contextual detail, this is nearly sufficient.

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