Kling AI MCP Server by useapi.net (third-party)

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

The description adds real value beyond the annotations: cost (2.5 credits), the 3-20 s duration constraint, and the async job nature. Annotations already cover the write/open-world profile, and nothing here contradicts them. It stops short of stating auth requirements or what the resulting task returns.

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 tight, front-loaded sentences with no filler; purpose, cost, job nature, and endpoint in order. The trailing 'POST /videos/add-sound' is marginal but cheap and directional.

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 3-param mutation with no output schema, the description covers purpose, cost, constraints, async job behavior, and an analogous sibling for reference. An agent can invoke and follow up correctly; missing only explicit auth/prerequisite detail.

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 schema documents all three parameters, including the email account-selection logic and cropVideoOriginalSound. The description only adds the 3-20 s duration limit that constrains the video parameter, so 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 (generate sound effects and ambience) and resource (a video), plus a concrete constraint (3-20 s). This distinguishes it from generic video tools, though it does not explicitly differentiate from the closest sibling, kling_lipsync, which also adds audio to video.

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?

'A job, like kling_text_to_video' implies the async job pattern and gives the agent a mental model for follow-up via kling_get_task. However, there is no explicit when-to-use/when-not guidance versus siblings like kling_lipsync or kling_text_to_speech, so usage is only implied.

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?

Annotations already declare the safety profile (write, non-idempotent, open-world), and the description adds real behavioral context beyond them: video length tracks the speech, cost is 4 credits/second at std and 8 at pro, and the call produces an asynchronous job like kling_text_to_video.

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?

A single dense paragraph with no filler: purpose, input matrix, length/cost, and async nature all front-loaded. Every clause carries information an agent needs.

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, no-required, combinatorial tool with no output schema, it covers the input matrix, pricing, and job semantics well. It stops short of stating how to retrieve the resulting video (polling via a task tool), which the 'A job' phrasing only implies.

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 100% schema coverage the baseline is 3, but the description adds the crucial combinatorial logic across the 0-required-parameter set: avatarId vs imageUrl are alternatives, audioUrl vs text+speakerId are alternatives, and an avatar carries its own default voice. This clarifies valid input pairings the per-parameter schema text only states individually.

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 concrete verb+resource ('A talking-head video') and immediately enumerates the two avatar sources and two speech sources. It names kling_list_avatars as the source of avatarId and references kling_text_to_video, letting an agent separate this from sibling video 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?

Explains which input combinations apply (avatar or portrait; audio or text+speakerId) and that an avatar supplies its own voice. It routes to kling_list_avatars for avatarId, but never contrasts the tool with the closely-related kling_lipsync sibling, so guidance is clear context without explicit exclusions.

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?

Annotations declare a non-idempotent, non-destructive, open-world write. The description adds value beyond that: omitted fields are auto-suggested by Kling from the picture (server-side defaulting) and the operation is 'usually free' (cost behavior). It could still flag duplicate-creation risk from non-idempotency, but the added context is real.

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 sentences, front-loaded with the verb and resource, with no wasted clauses. The closing cost note and endpoint round out the definition compactly.

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 create tool with no output schema, the description covers purpose, dependencies, defaults, and cost. It stops short of saying what the call returns (e.g., the avatar identifier to reuse in kling_avatar_video), which is the one remaining 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 coverage is 100%, so the schema already documents all eight fields. The description adds little beyond grouping the 'name, prompt, voice' bundle and noting defaults; the ttsSpeaker cross-reference it mentions is already in the schema text.

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 states a specific verb and resource (save a personal avatar from a portrait) and ties it to the downstream consumer, kling_avatar_video. It also names the sibling used to obtain the voice id (kling_list_tts_voices), so an agent can distinguish it from kling_save_voice, kling_create_element, and other creators.

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 usage context: create an avatar here to feed kling_avatar_video, and pull the voice id from kling_list_tts_voices. There is no explicit when-not or preference-among-alternatives guidance, but the dependency routing is 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?

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.

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is known structurally. The description reinforces this with 'Cannot be undone' and exposes the underlying DELETE /avatars/{avatarId} endpoint, which is useful but largely restates what the annotations encode; it adds no auth or side-effect detail beyond that.

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 action and entity, then the irreversible warning, then the endpoint. No filler or redundancy.

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 single-parameter delete with no output schema and a full-coverage input schema, the description supplies everything an agent needs: the target entity, scope ('your personal'), the irreversible consequence, and the HTTP route. Nothing material is missing.

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% — avatarId's format ('digits') and the conditional email parameter are both documented in the schema. The description adds nothing param-specific, 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?

