list_video_models

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

With readOnlyHint/destructiveHint/openWorldHint already covering the safety profile, the description adds genuine operational context: pricing_status is live and independent of visibility ('prices never filter model visibility'), a default_model_type is returned, and variable-duration models require a backend duration protocol ID plus real_duration from capabilities. This is real behavior beyond the annotations, though the duration-protocol mechanics remain cryptic.

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 first sentence is front-loaded and earns its place, but the pricing_status independence claim and the duration-protocol sentence are dense and partly redundant, and the closing sentence is cryptic. The block reads as packed operational notes rather than a cleanly prioritized description.

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?

With no output schema, the description usefully names what comes back (capabilities, live pricing_status, default_model_type), which is exactly what an agent needs to act on the result. It is close to complete for a read-only catalog tool, losing a point only for the unexplained duration-protocol requirement.

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 0%, so the description must carry parameter meaning. It enumerates the operation values (mostly duplicating the enum) and names the default, and gives a thin gloss for generate_audio ('Select generate_audio to match the quote'). That is a partial compensation, not a full one, since the non-obvious 'duration protocol ID' concept is referenced but never tied to a parameter.

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 opening clause states a specific verb+resource ('List the complete current Web video catalog') plus the payload (capabilities and pricing_status), clearly distinguishing it from list_image_models / list_music_models / list_tts_models. The remaining sentences drift into selection instructions rather than purpose, but the core intent is unambiguous.

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 conditional guidance for the operation parameter ('Select text_to_video (default), image_to_video...') and a rule for model defaulting ('When the user has not specified a model, use the returned default_model_type'). However, it never says when to call this versus the adjacent catalog/costing tools (estimate_video_cost, generate_video, preview_video_task), so routing against siblings is left to inference.

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