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

With no annotations, the description bears the full behavioral burden. It discloses that the operation is asynchronous by promising a returned Task ID and the callback_url param documents webhook notification. It does not cover permissions, cost, whether the extension is reversible, or rate limits, so meaningful gaps remain.

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 purpose followed by scannable use-case bullets; every line is relevant. The second sentence ('adding more motion and content after the original video ends') and the Returns block restate information already conveyed by the title or the output schema, costing some brevity.

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 an 8-parameter tool with an output schema present, the description needn't explain return values yet still gives a brief summary. Combined with the 100% schema coverage and explicit use cases, an agent has enough to call it correctly; only the async/permission behavior remains under-specified.

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 description coverage is 100%, so all 8 parameters are already documented in the schema, including enums, defaults, and the 5/10 second duration constraint. The description adds no parameter-level detail beyond this, which is the expected baseline 3 when the schema does the heavy lifting.

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+resource ('Extend an existing video') and clarifies scope: continuing a previously generated video rather than creating a new one. It implicitly separates itself from siblings like kling_generate_video by requiring a prior video_id, but never names an alternative explicitly.

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?

The 'Use this when' block gives three concrete scenarios (video too short, continue story/motion, build longer piece by piece) that establish clear context. However, it offers no when-not guidance or named alternatives such as kling_generate_video for fresh generations.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states the tool returns a Task ID and motion generation information, implying an asynchronous task-based workflow. However, it does not explain polling, error conditions, or that generation may take time. Some behavior is disclosed, but significant gaps remain.

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 well-structured with a concise summary, a bulleted list of use cases, and a clear Returns statement. Every sentence adds value and helps an agent decide when and how to use the tool without unnecessary verbosity.

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?

Given the tool's complexity (9 parameters, asynchronous task creation) and the presence of an output schema, the description adequately covers the core purpose and usage context. It lacks details about how to retrieve results or handle failures, but the Task ID return hints at the asynchronous pattern. The description is mostly complete for an agent to select and invoke the tool correctly.

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 schema provides 100% parameter coverage with detailed descriptions for all 9 parameters, so the baseline is 3. The tool description itself does not add extra parameter-level meaning beyond what the schema already contains, but it does not need to because the schema is sufficiently rich.

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 clearly states the tool's primary function: transferring motion from a reference video to a character image. It uses a specific verb-resource combination and directly differentiates from siblings like kling_lip_sync and kling_generate_video by focusing on motion transfer for character animation. The purpose is unmistakable.

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?

The description provides a clear 'Use this when' list with three concrete scenarios, giving an agent strong context for when to invoke this tool. However, it does not explicitly mention when not to use it or name alternative sibling tools, so it stops short of a perfect score.

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

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

With no annotations, the description carries the full behavioral burden; it does disclose that generation is asynchronous and must be polled via kling_get_task, which is real value beyond the schema. It omits cost/credit implications, failure/retry behavior, and whether prompt or multi_prompt is required for each shot_type.

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?

Two short sentences, front-loaded with the capability and followed by the required follow-up action; no filler. It is efficient, though the terseness substitutes brevity for needed specifics rather than reflecting a genuinely complete definition.

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 14-parameter generation tool with a nested shot array, no annotations, and 0% parameter documentation, the description is far too thin; the output schema plus 'poll' covers results retrieval, but the agent is left guessing how to construct custom multishot requests. A one-line note on multi_prompt vs prompt would close the main gap.

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 description coverage is 0% and there are 14 nested fields, yet the description explains only the model and shot-type dimension ('automatic or custom'). Key parameters such as multi_prompt/Shot.index, duration bounds (3-15), aspect_ratio, start_image_url/end_image_url, callback_url, and generate_audio get no explanation in either the schema or the description.

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 concrete verb and resource ('Generate ... multishot video') plus the supported models (V3/V3 Omni), which distinguishes it from the plain kling_generate_video siblings. It stops short of naming which sibling to use instead when the user doesn't need multishot.

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?

'Poll kling_get_task' gives a clear post-call workflow step, which is useful routing guidance. However, it never says when this tool is preferable to kling_generate_video, kling_generate_turbo_video, or kling_generate_video_from_image, leaving the alternative selection to inference.

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

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

With no annotations, the description carries the full burden. It usefully discloses two non-obvious behaviors: native audio is always on with no off switch (matching the const true schema field) and results must be polled. It omits cost/credit, permission, or failure behavior for a paid generation call.

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?

Three terse sentences with no filler; the capability statement comes first and the operational note (polling) last. Every clause carries information.

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?

