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

Annotations only cover the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false); the description adds genuinely new behavior: the call is asynchronous with a job_id and requires polling check_job until status=done, motion control is billed ~13 coins/s with a 3s minimum and a hard requirement for both image_url and motion_video_url, and defaults are applied without confirmation. That is exactly the operational context annotations cannot express.

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 trigger and defaults before the advanced motion-control block, and nearly every clause carries actionable information. It is dense and parenthetical-heavy in places (cost notes, model aliases), so it reads as a long paragraph rather than clearly separated sections, but 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 10-parameter generation tool with no output schema, the description closes the critical gaps: it states the return value (job_id), the required follow-up (poll check_job), defaulting behavior, and the one model whose parameters behave non-obviously. An agent could invoke this correctly without further knowledge.

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?

With 60% schema coverage, the description carries real weight: it pins defaults for model/aspect_ratio/duration/resolution/audio, explains how reference_image_urls enables character consistency and that order matters, and spells out the model-specific coupling of image_url + motion_video_url with duration matching the driving clip. Remaining gaps are minor — the grok_* and kling_2_6 enum values and the aspect_ratio options are never characterized in prose.

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?

Opens with a specific verb+resource ('wants a video made') and names the concrete output pipeline (job_id then check_job), which cleanly separates it from generate_image and check_job. The Dora/Seedance default is stated explicitly, so an agent knows exactly what this tool produces.

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 an explicit trigger ('whenever the user wants a video made, even if they do not name Dora'), an explicit instruction not to interrogate the user ('only ask what the user wants to create; generate straight away with these defaults'), and a rule for when to deviate ('change one only when the user asks'). It also routes a distinct sub-use-case (motion transfer) to the specific model and names the follow-up tool check_job, leaving little to inference.

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