KlingMCP
Server Quality Checklist
- Disambiguation5/5
Each tool has a clearly distinct purpose: text-to-video, image-to-video, motion transfer, video extension, single/batch task retrieval, and discovery utilities. No overlapping functionality between generation methods, and the descriptions explicitly direct users to the correct tool (e.g., directing image inputs to kling_generate_video_from_image).
Naming Consistency5/5Perfect consistency with klink_ prefix, snake_case throughout, and clear verb_noun structure (extend_video, generate_motion, get_task, list_models). The compound names like generate_video_from_image follow predictable patterns.
Tool Count5/58 tools is ideal for this scope - covering four generation modes (text2video, image2video, motion transfer, extension), task monitoring (single and batch), and discovery (models and actions). No bloat or obvious missing categories.
Completeness4/5Covers the core video generation lifecycle well with diverse creation methods and status checking. Minor gaps include no ability to list all tasks without knowing IDs first, and no cancel/delete operations for tasks, but the essential create-monitor-retrieve workflow is fully supported.
Average 4.1/5 across 8 of 8 tools scored.
See the tool scores section below for per-tool breakdowns.
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v0.1.0
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
- This server provides 8 tools. View schema
No known security issues or vulnerabilities reported.
This server has been verified by its author.
Add related servers to improve discoverability.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the async nature by mentioning 'Task ID' in returns, implying a job-based pattern. However, it omits cost/credit implications, expected generation time, error handling (e.g., character detection failure), or data retention policies—critical details for a media generation API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with clear visual hierarchy: one-sentence purpose statement, explanatory elaboration, bulleted usage scenarios, and return type declaration. Information is front-loaded with the core function in the first sentence. No redundant or filler text; every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with 100% schema coverage and existence of output schema, the description adequately covers the tool's purpose, usage contexts, and return value (Task ID). However, completeness is limited by absence of annotations (costs, destructive hints) which the description does not compensate for, and lack of behavioral constraints or error condition documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with excellent field-level documentation (e.g., character_orientation enum values explained). The main description references 'reference video' and 'character image,' implicitly mapping to required parameters, but adds no syntax details, format constraints, or examples beyond what the schema already provides. Baseline 3 appropriate given comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb ('Transfer') and clear resource ('motion from a reference video to a character image'), immediately distinguishing it from sibling tools like kling_generate_video (which generates from text) and kling_extend_video (which extends existing videos). The second sentence reinforces with 'character animation' and 'extracting motion,' leaving no ambiguity about the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit 'Use this when:' section with three concrete scenarios (animate character, create dance video, transfer specific movements), providing clear positive guidance. However, lacks explicit 'when not to use' guidance or named sibling alternatives, though the tool's specific scope makes incorrect selection unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully conveys that the tool appends content temporally ('after the original video ends') and mentions 'Task ID' in returns, hinting at async behavior. However, it fails to explain the async workflow (e.g., need to poll with kling_get_task), preservation of the original video, or any rate/cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose statement, elaboration, usage guidelines, and returns. The 'Use this when' bullets efficiently convey intent. Slightly redundant in mentioning returns when output schema exists, but appropriately front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage and existence of output schema, the description adequately covers the tool's purpose and selection criteria. Minor gap in not referencing the sibling kling_get_task tool for polling the returned Task ID, but sufficient for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with comprehensive documentation for all 6 parameters including enums and defaults. The description does not explicitly discuss parameters, relying entirely on the schema. With such high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Extend') and resource ('existing video'), clearly defining scope as 'additional content' that continues 'after the original video ends.' This effectively distinguishes it from sibling generation tools like kling_generate_video by emphasizing 'previously generated' and 'continue.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes an explicit 'Use this when:' section with three concrete scenarios (video too short, continue story/motion, building longer video piece by piece). This provides clear guidance on when to select this tool over initial generation alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Excellently documents domain-specific state lifecycle ('pending', 'completed', 'failed') with behavioral explanations. Discloses return data composition (URLs, state, metadata) and suggests failure handling ('check error message').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Clear hierarchical structure with purpose first, followed by usage scenarios, task states, and returns. Each section earns its place—task state definitions are essential for async workflow comprehension. Minor efficiency opportunity: 'Returns' section duplicates output schema, but provides useful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for single-task status polling. Covers workflow integration (following generation calls), state machine behavior, and output data. Minor gap: could reference kling_get_tasks_batch as alternative for bulk operations to ensure correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with task_id fully described in schema (including linkage to sibling tool outputs). Description focuses on operation semantics rather than parameter details, appropriate baseline for high-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Strong specific verb ('Query') plus clear resource scope ('status and result of a video generation task'). Explicitly positions this as the retrieval/polling tool, distinguishing it from generation siblings (kling_generate_*, kling_extend_*) by describing its role in checking completion of previous submissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent explicit guidance with 'Use this when:' section listing three specific scenarios (check completion, retrieve URLs, get full details). However, lacks distinction from sibling kling_get_tasks_batch—when to prefer single vs batch retrieval is unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the efficiency characteristic and return structure ('Status and video information for all queried tasks'), but omits error handling behavior, partial failure scenarios, rate limits, or authentication requirements that would be critical for a batch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, efficiency rationale, usage conditions, returns). The bullet points effectively front-load key usage scenarios. Minor redundancy exists between 'Efficiently check' and 'More efficient than,' but overall every sentence earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema present, the description is appropriately complete. It covers purpose, sibling differentiation, usage scenarios, and return values. It could be improved by mentioning error handling for invalid task IDs, but the core functionality is sufficiently documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully documents the task_ids parameter including the 50-task limit. The description mentions 'multiple tasks' but does not add semantic context, constraints, or format guidance beyond what the schema provides, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Query multiple video generation tasks at once' (verb + resource + scope). It explicitly distinguishes itself from sibling tool kling_get_task by stating it is 'More efficient than calling kling_get_task multiple times,' making the selection criteria unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance via 'Use this when:' bullet points covering multiple pending generations, batch status checks, and tracking scenarios. It explicitly names the alternative single-task tool (kling_get_task) and explains the efficiency advantage, giving clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately describes the return value ('Categorized list') but omits safety indicators (read-only nature), API interaction details (whether this requires auth or hits live API vs. cached data), and error conditions. The 'List' verb implies read-only behavior, but explicit confirmation is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the core action ('List all available...') in the first sentence. Four sentences total with minimal redundancy (sentences 2 and 3 overlap slightly in explaining the reference nature). The 'Returns:' section is structured and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple discovery tool with zero input parameters and an existing output schema, the description provides sufficient context. It explains the tool's meta-purpose adequately, though it could explicitly state this is safe to call without side effects given the lack of readOnlyHint annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters. According to the evaluation rubric, 0 params equals a baseline score of 4. No parameter documentation is required or expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List[s] all available Kling API actions and corresponding tools' using a specific verb and resource. It distinguishes itself from sibling execution tools (generate_video, extend_video, etc.) by positioning this as a 'Reference guide' for capability discovery rather than an action tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it helps understand 'which tool to use' and is 'Helpful for understanding the full capabilities,' suggesting when to reach for this vs. direct execution. However, it lacks explicit when-not guidance or clear statements like 'Use this first when uncertain which generation tool to invoke.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return structure ('Task ID and generated video information including URLs and state') implying async behavior, and claims 'high-quality' output. However, it omits operational details like credit costs, typical generation time, content moderation policies, or explicit async polling requirements despite returning a 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with one-line purpose, elaboration, bulleted usage conditions, explicit alternative reference, and returns block. Every sentence provides distinct value; no repetition of schema details or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters with 100% schema coverage and existence of output schema, the description appropriately focuses on sibling differentiation and return value summary rather than parameter minutiae. Completeness would be perfect with explicit mention of the async polling pattern (implied by Task ID and existence of kling_get_task sibling but not stated).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions 'text prompt' reinforcing the required parameter, but adds no additional syntax guidance, examples, or constraint explanations beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+mechanism ('Generate AI video from a text prompt using Kling') and explicitly distinguishes from the sibling 'kling_generate_video_from_image' by stating this is for when 'you don't have reference images'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when:' bullet points covering the primary use case (text description), prerequisite absence (no reference images), and quality attribute (quick generation). Explicitly names the sibling alternative 'kling_generate_video_from_image' for image-based workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the async pattern (returns Task ID and state), explains the interpolation behavior ('smooth motion between them'), and states the critical constraint that at least one image URL is required. However, it omits operational details like cost/quota implications, privacy considerations of sending image URLs, or error handling patterns expected for a 12-parameter AI generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, mechanism, usage scenarios, constraints, and returns. It is front-loaded with the core function. The 'Returns' section is slightly redundant given the output schema exists, but it clarifies the Task ID async pattern which may not be immediately obvious from schema structure alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema (100% coverage, 12 parameters with enums) and presence of an output schema, the description appropriately focuses on high-value additions: differentiating purpose, usage scenarios, and cross-parameter validation constraints. It does not need to enumerate individual parameters or return fields, and successfully covers the essential domain-specific logic for an image-conditioned video generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the input schema has 100% description coverage (baseline 3), the description adds crucial semantic constraints not captured in the schema: specifically, that 'At least one of start_image_url or end_image_url must be provided' despite both being optional in the schema with default values. It also clarifies how the parameters interact ('animate from this image... towards this image').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Generate[s] AI video using reference images as start and/or end frames', using a specific verb and resource combination. It clearly distinguishes this from siblings like kling_generate_video (text-to-video) and kling_extend_video by emphasizing the image reference capability and 'smooth motion between' frames functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'Use this when:' section with three specific scenarios (animating specific images, creating transitions between two images, precise visual control). While it effectively implies when to use this over alternatives, it lacks explicit 'when not to use' guidance or named sibling alternatives (e.g., 'don't use for text-only generation').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes return format ('Table of all models') and content ('capabilities and use cases'), but omits safety characteristics, rate limits, or caching behavior. Functional description present but lacks operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences with zero waste: purpose, functionality, usage guidance, and return format. 'Returns:' section efficiently signals output structure. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple discovery tool with zero parameters and existing output schema. Covers purpose, usage context, and return summary. Does not need to elaborate return values further since output schema exists (as indicated by context signals).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters. Per evaluation rules, 0 params = baseline 4. Description appropriately omits parameter discussion since none exist, avoiding unnecessary bloat.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Explicit verb 'List' with specific resource 'Kling models' and context 'for video generation'. Clearly distinguishes from sibling generation tools (kling_generate_video, kling_extend_video) by specifying this is for discovery/model selection rather than production.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to understand which model to choose for your video', positioning it correctly in the workflow before generation. Lacks explicit 'when not to use' or contrast with kling_list_actions, but clear positive guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
How to claim the server?
If you are the author of the server, you simply need to authenticate using GitHub.
However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.
{
"$schema": "https://glama.ai/mcp/schemas/server.json",
"maintainers": [
"your-github-username"
]
}Then, authenticate using GitHub.
Browse examples.
How to make a release?
A "release" on Glama is not the same as a GitHub release. To create a Glama release:
- Claim the server if you haven't already.
- Go to the Dockerfile admin page, configure the build spec, and click Deploy.
- Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
How to add a LICENSE?
Please follow the instructions in the GitHub documentation.
Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Latest Blog Posts
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AceDataCloud/KlingMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server