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

While annotations already declare readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral context beyond them: zero credit cost, no external calls, null-semantics ('a null does NOT mean free/instant, it means unconfirmed'), defaults-stability assurance for existing callers, and the honest caveat that service/api.py accepts rarer values this tool deliberately omits. These are exactly the non-obvious behaviors an agent needs and none of them contradict the annotations.

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 long but every sentence earns its place: safety profile, usage directive with failure consequence, three-section return contract, null handling, defaults stability, and the curation caveat. It is front-loaded with the most decision-relevant facts, and the Returns block is scannable; only minor tightening of the final note would improve it.

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 and no parameters, the description fully carries the burden of documenting return values — and it does so exhaustively: the images/videos/defaults sections, the t2v/i2v/r2v mode enum, null behavior, and the scope boundary versus the underlying HTTP layer. Nothing an agent needs to invoke it correctly or interpret its output is 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?

The tool has zero parameters and the schema reflects that at 100% coverage, so the baseline 4 applies with no deduction. The description adds cross-tool parameter value by mapping its output keys to sibling parameters: `model` values for generate_image/generate_character_image and `video_model_key` values consumed via the generate_* tools' Literal types.

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?

States a specific verb and resource up front: 'List every valid model id this service accepts,' followed immediately by the safety profile (READ-ONLY, spends no credits, calls nothing outside this service). It distinguishes itself from sibling generation tools by naming generate_image/generate_video directly, so an agent can tell them apart without opening any other schema.

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?

Gives explicit when-to-use guidance: 'Call this BEFORE generate_image/generate_video if you're unsure of an exact id,' and reinforces it with the concrete failure cost of guessing (a hard HTTP 400 on a call that already committed to a task). It also names the alternative tools that this one is meant to precede, leaving nothing to inference.

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