An output schema exists, so return values need not be described, and the polling pointer covers the async workflow. Still, for a generative paid tool with a 0%-covered nested schema, the description leaves several parameters (mode, aspect_ratio, start_image_url) unexplained for callers.

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 description coverage is 0%, so the description must compensate, and it only partly does: it explains the duration range and the audio constraint, but says nothing about mode (std/pro), aspect_ratio, start_image_url, callback_url, or the prompt length limit.

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?

Names a specific verb (Generate) plus the model variant (V3 Turbo), resolution options, and duration range, which lets an agent distinguish it from the generic kling_generate_video. It does not mention text2video/image2video modes or name the sibling it is not, so sibling differentiation is only partial.

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?

The instruction to 'Poll kling_get_task' is genuine usage guidance for the follow-up step, which matters because async defaults to true. However there is no guidance on when to choose this over kling_generate_video, kling_generate_video_from_image, or kling_generate_with_assets.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose that the call returns a Task ID and video state, which implies asynchronous task-based generation, but it never states that polling (e.g. kling_get_task) is required, nor mentions latency, cost, or failure handling — significant omissions for a generation tool.

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?

Well front-loaded: purpose first, then when-to-use bullets, then the sibling pointer and return note. The middle sentence ('This is the simplest way... high-quality AI video') is mild marketing padding that doesn't add selection value.

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?

An output schema exists so return values need not be explained, and the schema is fully described, so the description's job is selection and routing — which it does well. The remaining gap is the async/polling workflow, which an agent calling a task-returning generation tool would 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 description coverage is 100%, so every parameter including model, mode, duration, cfg_scale, camera_control, and generate_audio is already documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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+resource ('Generate AI video from a text prompt using Kling') and immediately distinguishes itself from the closest sibling by naming kling_generate_video_from_image as the image-reference alternative.

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?

Explicit 'Use this when' bullets cover the three selecting conditions (text-only, no reference images, quick generation), and it names the alternative tool plus the condition that routes to it (reference images / start-end frames).

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

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

With no annotations, the description carries the full burden. It implies an asynchronous flow by promising a Task ID and mentions that a callback_url/return state exist, but it omits rate limits, auth needs, and processing time. Critically, it claims 'start_image_url is required' while the schema lists only 'prompt' as required, creating an internal inconsistency that could mislead the agent.

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 mechanism, then scannable bullets. Slightly redundant in repeating that start_image_url is required and end_image_url optional after already describing frames in prose, but overall tight.

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?

Adequate for a 14-parameter async generation tool with an output schema: the agent knows when to use it and the frame roles. However, it doesn't address the async task lifecycle or how this tool relates to look-alike siblings, and the required-vs-optional frame claim conflicts with the schema.

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 description coverage is 100%, so the baseline is 3. The description only restates the start/end frame roles, which the schema already documents; it adds nothing about model/mode/camera_control/audio interactions that the schema also covers.

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+resource+mechanism: generate AI video using reference images as start and/or end frames, and explains that Kling interpolates motion between them. This distinguishes it from text-driven siblings like kling_generate_video or kling_generate_turbo_video, though it never names those siblings explicitly.

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?

The 'Use this when' block gives three concrete scenarios (animate a specific image, transition between two images, precise visual control), which is clear situational context. It stops short of naming an alternative tool or stating when NOT to use this one.

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

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

No annotations are provided, so the description carries the full burden. It does add real behavioral context the schema lacks: V2.6 voices cost 1.68 Credits/second, and ownership is verified server-side. However it says nothing about the async default, task-based return flow, or what happens on verification failure.

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?

Three short sentences, front-loaded with the distinguishing capability, and each sentence carries content (capability, cost, verification). The cost sentence is slightly cryptic in isolation but not wasteful. No filler or repetition.

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?

This is a complex video-generation tool whose description omits the essentials: that output is asynchronous by default, which model/mode combinations are valid, duration limits, and how element/voice ownership must be established first. An output schema exists so return values needn't be explained, but the invocation-level gaps remain significant.

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 description coverage is 0% for a request object with roughly a dozen meaningful fields (mode, model, action, duration, aspect_ratio, async, generate_audio, start/end image URLs). The description only touches voice_id and element_id and the credit cost; mode/model/duration/async semantics are undocumented in both places, so it fails to compensate for the coverage gap.

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 verb 'Generate' plus the qualifier 'with platform element or voice IDs' identifies the tool's distinguishing inputs, which separates it from siblings like kling_generate_video or kling_generate_video_from_image. It never explicitly names the resource (video), but the schema's AssetVideoRequest makes that recoverable. Clear, though not as crisp as naming verb+resource+scope outright.

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?

