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

With no annotations provided, the description carries the full burden and delivers substantially: it discloses asynchronous behavior (job id returned immediately), billing implications ('nothing is charged yet'), the polling protocol, and automatic brand personalization when enabled. Operational behavior that the schema cannot express is fully surfaced.

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 sentences, front-loaded with purpose, then the key behavior (async + job id + billing), then the polling workflow, then the brand personalization conditional. Every sentence earns its place; there is no fluff or repetition of schema content.

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?

Despite no output schema and no annotations, the description explains the return value (job id), the completion condition (status 'completed'), how to obtain the final hosted URL (get_video), and billing behavior. Nothing essential is missing for a 2-parameter async creation tool.

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 both prompt and aspect_ratio are already fully documented; baseline is 3. The description adds only marginal parameter context by calling prompt a 'text description' and hinting that brand personalization may alter how the prompt is applied. It does not expand aspect_ratio meaning beyond the schema's enum.

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 and resource: 'Start generating a video from a text description.' It clearly differentiates from siblings — video creation versus image/music/speech/text generation — and explicitly names get_video as the retrieval sibling, so an agent can distinguish roles without opening schemas.

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 description defines the workflow explicitly: use this tool to start generation, then 'Poll it with the get_video tool every few seconds until the status is "completed"'. This routes the agent to the correct sibling for status checking. It does not explicitly state exclusions among the generate_* siblings, but the purpose clarity makes those boundaries obvious.

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