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

Annotations already mark this as a non-idempotent write with no destructiveness; the description adds substantial non-obvious behavior: a random 5-character suffix is appended to the name, a voice URL is persisted as a voice BEFORE the tag check (hence the character-only warning), video is trimmed to the first 8s, and the call is usually free and takes ~5-30s. These are real side effects and latency/cost disclosures beyond the schema and 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?

Front-loaded with the primary image/video source, then voice rules, then auto-detection opt-outs, then side effects, cost and endpoint. Dense but each sentence carries distinct, actionable information with 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?

Rich on inputs, modes, side effects and latency for a 10-param creation tool, and no output schema exists to explain returns. It does not state what the call returns (e.g., the created element id) or how to reuse the element afterwards, which an agent needs to chain into kling_elements_video.

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, but the description adds meaning the schema lacks: the video's first 8s retention, the voice sample spec (MP4 with speech, 5-60s), and the ordering rule that voice is saved before tag validation. Those extras lift it above a pure schema restatement.

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 (save/create) and resource (a reusable element on a Kling account) and immediately scopes the two input modes (image via coverImage + extra views, or a 3s+ video). It distinguishes itself from siblings by naming kling_list_element_voices and kling_list_element_tags for the lookup steps rather than the creation step.

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?

Clear conditional guidance: give tag/description to skip auto-detection, and 'give a voice only to character elements' with the reason stated. It points to kling_list_element_voices for voice names. It stops short of explicit routing against alternative creation tools or a stated 'when not to use this', so 4 rather than 5.

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