Usage is only implied: the agent infers this is the tool to pick when it has an element_id or voice_id to attach. No alternative is named and no exclusions are given (e.g. 'for plain text-to-video use kling_generate_video'), so the routing decision is left to inference.

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

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

With no annotations, description carries full burden. It describes task states and that the tool returns video URLs and metadata. It does not cover rate limits or authentication, but for a simple query tool this is sufficient.

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 well-structured with sections (Use this to, Use this when, Task states, Returns). It is front-loaded and every sentence adds value.

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?

Given the tool has one parameter, an output schema, and clear task states, the description is complete. It covers purpose, usage, states, and expected return, meeting all contextual needs.

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 has 100% coverage on the single parameter, with a clear description of how to obtain task_id. The description adds little beyond the schema, so a baseline score of 3 is appropriate.

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 clearly states 'Query the status and result of a video generation task' with a specific verb and resource. It distinguishes itself from sibling tools like kling_get_tasks_batch by focusing on a single task.

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?

Provides explicit when-to-use scenarios (check completion, retrieve URLs, get details). However, it lacks explicit when-not-to-use guidance or mention of alternatives for batch queries.

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

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

No annotations provided. The description mentions returning status and video information but does not disclose behaviors like error handling for invalid task IDs, rate limits, or concurrency. The batch size limit is explained in the parameter schema, not the description.

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?

Description is concise and well-structured with a main sentence, a bullet list of use cases, and a return statement. It is front-loaded with the primary purpose and contains no redundant information.

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?

Given the presence of an output schema (return structure defined elsewhere), the description adequately covers purpose, usage guidance, and efficiency benefits. It could mention potential errors or performance characteristics, but overall it is sufficient for a batch query tool.

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% with the parameter 'task_ids' well-described (list of IDs, max batch size 50). The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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 clearly states it queries multiple video generation tasks at once, using a specific verb ('query') and resource ('multiple tasks'). It also distinguishes itself from the sibling tool 'kling_get_task' by noting it is more efficient for batch checking.

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?

Explicit 'Use this when' bullet points provide clear guidance on when to use this tool, such as checking multiple pending generations or tracking a batch. It implies when not to use (single task scenarios) by referencing the alternative 'kling_get_task'.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the async polling pattern implicitly via 'Poll kling_get_task' (consistent with async defaulting to true in the schema), but says nothing about permissions/auth, cost, watermarking, callback_url behavior, or how long generation takes.

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?

Two short sentences, front-loaded with the core action and the required inputs, with no filler. It is arguably too terse for the schema complexity, but nothing in it is wasted.

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 tool with a deeply nested request schema, 0% schema description coverage, and a 16-value content enum, this description is thin. The existence of an output schema removes the need to explain return values, but the required-content composition and settings are not covered well enough for reliable invocation.

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 schema has 0% description coverage across a large nested Content enum, so the description must compensate. It does add genuinely useful information by naming ref_image and goods_title as the content types this tool expects, which the schema never marks as required. Still, the other 14 content types, settings, and duration/aspect_ratio choices are left unexplained.

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 ('Generate product studio video') and narrows it by naming the two required content types, ref_image and goods_title. That distinguishes it reasonably well from sibling product tools like kling_apparel_video and kling_virtual_try_on, though it doesn't explicitly say how it differs.

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?

The second sentence, 'Poll kling_get_task,' is a useful next-step/routing hint that tells the agent what to do after invocation. However, there is no guidance on when to pick this over kling_video_commerce, kling_apparel_video, or kling_generate_video, nor any stated prerequisites.

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

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

With no annotations, the description carries the behavioral burden and mostly meets it: it explains the transformation (replacing speaker lip movements), the two modes, the TTS behavior in text2video mode, and the return value. It does not explicitly state that the source video is not modified or describe the asynchronous task workflow, but the returned Task ID strongly implies a new task/output.

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 organized well: a summary sentence, mode explanation, use-case bullets, and return value. It is not overly long despite covering a fairly rich tool, though the first and second sentences are mildly redundant.

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?

Given 11 parameters and no annotations, the description provides enough high-level context to correctly select and start using the tool. It would be stronger if it noted the async task nature and the need to poll kling_get_task or use callback_url, but the schema and output schema cover the detailed parameter relationships.

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 description coverage is 100%, so the baseline is 3. The description adds a small amount of extra meaning by noting that the source video can be supplied 'by URL or task ID' and that text2video generates audio via TTS, but it does not meaningfully deepen understanding beyond the schema.

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 defines a specific verb+resource: it synchronizes lip movements in an existing video to match audio or text. It clearly distinguishes itself from siblings by emphasizing the video lip-sync task, including the URL/task-ID source and mode-based behavior.

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?

