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

Annotations only say it's a non-read-only, open-world, non-idempotent call; the description adds substantive behavior – that it consumes Kling credits with per-second rates, that it is an async job ('A job, like kling_text_to_video'), and the per-version durations, reference caps and audio defaults. It doesn't cover what happens on failure, queueing, or how to poll, which keeps it below a 5.

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 the first clause, but the remainder is one long multi-clause sentence stitched with semicolons and parentheses, making the version matrix hard to parse at a glance. Nearly every clause carries information, but the structure works against quick scanning.

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 50-parameter generation tool with no output schema and no required fields, the definition covers model capabilities and costs well but says nothing about the return value, how the resulting task is polled (kling_get_task) or retrieved (kling_get_download_url), or what invalid reference combinations do. 'A job, like kling_text_to_video' is the only hint about the async lifecycle.

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 the baseline is 3, but the description contributes semantics the schema lacks: per-version reference limits (v3 up to 7 images+elements, v4 up to 10 images / 5 videos ≤30 s / 3 voices / 15 references), the v4-flash restriction to std/720p with no voices, and the note that video_1 on o1/v3 sets the length. That cross-parameter and per-version meaning is not derivable from the flat field list.

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 description opens with a concrete verb+resource: 'a video from a prompt with references named in it as @image_N, @element_N, @video_N and @voice_N', which tells the agent exactly what this generates and how the prompt syntax works. However, the only sibling mention is an analogy ('A job, like kling_text_to_video'), not a differentiation against kling_image_to_video or kling_elements_video, so the agent must infer when Omni is the right choice.

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?

It gives real decision aid inside the tool – version tradeoffs ('v4-flash … 6 credits a second', 'v4 … audio always on', 'o1 (3-10 s)') and an alternative path ('frame_start / frame_end (o1 / v3) make a start-to-end video instead'), plus a cost lever ('enable_audio false is cheaper'). What's missing is explicit when-to-use-this-vs-sibling routing, so usage is only implied relative to the other 40+ Kling tools.

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