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

The annotations already declare the non-read-only, non-idempotent, non-open-world profile, so the description need not restate safety. It usefully adds a cost model ('15 credits per second'), which is real behavioral information absent from the structured fields, but it omits that generation is likely asynchronous and may require polling via the sibling 'check_generation', a significant omission for a non-idempotent operation.

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?

Two sentences with no filler; the capability and its use cases are front-loaded and the cost caveat follows immediately. Every clause carries information an agent would act on.

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 five-parameter generative tool with no output schema and two undocumented parameters, the description leaves meaningful gaps: it never says what the tool returns (job id? asset key?) or whether the call blocks or must be polled. It compensates partially with cost and input-shape detail, but an agent could not fully plan a call sequence from this text alone.

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 60%: images, prompt, and duration are documented in the schema, while width and height have no descriptions at all. The description reinforces the 1–7 image constraint and the prompt-plus-images input shape but adds nothing about resolution parameters or duration bounds beyond what the schema already states.

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 names a specific verb and resource ('Generate a short video clip') and enumerates concrete output archetypes (trailer shot, cutscene, animated background), so the agent knows exactly what it produces. It stops short of distinguishing itself from the sibling 'extend_video', which is the closest alternative an agent could confuse it with.

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?

The parenthetical examples imply when the tool is appropriate, and the per-second credit cost gives a decision signal. However, there is no explicit when-not guidance, no mention of 'extend_video' for lengthening an existing clip, and no statement of prerequisites such as having called get_asset first to obtain image keys.

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