Video MCP Server
Server Quality Checklist
Latest release: v1.1.2
- Disambiguation4/5
Each tool targets a distinct part of the video/image processing pipeline: extracting frames, analyzing content, getting metadata, and generating scripts. The only minor ambiguity is between the 'analyze' tools and the corresponding 'generate_script' tools, since both operate on the same input types, but their purposes are still clearly differentiated.
Naming Consistency5/5Tool names consistently follow a verb_noun pattern using lowercase snake_case, such as extract_video_frames, analyze_video_content, and generate_video_script. This makes the tool set predictable and easy for an agent to navigate.
Tool Count5/5Six tools is a well-scoped size for a video and image analysis server focused on content understanding and script generation. Each tool has a clear role in the workflow without unnecessary redundancy.
Completeness4/5The core workflow of ingesting video/images, extracting frames, analyzing content, and generating scripts is well covered. Minor gaps exist around output management, such as editing or saving generated scripts, but these are not essential to the server's stated purpose.
Average 3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
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.
Tool Scores
- Behavior2/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, but it only states the final outcome. It does not reveal that the tool extracts video frames, calls Tencent Cloud, depends on credentials, or that cost is controlled via maxFrames.
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 a single efficient sentence with no filler and places the core action at the beginning. However, for a tool with 11 parameters and no output schema, the brevity borders on under-specification rather than ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex, cloud-backed tool with 11 parameters, no annotations, and no output schema, yet the description is only one short clause. It omits when to use it, what the generated script looks like, how the video is processed, cost/credential implications, and any relationship to sibling tools.
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%, so the structured parameters already carry the necessary meaning. The tool description itself adds no parameter-level detail, which is acceptable because the schema fully documents all 11 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('generate'), a concrete resource ('professional shooting script'), and the input basis ('video content'). It is clear enough to distinguish from analysis-focused siblings like analyze_video_content, though it does not explicitly name or contrast with generate_image_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as analyze_video_content or generate_image_script. There is no mention of prerequisites, exclusions, or preferred scenarios, leaving the agent to infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention that this likely invokes a Tencent Cloud API, requires authentication, may incur costs, or what side effects or outputs to expect. The parameters hint at cloud integration, but the description itself is silent.
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 a single, efficient sentence with no redundant content. It is concise and front-loads the core purpose, though it is so brief that it sacrifices informative value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters including credentials and no output schema, the description is inadequate. It does not explain the return value, prerequisites, failure modes, or how this tool fits into a larger workflow, leaving the agent without enough context to call it confidently.
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 each parameter already documented in the input schema. The description adds no additional parameter-level meaning, so 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('批量分析图片内容' - batch analyze image content) and is clearly distinct from the sibling video/script tools. However, it does not specify what type of analysis is performed or what the output looks like, 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.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of appropriate scenarios, exclusions, or routing to sibling tools, leaving the agent to infer usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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, but it only says frames are extracted. It does not mention output format, file naming, whether outputDir is created, overwrite behavior, dependencies, or side effects. The term '关键帧' may also mislead agents into thinking only keyframe strategy is supported, contradicting the default uniform strategy.
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 a single short sentence with no filler, which is efficient. However, the conciseness comes at the cost of omitting useful context like strategy behavior and output details, making it under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, an enum, and no output schema, the description is too thin. It does not explain how extracted frames are returned or saved, nor what each strategy produces. An agent would need to rely on parameter names and descriptions alone to understand the full workflow.
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?
The schema already describes all four parameters, including enum options for strategy, with 100% coverage, so the baseline is 3. The description adds no extra parameter semantics, such as path format requirements or how maxFrames interacts with strategy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action — extracting keyframe images from a video — using a specific verb and resource. It is distinguishable from sibling tools like analyze_video_content and get_video_info, though it does not explicitly name alternatives. Minor ambiguity exists because '关键帧' overlaps with the 'keyframe' strategy value while the tool also supports uniform and scene_change extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as analyze_video_content or get_video_info. It also does not explain when to choose uniform, keyframe, or scene_change strategies. Usage context must be inferred entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It implies a read-only operation through the word '获取', but it does not state what specific information is returned, whether it can fail, or any side effects. The description is too thin to provide genuine transparency.
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 a concise single sentence with no filler or unnecessary detail. It is front-loaded with the essential action, though it is so brief that it sacrifices useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what '基本信息' actually includes. It does not describe return values, supported paths, error behavior, or how this differs from analyze_video_content. An agent has only a vague idea of what will happen when invoking this tool.
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%, and the only parameter videoPath has a direct description ('视频文件路径'). The tool description adds no additional meaning to the parameter, but since the schema already documents it fully, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取视频文件基本信息' clearly states a specific verb ('获取') and resource ('视频文件基本信息'), so an agent can tell this is a retrieval tool. It is somewhat distinguishable from siblings like extract_video_frames or generate_video_script, though it doesn't explicitly differentiate from analyze_video_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives. There is no mention of when to prefer get_video_info over analyze_video_content, nor any exclusions or prerequisites, so an agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 reveals only that the tool generates a script from images, but says nothing about the fact that it evidently calls Tencent Cloud services (given secretId/secretKey/region parameters), what the output looks like, credential precedence, potential costs, rate limits, or side effects. This is a significant gap for a tool with cloud integration.
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?
A single front-loaded sentence with no filler — it states the purpose immediately. It is efficient and well-structured, though slightly under-specified for a tool with this many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool: 9 parameters including cloud credentials and region, no annotations, and no output schema. A one-line description is inadequate context. It does not explain the image-to-script workflow, the need for Tencent Cloud credentials, what the generated script contains, or how it relates to the sibling generate_video_script. An agent cannot fully anticipate side effects or requirements from this definition alone.
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%, so each of the 9 parameters is already documented with clear Chinese descriptions including defaults and enums. The description adds only the 'batch' qualifier that maps to imagePaths being an array, which is marginal. The baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '基于批量图片内容生成专业拍摄脚本' names a specific verb (generate), a clear resource (professional shooting script), and a scope (batch image content). The 'batch image' qualifier implicitly sets it apart from the sibling generate_video_script, though it does not name that alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: you feed it batch images and get a shooting script, which reasonably suggests it is for image-driven script generation rather than video-driven (generate_video_script) or pure analysis (analyze_image_batch). However, the description gives no explicit when-to-use guidance, no exclusions, and no mention of alternative tools, leaving the agent to infer the routing.
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, the description carries the full burden of behavioral disclosure. It reveals the external API vendor and the analysis purpose, which is useful. However, it does not disclose that this likely triggers an external network call, may require cloud credentials, may internally extract keyframes, or has cost implications — all relevant for an agent deciding to invoke it.
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 a single clear sentence with no wasted words, and it is front-loaded with the core action and resource. It loses one point because it could easily include a brief note about the external API and output without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a minimal viable description: purpose is clear, params are fully documented, but there is no output schema and no annotations. The agent is left without guidance on what the return value looks like, how errors surface (e.g., invalid video path, API failure), or that running the tool consumes cloud resources. For an external-API-backed tool, this is a notable gap.
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%, so the schema fully documents all seven parameters. The description adds the vendor/API context but no parameter-specific semantics beyond what the schema already provides. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('analyze video content') and identifies the concrete implementation (Tencent Hunyuan multimodal API). This clearly distinguishes it from frame-extraction and video-info tools. The only weakness is that it does not explicitly differentiate from analyze_image_batch beyond the medium.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when a video needs content analysis via the Tencent Hunyuan multimodal API. However, it gives no explicit when-to-use versus alternatives like analyze_image_batch or extract_video_frames, nor any conditions or exclusions. The routing context is weakly 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.
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:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/pickstar-2002/video-capture-script-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server