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

Annotations already declare mutation (readOnlyHint=false), openWorld, non-idempotent and non-destructive, so safety is covered. The description adds real value by disclosing the error condition (both/neither source fails) and the model lock. It still omits the async/webhook lifecycle (callback_id is a webhook trace id) and whether the operation is long-running or whether reference_images/ratio alter behavior, which matters for a media-mutation tool at this cost.

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?

Terse and front-loaded: the purpose line comes first, then the constraints in short bullet-like lines with no filler. Some information is duplicated verbatim in the schema-level description, but the tool-level text itself is efficiently structured.

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 10-parameter, zero-required, non-read-only media tool with no output schema and several undocumented parameters, the description is too thin. It omits the edit outcome, output/return handling, async completion behavior, and how the large set of remaining parameters interact, so an agent would have to guess on most calls.

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 only 20%, so the description must compensate, yet it explains roughly 3 of 10 parameters (model, workspace_id/video_url exclusion, mask_url). Prompt, ratio, resolution, callback_id, idempotency_key and reference_images carry no meaning in either place, leaving the majority of the surface undocumented.

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?

It names a resource ('视频' / video) and verb ('编辑' / edit) plus a key constraint (only seedance-2.0, source video via workspace_id XOR video_url), which is more than a bare tautology. However, it never says what the edit actually accomplishes (text-driven restyle? local repaint?) nor distinguishes itself from the many siblings (video_inpaint, video_magic_eraser, video_extend, video_enhance_v2). An agent cannot confidently route between these tools from this text.

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 a concrete invocation rule: pass exactly one of workspace_id/video_url, and it explains the optional mask_url enables local editing. That is useful conditional guidance for calling the tool. But there is no when-to-use-this-vs-alternatives guidance against the ~15 sibling video tools, and no prerequisites or ordering information.

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