Specific verb+resource: 'Delete one of your personal avatars' names the exact entity and scopes it to the caller's own avatars, which separates it by resource from delete_element, delete_task, delete_voice and delete_uploads. It does not explicitly contrast itself with those siblings, but the resource noun makes disambiguation straightforward.

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 gives no when-to-use context, no prerequisites (e.g. that the avatar must exist or that it is the caller's own), and no alternatives such as list_avatars to find the id first. The only operational note is the irreversibility warning.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is baseline-covered; the description adds the crucial non-derivable fact that the deletion is irreversible ("Cannot be undone") and names the underlying endpoint. It stops short of saying what happens to videos/images that reference the element or what permissions are required.

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, front-loaded sentences with zero filler: effect, irreversibility warning, and endpoint. Nothing could be removed without losing 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?

For a destructive delete with no output schema, the definition covers what the agent needs: identity of the target, the irreversibility warning, and the account-scoping parameter documented in the schema. Residual gaps (referential side effects) are minor.

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 only two parameters, so the schema already documents both; the description adds the useful framing that elementId must refer to one of the caller's own elements (implying the account/email scoping). That is a small but real addition over the schema's bare "The element id (u_…)".

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 (Delete) and resource (one of your elements, ID prefix u_…), which cleanly separates it from the sibling deletes targeting avatars, voices, tasks, and uploads. An agent can pick it without opening any schema.

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 implied rather than stated: the description makes clear it applies to element IDs (u_…) and the agent must already have one. It names no alternatives (e.g., kling_delete_avatar or kling_delete_uploads) and gives no when-not conditions, so routing among the delete siblings 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description reinforces permanence ('Cannot be undone') and clarifies that all works of the task are removed, but adds little genuinely new behavioral context such as permission requirements or error behavior for unfinished tasks.

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, front-loaded sentences: destructive scope first, irreversibility second, endpoint last. No filler, though the literal endpoint notation is marginally redundant for an agent invoking a tool rather than the REST API.

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 destructive two-parameter tool with full annotation coverage and no output schema, the description covers what is deleted and that it is irreversible, which is what the agent needs. Minor gaps remain around behavior when the task is unfinished or unauthorized, but these are secondary to annotations.

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% for both parameters, so the schema already explains task_id and the email fallback rule. The description only mirrors task_id in the endpoint path and adds nothing about the optional email parameter, making the baseline 3 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?

Names a precise verb and resource: permanently deletes every result/work of a task, with the endpoint DELETE /tasks/{task_id} confirming scope. The resource noun ('task's results') implicitly separates it from the other delete siblings (avatars, elements, uploads, voices), but no sibling is named 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 phrase 'of a finished task' implies the precondition that the task must be complete, which is useful usage guidance, but there is no explicit when-to-use, when-not-to-use, or comparison to alternatives. Usage is left mostly 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description still contributes real context by stating 'Cannot be undone' and, more importantly, delimiting what is destroyed ('Generated results are not affected'), which the annotations do not convey.

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?

Extremely tight: the action, id source, irreversibility, and scope of effect are each one clause, front-loaded with the verb. Nothing is wasted, and even the endpoint notation is compact.

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 destructive bulk-delete with no output schema, the description covers invocation source, count limit, and irreversibility adequately. The only minor gap is the multi-account email condition, which the schema already documents.

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 'ids' (1-10 digits) and 'email' are already documented in the schema. The description adds provenance of the ids but no syntax or format detail beyond the schema, 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 and resource ('Delete ... uploaded files') with the scope of deletion and the operation's non-effect on generated results. This cleanly separates it from sibling deletes like kling_delete_element, kling_delete_avatar, and kling_delete_task, which target different resources.

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?

Tells the agent where ids come from ('from kling_list_uploads') and clarifies that generated results are unaffected, which scopes the operation sensibly. It stops short of explicitly contrasting with the other delete_* siblings for ambiguous cases.

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?

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is largely covered. The description adds the critical operational fact 'Cannot be undone', which is genuinely useful irreversibility context beyond the annotation flags.

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 sentences plus an endpoint reference, with the action front-loaded and zero filler. Every clause (id source, irreversibility, route) carries information an agent needs.

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 simple single-resource delete with full schema coverage and annotations covering the safety profile, nothing further is needed; no output schema is required and return values are irrelevant. The definition is complete as written.

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 both parameters are documented (email conditional, voiceId as digits) and the baseline would be 3. The description adds provenance for voiceId (obtained from kling_list_voices or kling_save_voice), which is meaning the schema does not supply.

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 ('Delete ... Kling 4.0 voices by id') and scopes it to the user's saved voices, which cleanly separates it from the many sibling delete tools (kling_delete_avatar, kling_delete_element, kling_delete_task). It even names the endpoint, leaving no ambiguity about what is being removed.

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 tells the agent where the required id comes from (kling_list_voices or kling_save_voice) and warns the action is irreversible, which is the key precondition for calling it. It does not, however, state any when-not-to-use condition or contrast with the other delete siblings.

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?

Annotations declare the write/open-world profile, and the description adds genuinely new behavioral context: approximate credit cost (std ~20, pro ~35) and the fact that this returns an asynchronous job 'like kling_text_to_video', implying polling via kling_get_task. It does not state job duration or failure behavior, so it stops short of 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?

Three terse fragments that front-load the core action, then the prerequisite tool, then cost and async semantics. No filler and nothing buried.

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 async job tool with a fully documented schema and no output schema, the description covers the essential unknowns: which tool supplies effect names, what it costs, and that it returns a job. The missing piece is the relationship to kling_image_to_video and how results are retrieved.

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 adds decision-relevant meaning for the mode parameter by pricing std versus pro, which helps the agent choose among the enum values. It does not explain the 4k tier or the prompt limiting conditions.

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 ('Turn an image into a video with one of Kling's effects') and points at the endpoint. However, it never distinguishes itself from the closest sibling, kling_image_to_video, which also turns an image into video, so an agent must infer which path to take.

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 the credit cost for std/pro and directs the agent to kling_list_effects for valid effect names, which is a real usage requirement. But it offers no when-to-use guidance relative to kling_image_to_video or when-not conditions, leaving the main selection decision implicit.

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?

Annotations declare a non-read-only, non-idempotent, open-world write, and the description meaningfully extends this: it is an async job ('A job, like kling_text_to_video'), it costs ~20 credits per 5s, defaults to kling-v1-6 with sound on for v3-0, and it hits POST /videos/image2video-elements. That is substantive operational context beyond the annotations, though polling/return handling is only implied.

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?

Four dense sentences with no filler, and the primary action is front-loaded before model constraints and cost. It is information-packed but every clause (model limits, cost, job semantics, endpoint) 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 15-parameter, two-model, no-output-schema tool, the description covers the model matrix, defaults, cost, and async job nature. The main residual gap is that result retrieval (task polling via kling_get_task) is only hinted at by 'A job, like kling_text_to_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 the parameter bar is baseline 3, but the description adds cross-parameter constraints the schema does not: elements require kling-v3-0, element count is capped at 3 inputs total, and negative_prompt/aspect_ratio variants are tied to model choice. Some duration/model text duplicates the schema verbatim, keeping it short of a 5.

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: generating a video by combining images (image_0..3) with elements (element_1..3). The 'elements' mechanism distinguishes it from kling_image_to_video and kling_text_to_video, though those siblings are not named for direct routing. Purpose is clear but sibling differentiation is implied rather than explicit.

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?

Explains model-specific constraints (kling-v3-0 supports elements and 3-15s; kling-v1-6 is images-only, 5/10s) and cost, which implies when each model is appropriate. However, it never says when to pick this tool over kling_image_to_video, kling_omni_video, or kling_kolors_elements_image. Usage is inferable but not stated.

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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely new context: this is an async job rather than an inline result, and it costs 1 credit at 2k or 2 credits at 4k. It stops short of describing polling or completion behavior.

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 tight sentences, front-loaded with the capability and cost. 'POST /images/enhance' is developer-facing trivia that adds little for an agent, but it costs almost nothing.

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?

With no output schema, the description should carry more of the return contract. Saying it is 'a job, like kling_omni_image' hints at async task semantics, but it never says a task_id is produced or that kling_get_task should be used to fetch the result.

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; the description's notation of the credit cost per resolution adds a little meaning to the enum, but the email parameter (the non-obvious one, with account-selection semantics) is not addressed at all.

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: 'Improve and restore the detail of any image by URL' with explicit resolution targets. It does not, however, differentiate itself from the sibling kling_upscale_image, which is a near-neighbor an agent could easily confuse it with.

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?

Implied usage is clear (enhance an image given a public URL), and it gives cost and default-resolution guidance, but there is no explicit when-to-use vs kling_upscale_image or kling_kolors_image, and no statement of prerequisites for why the URL must be fetchable beyond the schema text.

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?

Annotations only declare the generic write/async profile, but the description adds highly specific behavior: model-version support limits, the exact error code on refusal, an approximate cost (~20 credits), the extension length, and the same-account requirement. It also frames the result as an async job, which is exactly the operational context an agent needs and cannot get from the 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?

Extremely dense and front-loaded: capability, version limits, cost, job model, and endpoint each get one clause with zero filler. The most decision-relevant facts (what it does, what it rejects) come first.

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 async generation job with no output schema, the description covers cost, eligibility, failure mode, account scoping, and the returned-job nature, referencing kling_text_to_video as the behavioral template. An agent has everything needed to decide whether to call it and what to expect.

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 schema already documents all six parameters. The description only reinforces the same-account constraint for 'email' and the duration semantics, adding little beyond the structured fields. 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 (continue/extend) and resource (a finished Kling video task) with the exact scope (~5 s continuation). It names the sibling kling_text_to_video as a structural analog and the endpoint, letting an agent place it precisely among the many kling_* 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?

Gives clear preconditions: must be a finished task, same account, and only kling-v1-6 videos qualify. It also names the failure case (kling-v2-6 refused with TASK.InvalidTaskType), which effectively tells the agent when not to use it. It stops short of an explicit 'use X instead for newer models' routing statement.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes further by disclosing what the call returns - live credit balance split into plan and top-up credits with expiry dates - which is genuinely useful since no output schema exists.

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 dense sentences with zero waste. The most important element (what account data comes back) is front-loaded, with the endpoint path trailing as a compact reference.

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 single-read tool with annotations covering the safety profile and a description covering the return shape, this is nearly complete. Minor gap: no mention of behavior when the email is unknown (e.g., not-found error), which matters for an idempotent single-record fetch.

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?

Only one parameter, and schema description coverage is 100% ('The account email.'). The description restates the endpoint path parameter but adds no format, validation, or lookup semantics beyond what the schema already provides, 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 ('Get'/'account') and adds scope detail: it returns ONE account's live credit balance with plan/top-up breakdown and expiry dates. The singular 'One account' implicitly distinguishes it from the sibling kling_list_accounts, though it never names that sibling 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?

Usage is only implied: the required email param and 'One account' framing signal single-account lookup. There is no explicit when-to-use guidance and no named alternative (kling_list_accounts) to route the agent between the two account tools.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely non-derivable facts: the paid-plan entitlement gate, the immediate availability of the link, and the default-fileType rule ('the first the work has'). Permission and rate-limit behavior remain unstated.

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?

Effectively one dense sentence that front-loads the value proposition (watermark-free link) before the format and readiness details. The parenthetical plan requirement and trailing route add density but no wasted sentences.

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?

There is no output schema, and the description compensates by characterising the return value as a direct link a nd by stating formats and immediate readiness. The one gap is the email parameter's multi-account condition, which is left entirely to 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 schema already documents workId, email, and the fileType enum with its default. The description restates the format-to-media mapping but adds no syntax, validation, or defaulting detail beyond the schema, 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?

The description states precisely what is returned: a direct link to a result without the Kling watermark, keyed by workId, in a specific media format, with the HTTP endpoint (GET /assets/download) named. It is a noun phrase rather than an explicit verb+resource, but an agent can immediately tell this apart from kling_list_works or kling_get_task, which are cited only as sources of the workId rather than alternatives.

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 preconditions: the workId comes from kling_get_task or kling_list_works, and watermark-free links require paid Kling plans. It also states the resource is 'Ready at once', implying no polling loop is needed. It stops short of explicitly saying when not to use it (e.g. free-plan users needing a watermarked download).

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuinely new behavioral content by disclosing the returned fields (cover and extra view images, video, tags, voice), which matters because no output schema exists.

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 with the return payload front-loaded, which is the most decision-relevant information. The trailing endpoint string is mildly redundant given the name and schema but costs almost nothing.

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 simple read-only getter with full schema coverage and no output schema, the description covers the essentials by describing the returned payload. It omits error/not-found behavior and account-scoping behavior, but nothing critical to invoking it is missing.

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%: elementId format (u_… / o_…) and the conditional email requirement are fully documented in the schema. The description adds no additional parameter semantics, 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 (retrieve a single element by id) and enumerates what the payload contains: cover/extra images, video, tags, voice. The word 'One' cleanly distinguishes it from kling_list_elements, though no sibling is named 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?

There is no when-to-use or when-not-to-use guidance. The endpoint string 'GET /elements/{elementId}' implies retrieval for a known id, but it never says to prefer kling_list_elements when the id is unknown or to use kling_list_element_tags/voices for narrower reads.

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?

Annotations already declare readOnly/idempotent/non-destructive, so those add nothing. The description earns credit by disclosing the blocking behavior of wait (~50 s) and the shape of the result payload, which annotations cannot express. No auth or rate-limit context, but the wait semantics are the key behavioral trait here.

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 resource, then the return payload, then the wait modifier and endpoint. The parenthetical field list is somewhat dense but each item is informative. No filler sentences.

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?

With no output schema, the description steps in to describe the result object (video/image with url, cover, size, length, workId) and notes how to view the cover. Combined with the wait semantics, an agent has enough to call and interpret the result, though account-scoping via email is left to 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 coverage is 100%, so the schema already documents all three parameters including wait and email. The description's 'wait: true waits up to ~50 s' largely restates the schema's own description, adding no new syntax or constraints. Baseline 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?

Names the specific resource (a Kling task) and enumerates what is returned: status, ETA, and results with url/cover/size/length/workId. The verb 'get' is implied by the title and the GET endpoint note. It's clearly distinct from kling_list_tasks or kling_delete_task, though it never names those siblings.

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 implied: retrieve a task by id, optionally waiting for completion. The 'wait: true waits up to ~50 s' note gives real operational context for polling. However, there is no explicit 'use this instead of kling_list_running when...' routing or when-not guidance.

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?

Annotations only declare that this is a non-idempotent open-world write; the description adds substantial context beyond that: it consumes Kling credits with a concrete price table, it returns a job rather than a finished video, it is model-gated in many interacting ways, and audio is forced on for some models. This is exactly the behavioral detail an agent needs before spending credits.

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?

Every clause carries real information, so nothing is padding, but the whole definition is a single dense run-on paragraph where model specs, costs, and cross-parameter constraints are interleaved. It would be far more usable broken into 'what it does / per-model rules / cost' segments; as written an agent must parse the whole block to extract one constraint.

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 35-parameter, zero-required-field generation tool with no output schema, the description covers the decisions that actually matter: which model supports which features, what the aspect ratio derives from, what audio costs, and that the call produces a job. Return values need no explanation since the job pattern is named and polling is a separate sibling 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 already 100%, so the baseline is 3; the description still adds cross-parameter rules the schema does not state, notably that keyframes must be in all ≤ duration + 1 and at most 10, that image_tail forces mode pro on older models, and that keyframes/elements are mutually model-exclusive. It largely repeats the per-model gating that individual property descriptions already carry, which keeps it from a 5.

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 ('Animate a start image ... optionally to an end image') and names the endpoint POST /videos/image2video-frames. It explicitly ties itself to the sibling family ('A job, like kling_text_to_video'), so an agent can distinguish this image-driven path from the text-driven and element-driven siblings.

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 per-model breakdown gives concrete selection criteria (duration ranges, std/pro/4k availability, audio defaults, credit cost per second) that tell an agent which model to pick and when a feature is unavailable (flash: start image only, no custom shots). It stops short of an explicit 'use this tool instead of kling_elements_video / kling_text_to_video when…' routing statement, so the alternative-selection guidance is implied rather than stated.

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?

Annotations already declare the write/openWorld/non-idempotent profile, and the description adds genuinely new operational context: cost (~1 credit per image), asynchronous job semantics, and the HTTP endpoint. It still doesn't say how the job's result is retrieved (e.g., via kling_get_task), which is the one behavioral gap.

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?

A single dense sentence plus two short fragments: the composition model comes first, then cost and job semantics. No filler and nothing important buried.

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 async generation tool with no output schema, it covers inputs, cost, and job nature adequately. It stops short of naming the polling/retrieval path for the resulting task, which is the main thing an agent still has to infer from sibling tools.

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 adds real meaning beyond the schema: the effective minimum of two images (the schema lists required=[], so nothing enforces it) and the mapping of subjectImage1..4 to 'subjects' versus the optional scene/style roles in the composition.

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: multi-image composition combining up to 4 subjects with optional scene and style images, guided by a prompt. The Kolors 2.1 / 'elements' framing and the 'up to 4 subjects' scope separate it from the single-image kling_kolors_image, though it never names that sibling explicitly to make the boundary airtight.

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 one hard usage rule ('give at least two images') and notes the job pattern via 'like kling_omni_image', which is a useful pointer. However it never states when to prefer this over kling_kolors_image or kling_omni_image, so the selection decision is left implied rather than stated.

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?

Annotations declare the write/open-world profile, and the description adds genuinely new context beyond them: the cost model ("1 credit per image"), the result shape ("Finished images come back as images you can see"), and the underlying endpoint. It does not clarify whether the call blocks or returns a task_id to poll with kling_get_task, which is the main remaining behavioral gap.

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 core purpose is front-loaded, but the body is a dense run-on of parentheticals that mixes version notes, credit cost, and an endpoint path. "POST /images/kolors" is internal plumbing that adds little for an agent and could be dropped to tighten it.

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 21-parameter generation tool with no output schema, the description covers the essentials an agent needs: cost, output form, version selection, reference-image limits, and conditional requirements. Remaining detail (per-parameter ranges, enums) is fully carried by the schema at 100% coverage.

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 already 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema states only in scattered per-field text: that aspect "auto" requires a reference on kling-v3-0, that reference modes require imageReference, and that imageCount defaults differ by version. That version-conditional coupling is real added meaning 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?

States a specific verb+resource ("Kolors images from a prompt") and enumerates the two operating modes (kling-v3-0 with up to 10 reference images vs. older versions with reference subject/face/restyle). An agent can tell this is the prompt-to-image generation tool, though it never explicitly distinguishes itself from the similarly named kling_kolors_elements_image sibling.

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 useful intra-tool routing (default kling-v3-0 with reference images; older versions when you want subject/face/restyle), which implies when each mode applies. However it offers no guidance on when to pick this tool over the many sibling image tools (kling_omni_image, kling_enhance_image, kling_kolors_elements_image), so alternative selection 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?

Annotations already declare the operation is non-read-only, non-idempotent and open-world, so the safety profile is covered. The description adds genuinely useful behavior: it is an asynchronous job (mirroring kling_text_to_video), costs ~5 credits per 5 s, and requires a frontal face within 60 s. It does not say how results are retrieved, which holds it back from 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?

Three tight sentences with zero filler; the core action, the hard input constraints, cost, async semantics and endpoint are all front-loaded and each 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 an async, no-output-schema job tool, the description covers action, constraints, cost and job semantics, which is enough to invoke it correctly. The only gap is that it implies result polling via kling_get_task without saying so explicitly.

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 video/audio/email are already fully documented in the schema (including the kling_upload_asset recommendation and multi-account guidance). The description only adds the 60 s / frontal constraint on the video input, so baseline 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?

States a specific action and resource: make the face in a video speak an audio track. It also pins the input scope (up to 60 s, frontal), which differentiates it from kling_add_sound and kling_avatar_video without opening their schemas.

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 60 s / frontal constraint implicitly tells the agent when this tool is applicable, and 'A job, like kling_text_to_video' signals the async submission pattern. However, it never names an alternative (add_sound, avatar_video) or states when not to use it, so routing 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?

The annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description usefully discloses the returned fields (maxJobs, sign-in mode, session expiry, error), but adds nothing about auth requirements, pagination or ordering beyond that.

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?

One compact sentence with the enumeration scope front-loaded and the returned fields listed in-place. The trailing 'GET /accounts' is minor but harmless; no filler sentences.

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 parameterless list tool whose annotations cover the safety profile and with no output schema, disclosing the fields stored is close to sufficient. A note on list size or ordering would close the remaining 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly omits parameter discussion rather than padding.

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 ('List') and resource ('Kling accounts') scoped to 'this useapi.net API token', which clearly separates it from the singular sibling kling_get_account. It stops short of explicitly naming that alternative, so it is clear but not maximally differentiating.

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?

Implied usage as the enumeration counterpart to kling_get_account is discernible, but the description never states when to prefer this listing over the single-account call or any other sibling. No explicit when/when-not guidance is given.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real value by enumerating the returned fields (id, name, picture, voice settings) and the default behavior of the type parameter, which matters since there is no output schema. It omits pagination/rate-limit behavior, but the disclosure is solid for a read 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?

A single compact sentence fragment front-loads the resource, the two variants, and the downstream tool, with zero filler. It is slightly telegraphic ('GET /avatars' adds little), but nothing 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 two-parameter, read-only listing tool with no output schema, the description covers the resource, variants, downstream use, and returned fields. Only minor operational details are absent, which is acceptable given the simplicity.

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 both parameters are already documented in the schema, including the enum values and the email requirement note. The description only restates 'personal, default' without adding syntax or format detail, so 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?

The description names the specific resource (avatars) and distinguishes the two flavors it returns: the user's own personal avatars versus Kling's templates. Naming kling_avatar_video as the consumer also disambiguates it from the many other list_* siblings (voices, elements, works).

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 implies usage by tying the result to kling_avatar_video, so an agent can infer this is the lookup step before avatar video generation, and it notes personal is the default. It gives no explicit when-not guidance or mention of alternatives like kling_create_avatar or kling_delete_avatar.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is context-adding. The description adds one genuinely useful behavioral fact — retired effects still appear in the list and are refused at submit at no cost — but omits ordering, pagination, or why some entries lack modes beyond a guess ('likely').

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 dense sentences plus the raw endpoint; the scope statement leads and the retired-effect caveat follows. Some phrasing is clipped to the point of ambiguity ('takes a prompt', 'the modes each allows'), which costs a little clarity but not much length.

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?

With no output schema, the description correctly carries the return-value burden by listing the fields an agent will receive and flagging the retired-effect edge case. It does not describe the response envelope or whether results are paginated, which is the main remaining incompleteness for a paginated-looking list endpoint.

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% for the single email parameter, so the schema fully documents it and the description adds nothing about it. Baseline 3 applies when the schema does the heavy lifting, which is the case here.

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 names a specific resource (Kling's video effects) and explicitly ties it to the consumer tool kling_effect_video, so an agent can place it in the workflow without opening a schema. It also enumerates the meaningful fields returned (name, caption, modes, hot, prompt support). The only gap is that no verb is stated in the description itself — 'list' comes from the name/title pair, not the prose.

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?

By naming kling_effect_video as the consumer, it implicitly tells the agent to call this first to discover valid effect names and modes. It also supplies practical guidance for interpreting results ('no modes listed is likely retired'). It stops short of an explicit when-not-to-use condition, but no sibling competes for this role.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds genuinely useful behavior the annotations don't: the id prefix convention (u_ = yours, o_ = official), the fact that a quota consumption figure is returned, and that cover/tags accompany each element. It stops short of describing pagination behavior or total counts.

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?

A single dense, front-loaded sentence that packs the tool's identity, output fields, and quota note without filler. The nested parentheticals and id examples make it slightly run-on, but nothing is redundant and nothing could be cut without losing 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?

With no output schema, the description carries the burden of describing the return payload - and it does, listing id, name, type, cover, tags and quota usage. That covers most of what a 7-param list tool with optional filters needs, though pagination semantics and whether official and own elements can be mixed in one call remain unaddressed.

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 one of the 7 parameters is already documented in the schema, establishing a baseline of 3. The description only lightly echoes the 'official' flag and tag source, adding no syntax or format detail beyond what the schema already states.

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 ('List elements' / GET /elements) and enumerates what an element is: reusable characters, props and scenes. It distinguishes itself from siblings kling_get_element (single fetch), kling_list_element_tags, and kling_create_element by naming the consuming tools and showing the element id/type/cover shape.

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 implied (browse your or official elements) and the tag parameter routes the agent to kling_list_element_tags first, which is a helpful dependency hint. But there is no explicit when-to-use guidance versus kling_get_element or kling_list_element_voices, and no statement of when to prefer official=true over your own elements.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the underlying endpoint (GET /elements/tags) and the return shape (id and key), which is mild added value, but it says nothing about auth beyond what the schema notes or about response ordering/volume.

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?

A single compact sentence with the resource and its filter values front-loaded and the consuming tools and endpoint at the end. Nothing extraneous, though the telegraphic fragment style borders on under-specification.

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 no-required-param read endpoint with full annotation coverage and full schema descriptions, the description supplies the return fields and the endpoint, which is enough for an agent to call it correctly. It does not need to explain return values further given the low 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?

Schema coverage is 100% and the sole 'email' parameter is fully documented in the schema, so schema carries the load. The description adds no parameter meaning beyond that; per the rubric this is the baseline 3.

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 fragment 'The tags an element can have' plus the enumeration (character, animal, prop, costume, scene, effect, others) makes the resource concrete, and the trailing reference to kling_create_element / kling_list_elements ties it to its consumers. It relies on the name/title to supply the 'list' verb and is written telegraphically, but an agent can tell it apart from siblings like kling_get_element.

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?

Saying the tags are 'for kling_create_element and kling_list_elements' implies the call is used to discover valid tag values before those operations, which is useful implied context. There is no explicit when-to-use/when-not framing or stated alternative, so guidance is only implied.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the return shape (id and name), which is useful, but says nothing about auth behavior or pagination beyond what the schema's email field carries.

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?

Tight and front-loaded: purpose first, then disambiguation, then return fields, then the endpoint. No filler, though the trailing 'GET /elements/voices' is marginally redundant with the tool name.

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 read-only list tool whose annotations carry the safety profile, an agent has everything it needs: what it lists, what it returns, and how it differs from the other voice lists. No output schema exists, and the description already names the returned fields.

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?

Only one optional parameter (email) with 100% schema description coverage, so the schema fully documents it. The description adds no parameter-level meaning, making the baseline 3 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?

Specific verb (list) plus resource (element voices) and even the returned fields (id and name). It explicitly distinguishes itself from the two nearest siblings, kling_list_voices and kling_list_tts_voices, and ties the list to kling_create_element voice.

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 names the alternatives it is NOT (kling_list_voices for Kling 4.0, kling_list_tts_voices) and pins its use case to character elements via kling_create_element, giving clear selection context. It stops short of an explicit 'use this when / don't use this when' rule, so it isn't a full 5.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real value by disclosing the content of each returned item and the intended use of the url, which is essential given there is no output schema. It does not mention pagination or auth, so not 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?

A single dense sentence with the purpose front-loaded, followed by the alternative and return-shape detail plus the endpoint. Nothing is wasted, though the parenthetical packing makes it slightly harder to scan than ideal.

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?

With no output schema, the description usefully compensates by describing the returned fields (url, cover, length). Auth context (email) lives in the schema. For a simple list tool this is nearly complete, missing only pagination/volume expectations.

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 both parameters (mine, email) are already documented in the schema and the baseline is 3. The description reinforces the meaning of mine:true but adds no syntax or format detail beyond what the schema provides.

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 (list) and resource (Kling's ready-made motion videos), and ties it to the consumer tool kling_motion_control, so the agent can distinguish it from the many other kling_list_* siblings. The description also clarifies what each returned item is (a motion video with a url, cover, and length).

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 names the related tool (kling_motion_control) and explains the returned url is meant to be passed as motionUrl, which implies when to reach for this tool. It also flags the mine:true variant for the user's own motions. It stops short of explicitly stating 'call this before kling_motion_control' or any exclusions.

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?

Annotations already declare read-only, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds real context beyond that: the 60-minute tracking ceiling, that results include the owning account, and that free job slots per account are returned, plus the underlying endpoint.

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?

A single front-loaded sentence carries the scope, contents and constraint, followed by the endpoint reference. No padding, though the raw 'GET /scheduler/available' is marginally useful to an agent and could be considered overhead.

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?

With no output schema, the description usefully enumerates what comes back (running tasks, their account, free job slots) and the tracking window. A note on response volume or ordering would make it fully self-sufficient, but nothing essential is missing for a zero-arg read 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless schema is 4. No misleading hints about hidden filters are given.

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?

Specific verb (list) and resource (running jobs) with precise scoping: only tasks started by this API token, only still-running ones, and only within a 60-minute tracking window. That scope cleanly separates it from the general kling_list_tasks sibling without needing to name it.

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 implied by the scope — an agent can infer this is for polling in-flight jobs rather than all tasks — but there is no explicit when-to-use guidance, no statement of when to prefer kling_list_tasks instead, and no mention of rate/polling expectations.

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?

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the safety profile is handled. The description adds real behavioral context beyond that: ordering (newest first), status coverage, inclusion of tasks created on kling.ai, and that results are returned inline. Auth nuance is left to the schema.

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 tight sentences with the core scope front-loaded and pagination second; the trailing 'GET /tasks' endpoint note is terse. No filler sentences.

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?

With no output schema, the description should carry return-shape information; 'with their results' is thin but adequate given the enumerations. For a read-only list tool with full annotation coverage and fully documented params, only the result structure is left somewhat vague.

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 adds semantics the schema lacks: createdBefore is the pagination cursor set to the last task's createTime. That turns an opaque timestamp filter into an actionable cursor pattern, which is above-baseline value.

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 ('An account's recent Kling tasks, newest first') and enumerates the statuses covered (running, failed, finished), which implicitly contrasts with kling_list_running. It never names a sibling explicitly, so an agent must infer the split from kling_list_running and kling_get_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?

Offers concrete operational guidance for pagination ('Page with createdBefore = the last task's createTime'), which is genuinely useful. It does not, however, say when to choose this over kling_list_running or kling_get_task, leaving 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds what a read actually returns (speakerId, name, a sample, supported emotions) and the backing endpoint, which is meaningful value beyond the 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?

A single dense sentence front-loads the resource and follows with the consumers and returned fields. Nothing is wasted, though the stacked parentheticals and trailing endpoint make it slightly run-on rather than crisply structured.

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?

With no output schema, the description compensates by enumerating the returned fields (speakerId, name, sample, emotions) and linking the voices to their consuming tools, which is what an agent needs to call and use this correctly. Missing only explicit guidance on account scoping for the email parameter.

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 single email parameter is fully documented in the schema and the description need not repeat it. The description adds nothing about the parameter, 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 (Kling's text-to-speech voices) and immediately distinguishes it from the generic kling_list_voices sibling by naming the exact consumer tools (kling_text_to_speech, kling_avatar_video, kling_create_avatar). An agent can tell what it returns (speakerId, name, sample, supported emotions) without opening the schema.

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?

By naming the three tools that consume these voices it implies the when-to-use condition (call before invoking TTS/avatar tools), giving clear context. It stops short of explicitly routing away from the similar kling_list_voices / kling_list_element_voices siblings, so no exclusions are stated.

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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the returned field set, newest-first default ordering, and the pagination termination rule (stop on a short page), though it says nothing about auth or rate limits.

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 compact sentences with the resource, returned fields, pagination rule, and endpoint all front-loaded; no filler or repetition of the title.

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?

With no output schema, the description usefully enumerates the returned fields and explains how to page, and the six optional filters are fully specified by the schema. Only the multi-account/email authorization nuance and filter combinations go unaddressed.

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 (sort, email, pageNum, fileName, pageSize, contentType) is already documented in the schema. The description only adds 'newest first' for sort and the short-page pagination rule, which is baseline-level value on top of a complete 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?

States a specific verb and resource (list files uploaded to a Kling account) plus ordering and the fields returned (id, name, type, url). It references the related kling_upload_asset tool, which clarifies provenance, but it does not explicitly contrast itself with other list-style siblings.

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 usage context is implied by 'the files you uploaded' and the pagination hint ('Page until a short page comes back'), but there is no explicit when-to-use/when-not statement and no named alternative for cases such as filtering or retrieving a single asset.

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?

Annotations already cover read-only, idempotent, open-world and non-destructive behavior, so the bar is lower; the description still adds ordering semantics (saved voices first, then official), the returned fields, and the underlying endpoint. It omits pagination or result-size limits, but a simple list endpoint likely has none.

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?

One dense sentence that front-loads the resource and scope, then the result composition, then the endpoint. Nothing is redundant and no clause 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?

With no output schema, the description compensates by enumerating return fields (id, name, sample) and ordering. It is essentially complete for a zero-required-param read, with only minor gaps like result size or failure modes when the account is ambiguous.

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% and the single email parameter is fully documented in the schema as required when the token spans several Kling accounts. The description only echoes this with "on one account," adding no syntax or format detail beyond the schema, so 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 resource (the voice list for kling_omni_video v4) and the exact contents returned (id, name, sample) plus ordering. It distinguishes itself by scoping to omni-video v4 voices, though it does not name the near-identical siblings kling_list_tts_voices or kling_list_element_voices.

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 voices for kling_omni_video v4" gives clear context for when to call it — to obtain voice_1..3 ids for omni video. There are no explicit exclusions, so an agent must infer that TTS or element voices live in the other list tools.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description goes further by disclosing default ordering (newest first), pagination behavior via pageNum, the returned field set (url, cover, size, workId) and the underlying endpoint GET /assets. No rate limits or auth caveats are given, but this is solid added context.

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 scope and content types, then the sibling disambiguation, then the endpoint. Efficient with no filler, though the single dense clause listing return fields compresses several facts into one sentence.

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?

With no output schema, the description is the only source for return values, and it names the key fields plus ordering and paging. It omits total counts/cursor semantics, but for a five-parameter read-only list tool this covers what an agent needs to call it 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 100% with enums documented for sort and contentType, so the baseline is 3. The description only echoes the default sort and pageNum paging without adding format or constraint detail the schema lacks.

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 (list) and resource (an account's finished results: videos, images, audio) with scope ('finished results only') and names the sibling it is not (kling_list_tasks). An agent can distinguish it from kling_list_tasks, kling_list_running and kling_list_uploads without opening any schema.

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?

Points to the alternative for the complementary case ('kling_list_tasks also shows running and failed tasks'), which effectively routes the agent to the right tool for running/failed work. It does not state prerequisites such as when the email parameter becomes mandatory, so it falls short of fully explicit when/when-not guidance.

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 annotations covering safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), the description still adds real behavioral context: it is an asynchronous job, output duration equals the motion video length, and it carries per-second credit pricing (9 credits/s std, 35 per 5s for kling-v2-6). Cost and job semantics are not in the structured fields, so this is meaningful added value.

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?

Dense and front-loaded: purpose first, then input provenance, then cost, then job nature and endpoint. Every sentence carries information. Slightly cryptic parentheticals keep it from a perfect score, 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 9-parameter, no-output-schema tool, the description supplies the missing return shape (a job/task, like kling_text_to_video), duration behavior, and cost. Combined with full schema coverage, an agent has enough to call it correctly; only the explicit sibling differentiation is absent.

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, but the description adds semantics the schema lacks: the 3-30s bound and provenance for motionUrl, and the model_name credit differential. These go beyond the enum/type documentation, lifting it above baseline.

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: 'make the person in imageUrl perform the movement of motionUrl'. The core operation is unambiguous and the 3-30s constraint is given. It does not, however, distinguish itself from the closest siblings (kling_image_to_video, kling_avatar_video, kling_lipsync), so an agent must infer the difference from the inputs.

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 tells the agent where motionUrl comes from (kling_upload_asset or kling_list_motions) and that the result is an async job 'like kling_text_to_video', which is useful prerequisite/routing context. But there is no explicit when-to-use-this-vs-alternatives guidance and no exclusions, so usage is implied rather than stated.

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?

Annotations declare non-readonly, open-world, non-idempotent, non-destructive. The description goes further than annotations by disclosing cost (1 credit per 1k image, 2 at 2k, 4 at 4k, multiplied by imageCount), latency (usually under a minute), and the returned artifact form. It omits any auth or async/polling detail, but the added cost/latency context is genuinely valuable.

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 and compact, packing version, cost, latency, and output format into a few dense sentences with no filler. Slightly telegraphic, but nearly every clause carries a distinct fact.

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 28-parameter mutation tool with no output schema, the description covers the essentials: reference conventions, version tradeoffs, resolution/cost, latency, and result form. It does not explain the account/email selection rules (left to the schema) or any async task handling, so it is strong but not fully complete.

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 adds information the schema lacks: the prompt referencing syntax (@image_1 / @element_1) and version-specific defaults (v3 default with aspect auto vs o1 with 16:9). That is real added meaning beyond the field-level docs.

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 (generates images from a prompt) plus its distinguishing mechanism (up to 10 image/element references) and the endpoint. It differentiates itself from enhance/upscale siblings by the reference-driven generation. It does not, however, contrast against the closest siblings like kling_kolors_image or kling_kolors_elements_image, so it stops short of a 5.

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 implies when the tool applies (prompt-driven generation with up to 10 references) and explains the @image_1 / @element_1 naming convention, but gives no explicit 'use this instead of X' routing or when-not-to-use guidance relative to the many sibling image tools.

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?

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.

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond them by disclosing cost ('Free') and describing the return payload (crops with positions), which is behavioral context the annotations do not carry.

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?

A single compact sentence front-loads the action, then folds in the return shape, the use case, the cost and the endpoint with no filler. Every clause 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?

With no output schema, the description usefully compensates by stating what comes back (crops and positions), and it names the endpoint and cost. It does not cover failure modes (e.g. no face detected, fetch failure), which for a two-parameter read tool is a minor remaining 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 100%: the schema already documents that imageReference is a public https URL best sourced from kling_upload_asset and that email is needed for multi-account tokens. 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 and resource ('Find the faces in an image') and goes further by naming what is returned (crop and position) plus the concrete downstream use case (picking faceNo for kling_kolors_image). An agent can distinguish it from siblings like kling_kolors_image without opening either schema.

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 a clear motivating scenario ('e.g. to pick faceNo for kling_kolors_image reference face'), which tells the agent when this tool is the right precursor step. It stops short of explicit when-not conditions or naming alternatives for other face/identity workflows, so it is not a 5.

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?

Annotations already cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false). The description adds genuinely useful behavior beyond that: Kling cleans the clip, the return is a voice id, the result is account-bound ('use it with the same email'), and cost is usually free — a cost signal no annotation carries.

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?

Roughly 50 words, front-loaded with the verb and resource, and every clause carries information. The trailing 'POST /videos/voices' is marginal value for an agent invoking by tool name, and '(voice_N)' is slightly cryptic, keeping it from a 5.

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?

With no output schema, the description correctly states what comes back (the voice id) and how to use it. It covers source constraints, cost, and account coupling. It omits failure modes (bad URL, clip too short) and any rate/limit detail, which is a modest gap for a network-dependent write.

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 adds constraint detail the schema lacks (the 4.5-30 s duration window and 'clean speech' quality requirement) and ties the email parameter to a consequence ('use it with the same email'), which explains why the optional email matters.

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 ('Save your own voice') plus the exact downstream consumer (kling_omni_video v4, voice_N) and the source format (public URL of a clean speech sample). This distinguishes it cleanly from siblings like kling_list_voices, kling_delete_voice, and kling_list_tts_voices — an agent can route without opening any schema.

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 clear conditions for use: a public URL speech sample, 4.5-30 s, clean speech, and tells the agent to reuse the voice with the same email. It never explicitly names an alternative (e.g. kling_list_voices / kling_list_tts_voices) or a when-not-to-use case, so it stops short of a 5.

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?

Goes well beyond the annotations by disclosing the concrete effects (frees the account job slot, stops replyUrl callbacks), the non-effects (task keeps running and is still charged, kling_get_task still reads it), and the underlying endpoint. This is exactly the extra context the destructive/idempotent hints cannot convey.

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 tight sentences, front-loaded with the action and its side effects, then the critical exclusion, then the endpoint. No filler; every clause carries decision-relevant 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?

With no output schema and a one-parameter tool, the description supplies everything an agent needs: what it does, what it does not do, that the task remains billable and readable, and the route it hits. Nothing material is missing.

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% and the single task_id parameter is already documented as a digits-only Kling task id. The description adds nothing about the parameter beyond the URL template, 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 (stop tracking) and resource (a running task), and immediately contrasts it with the sibling operation it is not: 'It does NOT cancel the task at Kling'. The endpoint DELETE /scheduler/{task_id} pins it down further, letting an agent separate it from kling_delete_task and kling_get_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?

Gives a clear trigger condition ('when a task is stuck') and implicitly routes away from cancellation via the 'does NOT cancel' clause, but never names kling_delete_task as the tool to use when the agent actually wants to cancel. Context is clear without an explicit alternative.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true. The description adds genuinely new operational context: cost ('Free'), latency ('long text takes over a minute'), and the exact return payload (MP3 link and length), which the annotation set does not convey.

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 clauses, front-loaded with the core action and return value, then dependency, then cost/latency caveat. No sentence is filler; the endpoint is appended compactly at the end.

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?

With no output schema, the description correctly fills the gap by naming the return values, and it covers cost, latency, endpoint, and voice sourcing. What remains unstated is whether the call is synchronous or task-based and how the 'email' multi-account case behaves, both of which matter for an openWorld, non-idempotent 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%, so the schema already documents all five parameters, establishing a baseline of 3. The description adds meaning the schema lacks: practical length guidance for 'text' (the schema has no maxLength) and the provenance of speakerId from kling_list_tts_voices.

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 ('Read text aloud with a Kling voice'), names the return artifact (MP3 link + length), and points to kling_list_tts_voices as the source of speakerId, which cleanly separates it from that sibling list tool and from kling_add_sound.

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 a clear prerequisite path (speakerId comes from kling_list_tts_voices) and a practical usage constraint ('keep it to a few sentences'). It does not state explicit when-not conditions or contrast against siblings like kling_add_sound, so it falls short of a 5.

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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses that this is a paid, credit-consuming, non-idempotent generation call, quantifies typical cost per model and duration, and explains the asynchronous job flow: it blocks up to ~50 s then returns a task_id plus email for kling_get_task. That async/next-step disclosure is exactly the kind of behavior an agent cannot get from the annotations or schema.

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, which is good, but the rest is a single dense semicolon-chained paragraph of model specs and pricing that is hard to scan and partly restates schema descriptions. A per-model table or bullet list would earn the same information in less cognitive load; several clauses could be trimmed without loss.

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 22-parameter, zero-required, no-output-schema tool, the description covers the essentials an agent needs: default model, cost profile, duration/mode constraints per model, mutual exclusion between prompt and shot_N params, and what the call returns plus the follow-up tool. Nothing critical is left to guesswork.

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 cross-parameter constraints the schema cannot express: duration limits vary by model, negative_prompt/cfg_scale are older-model only, enable_audio=false is cheaper on kling-v3-0 and that native audio on kling-v2-6 requires pro mode, and 21:9 is kling-v4-0 only. It adds useful meaning, though some of it (audio, negative_prompt) is duplicated from the per-parameter schema text.

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 opening clause states a specific verb and resource ('Generate a video from a prompt') and immediately scopes the variants (custom multi-shot via shot_N params on kling-v3-0/v4-0). The name and description together make it obvious this is text-driven generation rather than image-driven. However, it never explicitly contrasts itself with siblings like kling_image_to_video or kling_extend_video, so the differentiation is inferred from the tool name rather than stated.

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 substantial selection guidance: per-model duration ranges, allowed modes, audio defaults, which models accept negative_prompt/cfg_scale, which run pro-only, and relative credit costs so the agent can pick cheaply versus at quality. What's missing is routing guidance against siblings ('if you already have a start image, use kling_image_to_video'), and no explicit statement of when not to use 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?

Annotations already declare readOnly=false, idempotent=false, destructive=false and openWorld=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: per-format size ceilings (10 MB image, 30 MB video/audio, 50 MB url), the accepted MIME types, and the POST /assets endpoint. It stops short of saying what happens on re-upload or any rate limits.

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?

A single dense sentence plus a short return-value sentence; formats, sizes, and transport options are front-loaded before the return semantics. Slightly packed with parenthetical lists, but no sentence 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?

There is no output schema, so the description correctly compensates by stating that a Kling url is returned and where it can be reused. Combined with the annotations and fully documented schema, an agent has enough to call it; only re-upload/idempotency behavior is unstated.

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 adds meaning the schema does not carry: the url path is capped at 50 MB, contentBase64 is intended for small files, and the format list maps onto the mimeType enum. That is real per-parameter selection guidance, not repetition.

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 (Upload) plus the resource (image/video/audio asset) and its destination (a Kling account), and enumerates the concrete formats accepted. This clearly separates it from siblings like kling_list_uploads and kling_delete_uploads, which operate on the same asset collection.

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 explains the output's purpose ('Returns the Kling url to use as an input (image, image_tail, video, audio, motionUrl, imageUrl…)'), which implies this is a prerequisite step for the generation tools. However, it never names a specific alternative tool or states when NOT to use it, so the routing guidance is only implied.

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?

Annotations already declare a non-read-only, non-idempotent, non-destructive, open-world write, so the safety profile is covered. The description adds genuinely new context by stating this is an async job ('A job, like kling_omni_image') and giving the endpoint, which implies a task id must be polled via kling_get_task. It stops short of naming the polling tool or the returned job id field, but it adds real value beyond the 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?

Three short sentences, front-loaded with the scoping rule and the alternative before any incidental detail. The trailing 'POST /images/upscale' line is marginal for an agent that invokes via tool call rather than raw HTTP, but it costs little.

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?

There is no output schema, so the description carries some return-value burden, and 'A job, like kling_omni_image' does convey that an async job is produced. For a 3-parameter tool with full schema coverage and annotations covering safety, this is nearly complete; only the polling follow-up (kling_get_task) is left implicit.

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 each parameter is already documented in the schema (email, workId, task_id). The description restates the task_id + workId pairing and the same-account rule but adds no format, syntax, or edge-case detail beyond the schema. Baseline 3 is appropriate 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 (upscale), a specific resource (one image of a finished Kling image task), and the exact inputs that identify it (task_id + its workId, same account). It explicitly names the sibling kling_enhance_image as the tool for any other image, so an agent can distinguish it without opening either schema.

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 routing rule is explicit: use this tool only for a finished Kling image task, and use kling_enhance_image for any other image. The 'same account' constraint further narrows applicability. Both the use case and the exclusion are stated, leaving nothing 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?

Annotations cover the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description is free to add operational context — and it does: Kling pre-validates photos and rejects unsuitable ones (e.g., AI-generated images), the call costs ~5 credits, and it returns an asynchronous job rather than the finished image. It stops short of naming the polling sibling (kling_get_task) or explaining result retrieval, but this is meaningful disclosure beyond the 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?

Four short, front-loaded fragments: the action and input combinations come first, followed by validation behavior, cost, job model, and endpoint. The telegraphic 'a dress (dressInput), or a top (upperInput) and / or bottoms (lowerInput)' is dense but every clause carries information; little 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 no output schema, the description covers cost, input validation behavior, the async job model, and the HTTP endpoint, which is close to what an agent needs to invoke and follow up correctly. It leaves the result-retrieval path only implied via 'A job, like kling_omni_image', which is a minor gap rather than a blocker.

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 six parameters (including email and imageCount) are already documented in the schema; the baseline is 3. The description restates the dress-vs-upper/lower combination rule that dressInput's schema description also carries, adding readability rather than new semantics.

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 ('Dress the person in humanImage in clothes from images') and enumerates the exact input slots (dressInput, or upperInput/lowerInput), so an agent can immediately tell this is a garment-swap operation rather than image generation. The endpoint (POST /images/virtual-try-on) and the analogy to kling_omni_image further pin down its scope.

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 implied through the input matrix (dress vs top/bottoms) and the note that Kling validates and refuses unsuitable photos, which hints at when the call will fail. But it never says when to prefer this over a sibling like kling_omni_image or kling_enhance_image, nor does it state exclusion conditions; kling_omni_image is cited only as a job-pattern analogue, not an alternative.

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