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

With no annotations provided, the description fully discloses behavioral traits: it is currently a stub that responds synchronously, is non-idempotent (mints a new video_id per call), inserts a usage_log row, and outlines future scope changes. It also documents error codes, rate limits, and side effects, going far beyond basic safety hints.

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?

Although the description is long, it is well-structured with clear sections (When to use, When NOT to use, APS scopes, Rate limits, Errors, Side effects) and front-loaded with the main purpose. Every sentence provides actionable information, and the use of labels makes it scannable despite its length.

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 covers all essential aspects: what it does, when to use/not use, return values (video_id, download_url), current stub behavior, side effects, error handling, and rate limits. Given no output schema, it adequately explains the expected response, making the tool fully comprehensible for an agent.

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?

The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds a useful precondition not in the schema: the model must be 'translated' (processed by Model Derivative) for the tool to work. This goes beyond the schema's generic 'model to animate' and justifies a slightly higher score.

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 uses a specific verb+resource ('Queue a cinematic Twinmotion-style fly-through video of a translated model') and clearly distinguishes from siblings by specifying when NOT to use it (for real-time interactivity use get_viewer_link, for still images use twinmotion_render). It also states the return values (video_id and download_url), leaving no ambiguity about the tool's core function.

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?

Explicit 'When to use' and 'When NOT to use' sections name alternative tools (get_viewer_link, twinmotion_render) and provide concrete use cases (marketing/pre-con video scripted from an agent workflow). This is the gold standard for usage guidance.

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