The 'Use this when' bullets provide concrete, decision-relevant cases: dubbing, replacing generated-video audio, and creating talking-head videos from text. It does not explicitly state when to use a sibling tool instead, but the listed use cases are strong enough guidance for most selection scenarios.

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

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

No annotations are provided, so the description carries the disclosure burden. It states the tool returns a categorized list, implying a read-only operation, but does not explicitly confirm no side effects, authentication needs, or rate limits. This is minimally adequate.

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 short and to the point, but contains minor redundancy ('Reference guide...' adds little over the first sentence). It could be slightly more structured, but overall efficient.

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?

Given the tool has no parameters and an output schema exists, the description sufficiently covers its role. It explains the purpose, output nature (categorized list), and context (reference guide). No additional information is needed for agent understanding.

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 schema coverage is 100%. Per guidance, baseline is 4. The description adds no extra parameter info because none exist, but confirms the tool takes no inputs.

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 clearly states the tool's purpose: listing all available Kling API actions and corresponding tools. It is a specific verb-resource pair ('list actions') and distinguishes itself from sibling tools (e.g., kling_generate_video) by being a meta-reference.

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?

The description provides clear context ('Reference guide', 'helpful for understanding the full capabilities'), but does not explicitly state when not to use it or mention alternatives like kling_list_models. However, for a listing tool, this is adequate.

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

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

No annotations but description fully discloses behavior: it shows available models with capabilities and returns a table, with no side effects. It is transparent about being a read-only listing.

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?

Three succinct sentences that front-load the purpose, add usage context, and mention the return format. Every sentence is informative and no fluff.

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?

The tool has no parameters and an output schema, so the description adequately explains its purpose and usage. It is complete for a listing tool with no complexity.

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?

No parameters exist, so schema coverage is 100%. The description adds value by explaining the return table and use cases, which is not in the schema.

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 clearly states 'List all available Kling models for video generation', which is specific and distinguishes it from sibling tools that handle generation or task queries.

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?

Explicitly says 'Use this to understand which model to choose for your video', providing clear guidance on when to use the tool, though it does not mention when not to use it or alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the output is a video with synchronized lips/expressions/head movements and returns a Task ID, hinting at asynchronous operation. However, it does not detail the asynchronous workflow, potential failure modes, or any prerequisites beyond providing image and audio URLs.

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 concise and well-structured: a clear one-sentence summary, a 'Use this when' list with three bullet points, and a 'Returns' line. Every sentence adds value, and the information is front-loaded.

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?

Given the output schema exists and the input schema is fully documented, the description provides sufficient context for the tool's core function. It could be improved by explicitly stating the async task workflow (e.g., use kling_get_task to fetch results), but the 'Returns Task ID' line partially covers this.

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 description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema already provides, which is acceptable since the schema thoroughly documents all seven parameters.

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 clearly states the tool animates a portrait photo to match an audio track, generating a talking-head video. It uses specific verbs ('Animate', 'generates') and describes the resource (portrait photo + audio). This distinguishes it from generic video generation tools.

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?

The 'Use this when' section provides explicit use cases: creating talking-head videos, making a person speak, and quick avatar videos. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough for an agent to decide when to invoke this tool.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool creates an asynchronous task that should be polled with kling_get_task, but it omits other important behavioral details such as default async behavior, callback_url usage, permissions, or whether the operation is destructive.

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 two short sentences with no wasted words, and the purpose is front-loaded before the polling instruction. It is appropriately concise.

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?

Given the complex nested input schema, no annotations, and a sibling set with overlapping video-generation tools, the description is too sparse. It provides only a high-level purpose and a polling hint, leaving an agent without enough context to invoke the tool correctly.

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 description coverage is 0%, so the description must compensate, but it only names "avatar" and "speech_script" without mapping them to the nested content types. It does not explain the required contents array, settings, or other important schema fields.

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 gives a specific verb and resource: "Generate creator/product voiceover from an avatar and speech_script." This clearly identifies the output and core inputs. However, it does not explicitly distinguish the tool from siblings such as kling_goods_studio or other video-generation tools.

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?

The description says "Poll kling_get_task," which gives useful post-invocation guidance. However, it does not say when to choose this tool over alternatives like kling_goods_studio or kling_generate_turbo_video, nor does it provide any exclusions or prerequisites.

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