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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real operational context: it shares a daily quota with 60fps_get_motion_breakdown, and it specifies that a present `generated` value is a complete compile-checked file that must be printed in full rather than summarized — an output-handling rule the annotations do not convey.

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?

Purpose and the key reconstruction constraint are front-loaded, and the pairing/quota guidance is compact. It runs slightly long, and the closing reprimand about summarizing rather than printing carries some redundancy, but each sentence still carries usable instruction.

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?

An output schema exists, so return values need not be re-explained, yet the description usefully characterizes the `generated` payload. Combined with the sequencing, quota, and sibling-pairing guidance, an agent has everything needed to call this correctly last in the workflow.

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 100%, so slug, framework, and response_format are already fully documented in the schema; the baseline is 3. The description mentions motion_params, but that is a property of the shot data rather than a call parameter, so it adds no invocation guidance beyond the schema.

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?

States a specific verb+resource ('Get starter SwiftUI code to recreate a shot's motion') and explains the transformation applied (motion_params become real SwiftUI Animation values). It explicitly names and differentiates from the sibling 60fps_get_motion_breakdown, telling the agent which artifact each provides.

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?

Gives explicit sequencing ('Use it last, when the user wants to build the motion'), names the complementary sibling to pair with, states the daily-limit cost, and adds a clear when-not condition by redirecting recreation of motion rather than copy/brand/assets.

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