generate_video

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

With no annotations, the description carries the full burden and does disclose the critical behavior: this is an async submit-and-poll operation, and some model mappings are unverified (only Wan text-only smoke-tested). It leaves out error handling, rate limits, and where the submit actually lands, but the async contract is the key risk an agent faces and it is front-loaded.

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?

Very short and front-loaded – the submit/poll contract comes first, then mode requirements, then the verification caveat. The telegraphic style ('t2v', 'i2v', 'r2v') risks being opaque to an agent that has not read the model enum, which costs it a point.

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 needn't be explained, and the async pattern is covered. But it says to query task_id 'later' without naming get_task as the tool to poll with, and several generation-shaping parameters (duration, resolution, ratio, seed) remain entirely undescribed on an 8-parameter 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 coverage is 0%, so the description must compensate; it explains image_url, reference_urls (including the 1-9 bound), and the omit-for-defaults convention. However, seed, ratio, duration, resolution (enum), and the four model values beyond the i2v/r2v distinction are undocumented in both places, leaving half the surface unexplained.

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 ('Submit video generation') plus the async continuation ('query task_id later'), which distinguishes it from edit_video and generate_image. It stops short of explicitly naming those siblings, so an agent must infer the boundary from the name alone.

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 concrete mode-selection guidance: i2v requires image_url, r2v requires 1-9 reference_urls, and optional params should be omitted to get upstream defaults. It does not say when to prefer generate_video over edit_video for modifying an existing video, which is the main sibling ambiguity.

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