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

With annotations only covering safety/idempotency flags, the description adds genuinely new behavioral context: the task is async, results are delivered via webhook, and per-model limits are validated server-side rather than client-side. The one gap is that the async lifecycle details (task ID return, webhook payload) are only gestured at.

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 short lines, front-loaded with the generation modes followed by the async workflow and the model-variability caveat. Nothing is padded, though the terseness borders on under-specification for a 12-parameter tool.

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 12-parameter, no-required-field, no-output-schema tool, the description covers the async lifecycle and model variability but omits concrete return handling — no mention of what the submit call returns (task ID?) or what the webhook payload contains — leaving the agent to infer the full round trip.

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 67% and the schema's own top-level table already documents the per-model duration/resolution/ratio/reference_* matrix in detail. The description only restates that these limits 'vary by model', so it adds little beyond the structured data — the baseline 3 applies.

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 states a specific verb and resource (视频生成) and enumerates the generation modes it covers: text-to-video, image-to-video, first/last-frame, and multi-reference media. That distinguishes it reasonably well from editing/extending siblings like video_extend or video_edit, though no sibling is named explicitly.

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?

It gives operational guidance — the call is asynchronous, status is polled via /openapi/v1/work/status, and the result arrives by webhook — which tells the agent how to consume the tool. However, it never states when to choose video_generate over alternatives such as video_extend, video_edit, or image_create.

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