Generate a video (any model)

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

Beyond the annotations (which only say this is non-read-only, non-destructive, non-open-world), the description discloses the blocking default (waits for result), the async escape hatch via wait=false and get_job, a billing caveat (Seedance models consume a separate allowance), mutual-exclusion constraints, and that lip-sync clip length is dictated by the audio. These are exactly the behavioral traits an agent cannot infer from structured fields.

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 mode enumeration is front-loaded and each clause carries information an agent needs (model families, parameter pairings, quota note, wait behavior). The sentences are long and densely packed, which makes the middle harder to scan than it needs to be given 17 parameters.

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 17-parameter, zero-required-parameter tool with strong output schema and 88% schema coverage, the description supplies the missing model-selection logic, the required-inputs handoff to list_video_models, and the per-mode parameter contracts. An agent can compose a valid call for each supported mode from this text alone.

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 already 88%, so the baseline is 3, but the description adds real cross-parameter semantics: first entry of imageUrls is the start frame with an optional end frame, audioUrl pairs with one image for OmniHuman/Kling Avatar or with sourceVideoUrl for Kling Lip Sync, and reference* arrays are model-gated and mutually exclusive with imageUrls. A few params (generateAudio, aspectRatio) are not addressed in the description, so it falls short of 5.

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 concrete verb+resource ("Generate a video with any model on the EzUGC dashboard") and enumerates the distinct generation modes it covers (text-to-video, image-to-video, references, lip-sync). It does not differentiate itself from sibling tools generate_ugc_video and generate_brand_video, even though its 'optionally ground it in a saved brand' capability clearly overlaps with the latter.

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 clear operating instructions: call list_video_models for model ids and requiredInputs, use wait=false plus get_job for async polling, and which parameter combination each mode requires. It also states an exclusion (frames and references cannot be combined). What is missing is routing guidance against the sibling video-generation tools that appear to do similar work.

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