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

With no annotations, the description carries the full burden and does substantial work: it discloses credit costs per tier (10/25/30), expected wall-clock times (30s to 2-3min), and the timeout-plus-recovery path via get_render_status, which implicitly reveals this is a long-running synchronous call. Gaps remain around whether credits are consumed on failure and whether the asset persists if the call errors.

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?

Front-loaded with the core action, then tier economics, then the two actionable caveats (timeout recovery, prompt quality), each in a compact sentence. The credit/latency list is dense but every element is decision-relevant; only the capitalized "IMPORTANT" framing is slightly wasteful.

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 6-parameter, no-output-schema tool this is close to complete: it covers cost, expected latency, timeout recovery, default duration, and prompt pre-processing. The one thing an agent would still want is what the call returns (asset ID vs URL) so it can chain into get_render_status or list_assets, but the timeout sentence covers most of that workflow need.

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%, so baseline is 3; the description adds genuine value by attaching cost and latency trade-offs to model choice and reaffirming the 5-second default duration. However, it describes only the legacy draft/standard/best tiers and omits the primary enum values seedance, kling, flux, and h3-max entirely, so an agent reading the description alone would misjudge the real model space.

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 transformation: "Generate a video from a still image using AI." It names the input resource (still image), the output (video), and the underlying operation, which makes it easily separable from siblings like generate_image or stitch_video.

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 concrete conditional routing: use enhance_prompt first when the prompt is generic, and use get_render_status if the call times out. That is real when-to guidance tied to named alternatives, though it never distinguishes this tool from generate_image or stitch_video for similar-looking tasks.

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