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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), yet the description adds substantial behavioral context: mode-by-mode semantics, assetRequired/assetRequiredWhen constraints, audio policy rules, the rule that references must be private MaxVideoAI assets and never public HTTPS URLs, and that only live generation-enabled modes are executable. This is unusually rich disclosure beyond the 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 purpose is front-loaded in sentence one, but the body is a dense wall of mode abbreviations (t2v, i2v, ref2v, fl2v, v2v, r2v, extend, a2v, retake, reframe) and policy rules that read like return-value documentation crammed into a description. Much of it arguably belongs in an output schema; the density hurts scannability even if most sentences are individually relevant.

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 carries the full burden of explaining what is returned — mode requirements, settings, reference roles/counts, durations, audio policy, seedanceWorkflow, aspectRatios, and promptingSources — and it does so thoroughly. Nothing an agent needs to call this lookup correctly appears missing.

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 100% and there is only one parameter, so the baseline is already high. The description still adds meaning by clarifying that the ID must be an exact public model ID obtained from list_models or recommend_models, which constrains valid values beyond the schema's minLength/maxLength.

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 sentence gives a specific verb (read/retrieve) and resource (exact current capabilities, limits, evidence and reviewed promptingSources for one known public model), and immediately scopes it to a single known model ID. It is clearly distinguishable from siblings like list_models, recommend_models, calculate_project_budget and compare_generation_prices.

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?

Explicit when-to-use (before budgeting or quoting, to read mode requirements) and explicit when-not-to-use ('Do not use this for exact pricing, generation, hidden models, or provider guarantees'), which routes the agent to the budgeting/pricing and generation siblings. It also instructs how to handle empty promptingSources rather than substituting web search.

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