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

Adds real context beyond annotations: zero-credit, queue-only, no provider render, and that re-calling is safe once the film finishes joining (consistent with idempotentHint=true). The gap is that it never says what comes back — a download URL, a job handle, or a status — which matters since there is no output schema.

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 tight sentences with the cost/scope signal ('Free') front-loaded, followed by the side-effect boundary and the retry rule. No filler.

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?

Covers cost, side effects, and the polling prerequisite well for a two-parameter tool. With no output schema, the missing piece is the return value — an agent cannot tell whether the MP4 link is returned here or fetched elsewhere.

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 coverage is 100%, so project_id's accepted forms (bare uuid or 'studio-video:<uuid>') and user_goal are already fully documented in the schema. The description only obliquely reinforces that project_id refers to an already-finished film. 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?

States a concrete verb and resource ('put a finished Video Studio film together as one downloadable MP4') and immediately distinguishes it from the Make/render path. An agent can tell it apart from make_studio_video and get_studio_video without reading any schema.

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?

Explicitly names when-not ('never presses Make, spends Creative Credits or starts a provider render') and routes to the alternative: 'poll get_studio_video and call this again when it is ready.' Both the exclusion and the fallback condition are spelled out.

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