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

No annotations are supplied, so the description must disclose behavior. It reveals an extension returns a Task ID and extended video info, implying an asynchronous workflow, but does not state that results must be polled via get_task, whether the original video is modified, or any required permissions/billing. The continuation semantics are clear, but operational behavior is under-specified.

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?

Information is front-loaded with a one-sentence summary and scannable bullets. Minor redundancy between the first sentences ('Extend... additional content' vs 'continue... adding more motion and content') costs a point.

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 no annotations, the description covers the core use case and return value but omits the asynchronous task lifecycle (how to retrieve the result, whether to use callback_url) despite siblings like kling_get_task existing. Schema covers parameter semantics, so the remaining gap is moderate.

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?

Input schema descriptions cover 100% of parameters, including defaults and enum semantics for mode/model and the source of video_id. The prose description adds nothing beyond the schema—it restates the prompt guidance already in the schema—so baseline 3 is warranted.

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?

Clearly states the verb ('extend') and resource ('an existing video'), and explains the result is continued content after the original ends. This differentiates it from generation siblings like kling_generate_video and kling_generate_motion.

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 an explicit 'Use this when' bullet list with three concrete scenarios. Does not name alternatives or exclude cases, so it misses the when-not dimension, but the positive triggers are unambiguous.

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?

No annotations are provided, so the description carries the full burden. It discloses that the result includes a Task ID and generated video information with URLs and state, but omits important behavioral context such as asynchronous generation timing, callback behavior, and potential cost implications.

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-structured with front-loaded purpose, clear use-when bullets, an explicit sibling alternative, and a returns section. Minor redundancy and marketing language such as 'simplest way' and 'high-quality AI video' slightly reduce efficiency but do not obscure meaning.

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 12-parameter tool with a rich schema and output schema, the description adequately covers when to use the tool. However, it omits async/notification details and gives partially conflicting reference-image guidance, leaving moderate gaps for an agent making advanced invocation decisions.

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 and the description need not repeat parameter documentation. It adds little parameter-level meaning beyond the schema, and its 'no reference images' framing is somewhat misleading given the schema's image_list and video_list support.

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 AI video from a text prompt using Kling.' Explicitly differentiates from the sibling kling_generate_video_from_image, which prevents confusion between text-only and image-based generation.

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 clear use-when bullets and explicitly routes start/end-frame requests to kling_generate_video_from_image. However, the guidance 'You don't have reference images' is contradicted by the schema's image_list and video_list parameters, and no selection guidance is given for other siblings like kling_generate_motion or kling_extend_video.

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 behavioral disclosure burden. It reveals that Kling animates between the supplied frames, that start_image_url is required while end_image_url is optional, and that the call returns a Task ID plus video URLs and state. It does not explicitly mention asynchronous polling or rate limits, but the Task ID return makes the async nature reasonably inferable.

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-organized and front-loaded: the core capability appears in the first sentence, followed by compact use-case bullets and a terse return summary. There is slight redundancy between 'start and/or end frames' and 'first frame and/or last frame,' but the overall length is appropriate and every major section earns its place.

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 14 parameters, the description succeeds by giving the core generation concept, selection guidance, and a high-level return summary; the 100% schema coverage and output schema handle the remaining invocation details. It could be more complete by explicitly routing to alternatives like kling_generate_video when no reference image exists, but this is a minor gap rather than a blocking omission.

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 only marginal semantics beyond the schema by restating that start_image_url is required and end_image_url is optional. The schema itself already documents each parameter's purpose, including model restrictions and defaults, so the description does not need to compensate.

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 specific verb+resource: 'Generate AI video using reference images as start and/or end frames.' This clearly separates it from text-to-video and motion-only siblings by naming the distinguishing mechanic — first-frame and/or last-frame image control. The follow-up use-case bullets reinforce the tool's unique role as an image-driven video generator.

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 concrete trigger conditions: animating a specific image, creating a transition between two images, and needing precise visual control. It does not explicitly name alternatives or state when not to use this tool, but the given context is clear enough for an agent to select it appropriately.

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?

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.