generate_video

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

It discloses two useful behavioral traits: the task is submitted without waiting, and model names map to different endpoints. Since no annotations are present, this behavior burden is only partially carried; it does not describe what the function returns, how to track the task, or side effects beyond creation.

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?

The text is one efficient block with no fluff. The most important distinction (no wait) is front-loaded, and routing details are placed exactly where they support the 'model' parameter. Every sentence earns its place.

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?

The description covers the key capabilty and routing behavior, but with no annotations and no output schema, it leaves gaps: return representation, subsequent status-check flow, and model restrictions/limitations. The agent can infer most call mechanics from a 100% schema, but the async feedback loop is not fully explained; it relies on the sibling tools to fill the gap.

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 descri completeness is 100%, so baseline is 3. The description adds meaning by explaining that the 'model' parameter determines routing, and that model families are routed to different endpoints. It also makes the image/prompt/video mode distinctions easier to reason about.

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 uses a specific verb and resource combination ('提交视频生成任务' submit video generation task) and explicitly states that it is non-blocking ('不等待'). It also states the automatic route by model name, distinguishing it from both image generation and waiting variants.

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 clearly establishes that this is an asynchronous submission operation, which implies that callers needing a completed video should use the waiting sibling. It does not explicitly name 'generate_video_and_wait' or 'get_video_status' as alternatives, but the routeing logic gives practical guidance for model selection.

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