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?

No annotations are provided, so the description carries the full burden. It says it fetches 'current status and latest result payload', which is a mild disclosure of a polling read, but it doesn't disclose the status vocabulary, whether the payload is null or partial while pending, whether the result is preserved after completion, or rate limits for polling. For a polling endpoint with zero annotation coverage 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?

One sentence, front-loaded with the verb and resource. No filler or redundant restatement of the 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?

There is no output schema, so the description should say more about the return shape than 'status and latest result payload' – e.g., whether status is a string or enum and how the result payload varies per action. Two required parameters and zero annotations also mean the description should explain the polling contract. Adequate but with clear gaps.

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 both task_id and the action enum with the note that action identifies the asynchronous endpoint. The description mentions 'kling task' but doesn't add format, mutability, or constraints beyond the schema. Baseline 3 is correct when the schema does all the work.

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 (fetch the status and result payload for a kling task). Clear and distinguishable from siblings, which are all login, video-generation endpoints, or pricing. An agent can tell this is the monitoring/retrieval counterpart to the generation 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?

No when-to-use guidance. It doesn't say to call this after starting any of the six generation endpoints, nor when to stop polling (e.g., terminal status), nor whether the task must exist. Sibling tools like text_to_video return task ids implicitly, but the description never makes the create-then-get_task loop explicit.

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, and it does disclose the return payload (task id, status, output URLs), which signals an asynchronous job pattern consistent with the wait/callback_url params. It says nothing about authentication against RunAPI, cost, latency, rate limits, or failure/error behavior for what is clearly an external paid API call.

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

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

Two short sentences, front-loaded with the action and platform, then the return shape. Every clause carries information and 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 10-parameter task-creation tool with no output schema, the description adequately signals what comes back, and the schema covers most inputs. It omits the operational context an agent would want before firing a costly asynchronous job — authentication, what a non-terminal status means, and whether waiting is the default path.

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 80% with 10 parameters, so the schema already documents most inputs, making the baseline 3 appropriate. The description adds no parameter-level meaning (no guidance on prompt, model slug, character_orientation, or how wait interacts with callback_url), so it neither compensates for nor extends 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 and resource ('Create a Kling task on RunAPI (motion control)') and identifies the model line, which separates it from image_to_video, text_to_video, and extend_video. It does not explicitly name which sibling to prefer over it, but the motion-control framing implies a source image plus reference 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the eight sibling tools. The agent must infer from the required source_image_url/reference_video_url that this is motion transfer, but nothing tells it when this is the right choice versus image_to_video.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses that a task is created asynchronously and that the response includes a task id, status, and output URLs, which implies long-running/queued work. However, it omits cost implications, whether generation is billable, rate limits, and what the 'wait' polling semantics imply for latency.

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, front-loaded with the action and resource, then the return value. No filler, no repetition of schema content.

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 23-parameter tool with no annotations and no output schema, the description does far too little: it never tells the agent when to choose this over the other video-generation siblings, does not explain the polling/async workflow implied by 'wait', and gives only a one-line hint at return shape. The brief mention of task id/status/output URLs partially compensates for the missing output schema but not enough.

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 all 23 parameters (e.g., multi_prompt shot constraints, duration enums, image URL formats). The description adds nothing about parameters, so the baseline 3 applies; the two undocumented params (timeout_ms, poll_interval_ms) remain unexplained in both places.

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 ('Create') and resource ('Kling task on RunAPI') with the modality in parentheses ('text to video'), so an agent knows it is a generation task rather than a query or edit. It is distinguishable from image_to_video and extend_video by the explicit text-to-video framing, though it never names those siblings to draw the boundary.

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 tool versus image_to_video, motion_control, or edit_video, and no prerequisites (API key, credits, prompt requirement) are given. Usage is only implied by the tool name and the parenthetical.

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