kling-mcp

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

With no annotations, the description carries the full burden, and it does disclose the return shape (task id, status, output URLs) which is useful given there is no output schema. However, it omits the asynchronous task semantics implied by the wait/poll_interval_ms/timeout_ms parameters, the default blocking poll (wait=true), and any auth or cost considerations despite a sibling check_pricing 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?

Two short sentences with no filler, and the core purpose is front-loaded before the return-value note. Minor waste in the '(ai avatar)' parenthetical and vendor jargon, but nothing that harms 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 an 8-parameter generative task tool with no annotations and no output schema, the description covers only the return shape and leaves usage conditions, async/polling behavior, and two parameters entirely unaddressed. An agent has enough to attempt a call but not enough to call it correctly or confidently.

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 description mentions no parameters at all, and schema coverage is only 75%, below the high-coverage threshold where the schema alone could justify a 3. Two undocumented parameters (timeout_ms, poll_interval_ms) have no meaning supplied anywhere, so the description fails to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Create a Kling task'), and the '(ai avatar)' gloss ties it to the tool name, distinguishing it from sibling video tools like text_to_video and image_to_video. The 'Kling task on RunAPI' phrasing is vendor jargon that only indirectly conveys that this produces a lip-synced avatar from an image plus audio.

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?

No when-to-use guidance is given: nothing says this is for talking-head/lip-sync avatars requiring an image and audio, nor how it differs from image_to_video or motion_control. The agent must infer applicability purely from the required params.

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

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

No annotations are provided, so the description carries the full disclosure burden. 'Look up' implies a safe read, but the description does not state whether pricing is real-time or cached, whether auth is required, or what the lookup returns (per-call, per-second, currency), which matters greatly for a pricing tool with no output 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?

A single front-loaded sentence with no waste; the resource and scope appear immediately. Nothing extraneous is included.

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 no annotations, the description should explain what the pricing result looks like and any auth or rate constraints, but it says nothing about the return value. For a tool whose entire purpose is retrieving pricing data, this leaves a significant 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%, so the schema already documents both params including the action enum and the default behavior, making the baseline 3 appropriate. The phrase 'kling model line' hints that the model param is constrained to kling slugs, but no semantic detail is added beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Look up RunAPI pricing') and scopes it to the 'kling model line', which is clear enough for an agent to understand the operation. It does not differentiate from siblings, but no sibling tool overlaps with pricing lookup, so the risk of confusion is low.

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 guidance: nothing explains when an agent should call this versus acting on pricing info, nor any prerequisite such as needing a model slug first. With both params optional, the description does not indicate any situation in which the tool is or isn't appropriate.

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

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

No annotations are present, so the description carries the full behavioral burden. It notes the return values (task id, status, output URLs), but says nothing about asynchronous task creation, polling/wait behavior, authentication, cost, or the mutual exclusivity of source inputs, leaving major behavioral traits undisclosed.

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 single sentence is front-loaded with the primary operation and has no filler, and the return-value note is useful. Even though it is terse for a 13-parameter tool, the dimension rewards lack of waste.

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 complex video-editing task tool with no annotations and no output schema, the description is under-specified. It covers the return shape only briefly and omits the asynchronous workflow, usage context, and source-constraint details that an agent would need beyond 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 85%, so the input schema already documents nearly all 13 parameters, including mutual exclusivity notes and known values. The description adds no parameter meaning, so the baseline of 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 a specific action ('edit video') and the mechanism ('Create a Kling task on RunAPI'), which lets an agent know this is not text-to-video or image-to-video. However it does not explicitly name or differentiate from sibling tools such as extend_video or motion_control, so it falls 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 gives no when-to-use guidance, no alternatives, and no conditions under which this tool should be chosen over sibling video tools. It only labels the operation; the agent must infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does mention that a task id, status, and output URLs are returned, hinting at an async job model, but says nothing about cost, authentication, rate limits, whether the source task must be Kling v2.5 Turbo specifically, or how wait/callback interact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action and followed by the return contract; nothing is wasted. It is marginally terse given eight parameters, 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 an eight-parameter async task-creation tool with no output schema, the description partially compensates by naming the return fields (task id, status, output URLs). However, with no annotations it leaves async behavior, callback_url/polling semantics, and cost unaddressed, so it is minimally adequate rather than 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 description coverage is 75%, so most parameters are self-documenting and the baseline is 3. The description adds no meaning beyond the schema, and two parameters (timeout_ms, poll_interval_ms) have no description in either place, so it does not compensate for that gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource ('Create a Kling task ... extend video'), so an agent can tell it produces a video extension rather than a fresh generation. It does not explicitly differentiate itself from siblings like text_to_video or image_to_video, but the action is unambiguous.

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 statement of when to use this versus alternatives such as text_to_video or edit_video, nor any prerequisites beyond the implicit need for a completed source task implied by the required source_task_id. The agent must infer that this continues an existing generation rather than starting one.

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

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

