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

Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the burden of behavioral disclosure. It clearly states this is the MOST EXPENSIVE operation, priced per second, charged on completion, using purchased credits only, and async via poll get_video. It also discloses the promotion discount and instructs the agent to quote from dry_run rather than the guide. This is rich, decision-relevant behavioral context.

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 description is dense and front-loaded with the most critical facts (cost, async, dry_run). It uses compact bullet-like lines and abbreviations to pack a lot of model-specific guidance into a small space. It loses one point because the pricing table is complex and somewhat hard to parse at a glance, but every sentence earns its place and there is no filler.

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, high-cost, async generation tool with no output schema, the description is remarkably complete. It covers cost model, billing timing, async polling, quoting flow, model selection per job, duration ranges, reference clip semantics, and the promotion. An agent has enough context to invoke the tool correctly and to ask the user for confirmation before spending credits.

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 92%, so the schema already documents most parameters well. The description adds meaningful semantics beyond the schema: it explains how reference_video_id behaves differently per model, how reference_image_ids counts differ per model, what duration defaults apply per model, and how mode maps to resolution tiers. It doesn't exhaustively restate every parameter, but it adds the cross-model constraints that the schema alone cannot express.

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 opens with a specific verb and resource ('Makes a video from an image the user owns') and immediately distinguishes the tool from siblings like generate_image and get_video. It also names the model families and their distinct jobs, so an agent can tell exactly what this tool produces and how it differs from related generation tools.

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 provides explicit when-to-use guidance: it explains the default model, when to choose each alternative (e.g., 'Cheapest clip WITH sound', 'Keep an existing clip's acting', 'Copy a dance or gesture'), and even instructs to quote with dry_run:true and confirm the number with the user. This is far beyond a minimal usage note and directly routes the agent to the correct model per job.

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