With no annotations, the description carries the full burden. It does add real behavioral context by implying read-only retrieval and that the result is the 'latest' payload (i.e., may not yet be final), which supports polling semantics. It does not disclose rate limits, how to interpret status values, or what happens on an unknown task_id.

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 with no filler; the resource and the returned payload are stated immediately.

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 two-parameter lookup with full schema coverage and no output schema, the description usefully states what comes back (status plus latest result payload), which compensates for the missing output schema. It stops short of explaining status semantics or error behavior, so it is 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 description coverage is 100%, and both required parameters (task_id, action enum) are documented in the schema. The description adds no further parameter detail, 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 ('Fetch') and resource ('status and latest result payload for a kling task'), so the agent knows exactly what it retrieves. It is clearly distinguishable from the sibling creation tools (text_to_video, extend_video, etc.), though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: because siblings all create tasks, this tool is obviously the status/polling counterpart, and the word 'current' hints at repeated polling. However, there is no explicit statement of when to call it (e.g., after task creation, poll until terminal status) 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?

With no annotations, the description carries the full burden, and it does disclose the async task pattern by stating it returns a task id, status, and output URLs. However, it omits auth/who can call, cost implications (a sibling check_pricing exists), and the fact that wait defaults to true (a blocking call by default), which are non-obvious behavioral traits.

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, front-loaded sentences with no wasted words; the create action and return shape are both immediate. It is efficient, though slightly clipped for a tool of this complexity.

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 19-parameter, no-annotation, no-output-schema generation tool the description is thin. It does describe the return values (task id, status, output URLs), which compensates for the missing output schema, but leaves async/polling behavior, exclusivity constraints, and cost context 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 89%, so the schema already documents almost all 19 parameters. The description adds no parameter-level meaning (e.g., interaction rules like reference_video_url vs last_frame_image_url, or the mutually exclusive frame options), so it stays at the high-coverage 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+resource ('Create a Kling task') and parenthetically scopes it to image-to-video, which implicitly separates it from the text_to_video and extend_video siblings. It stops short of naming those alternatives explicitly, so it is clear but not fully self-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?

There is no when-to-use guidance at all: nothing tells the agent how this differs from text_to_video, motion_control, or extend_video, nor when to prefer wait=true polling versus a callback_url. Usage must be inferred entirely from the name.

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

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

With no annotations, the description carries the behavioral burden. It discloses the interactive browser flow and the file write side effect (config.json). However, it does not mention that it may overwrite existing credentials or that it could block waiting for user input, though these are 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?

The description is a single, well-structured sentence that front-loads the action ('Authenticate RunAPI') and provides necessary details without extraneous 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 simple login tool with one optional parameter and no output schema, the description covers the core purpose and side effect. It lacks an explicit statement that this is a prerequisite for other tools, but that is implied.

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 only parameter 'force' has a description). The tool description adds no additional meaning about parameters beyond the schema, so the baseline of 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 clearly states the tool's purpose with a specific verb ('Authenticate'), target resource ('RunAPI'), method ('browser PKCE login flow'), and side effect (saving to config.json). It is distinct from sibling tools, none of which relate to authentication.

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 usage (to authenticate RunAPI) but does not explicitly say when to run it (e.g., before other RunAPI tools) or when to use the 'force' parameter. Since there are no alternative auth tools among siblings, 'vs alternatives' is not applicable.

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

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

With no annotations, the description carries the full behavioral burden yet only discloses the return shape. It omits that this is an async generation job, that 'wait' defaults to polling, whether it costs credits, and how timeouts/callbacks behave — all of which are behavioral traits an agent must know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and resource, followed by the return shape. No waste, though it is arguably under-specified rather than efficiently complete.

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 11-parameter async generation tool with no annotations and no output schema, the description partially compensates by naming the return values (task id, status, output URLs). However it leaves usage, polling behavior, and cost/auth context 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 82%, so the schema already documents most parameters (including the three required URLs and enum-like known values). The description adds no parameter meaning beyond what the schema provides, which is the baseline 3 for high coverage.

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: 'Create a Kling task on RunAPI (motion control)'. The purpose is clear, but it does not differentiate from siblings like image_to_video, text_to_video, or edit_video, which are also task-creating tools on the same platform.

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?

No when-to-use guidance is given. The '(motion control)' parenthetical hints that a source image and reference video drive motion, but the description never says when to choose this over image_to_video or text_to_video, nor does it state prerequisites or 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?

No annotations are supplied, so the description carries the full disclosure burden. It notes the response shape (task id, status, output URLs), which is useful given there is no output schema, but says nothing about polling/`wait` behavior, cost, async callback semantics, or what happens with the many optional reference params. For a 22-parameter generation tool this is thin.

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, both front-loaded and waste-free: purpose first, then the return contract. Nothing is redundant, though it is arguably under-informative rather than truly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 22 parameters, zero annotations, and no output schema, the description should at minimum explain the wait/polling default and the interaction between multi_shots, multi_prompt, and the reference-* fields. The return-shape sentence partially compensates for the missing output schema, but the behavior of a complex async generation task is left unexplained.

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 91%, so the schema already documents nearly every parameter (including enum-like known values and defaults). The description adds no parameter-level meaning 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 ('Create a Kling task'), plus the modality '(text to video)', which distinguishes it from siblings like image_to_video and edit_video. It does not name those siblings explicitly, but the modality label is enough for an agent to route correctly.

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?

No when-to-use guidance, no mention of when to prefer image_to_video/extend_video/motion_control, and no prerequisites (e.g. that reference image URLs push work toward the image_to_video path). The agent must infer usage from the tool name alone.

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