Video Clip MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity: batchProcess handles bulk operations, cancelTask manages task cancellation, clipVideo performs precise trimming, getSupportedFormats lists formats, getTaskStatus checks status, getVideoInfo retrieves metadata, mergeVideos combines files, and splitVideo divides videos. The descriptions specify unique functions, making tool selection straightforward for an agent.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern throughout (e.g., clipVideo, getVideoInfo, mergeVideos), with all tools using camelCase. However, there is a minor deviation with 'batchProcess' which could be more aligned as 'processBatch' or similar, but overall the pattern is predictable and readable.
Tool Count5/5
With 8 tools, the count is well-scoped for a video processing server, covering core operations like clipping, merging, splitting, and task management. Each tool earns its place by addressing specific needs in the domain, avoiding bloat while providing comprehensive functionality.
Completeness4/5
The tool set offers strong coverage for video processing, including creation (clip, merge, split), retrieval (info, formats, status), and management (cancel, batch). A minor gap exists in update operations, such as modifying video metadata or adjusting tasks, but agents can work around this with the available tools for most workflows.
Average 2.9/5 across 8 of 8 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.json to 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states '批量处理视频任务' without explaining what happens during processing, whether it's synchronous/asynchronous, if it returns status information, what errors might occur, or any rate limits. For a batch processing tool with no annotation coverage, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one Chinese phrase ('批量处理视频任务'). While this may be too brief for completeness, as pure conciseness it's maximally efficient with zero wasted words. The single phrase is front-loaded with the core concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a batch processing tool with no annotations, no output schema, and multiple sibling tools for individual operations, the description is insufficient. It doesn't explain the relationship to sibling tools, what the tool returns, how to monitor progress, or error handling. For a tool that presumably orchestrates multiple video operations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the single 'tasks' parameter with its structure. The description doesn't add any meaning beyond what the schema provides about task types or options. With high schema coverage, the baseline is 3 even without additional parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '批量处理视频任务' (batch process video tasks) states a general purpose but lacks specificity. It mentions 'video tasks' but doesn't clarify what types of tasks or distinguish from sibling tools like clipVideo, mergeVideos, and splitVideo which handle individual operations. The purpose is vague rather than specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when batch processing is appropriate, or how it relates to sibling tools like clipVideo, mergeVideos, and splitVideo which handle similar operations individually. There's no explicit or implied usage context.
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 the full burden of behavioral disclosure. '获取任务状态' implies a read-only operation, but it doesn't specify if it requires authentication, has rate limits, returns real-time or cached data, or what happens with invalid task IDs. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('获取任务状态'), which is highly concise and front-loaded with the core purpose. There's no wasted text, though it could benefit from slightly more detail to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the status return values might be (e.g., pending, completed, failed), error conditions, or how it fits with sibling tools like 'cancelTask'. For a status-checking tool in a video processing context, this leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'taskId' documented as '任务ID' (task ID). The description adds no additional parameter semantics beyond this, but since the schema fully covers the single parameter, the baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取任务状态' (Get task status) clearly states the verb ('get') and resource ('task status'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getVideoInfo' or 'getSupportedFormats' which also retrieve information, leaving the scope somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a task ID from another operation), exclusions, or comparisons to siblings like 'cancelTask' or 'batchProcess', leaving the agent without usage context.
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 full burden but only states the action without behavioral details. It doesn't disclose if cancellation is reversible, requires specific permissions, affects other tasks, has rate limits, or what happens on success/failure (e.g., partial rollback). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loaded with the core action, though it could benefit from more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial context like behavioral effects, error conditions, or return values. Given the server context (video processing tools), it should clarify what 'cancel' entails (e.g., stops processing, deletes partial files).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter ('taskId') documented in the schema. The description adds no additional meaning beyond implying 'taskId' identifies the task to cancel, which is already clear from the schema. Baseline 3 is appropriate as 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '取消指定的处理任务' clearly states the action (cancel) and target (specified processing task). It uses a specific verb and resource, though it doesn't explicitly differentiate from sibling tools like 'getTaskStatus' or 'batchProcess' which might involve task management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., task must be running), exclusions (e.g., cannot cancel completed tasks), or refer to sibling tools like 'getTaskStatus' for checking task state before cancellation.
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 mentions '毫秒级精度' (millisecond precision) which adds some context about accuracy, but doesn't describe important behavioral aspects: whether this is a destructive operation (modifies or creates new files), what happens if input/output paths are invalid, performance characteristics, error handling, or what the tool returns (since no output schema exists). The description is minimal and lacks critical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one sentence with 11 Chinese characters. It's front-loaded with the core purpose and includes one key feature (millisecond precision). There's no wasted language, though one could argue it's too brief given the tool's complexity. The structure is simple but effective for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a video processing tool with 7 parameters (including complex nested objects and enums), no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, performance implications of quality/codec choices, or how it differs from similar video manipulation tools. The high parameter count and technical nature of video processing demand more contextual information than this minimal description provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 86%, so the schema already documents most parameters well. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain the 'timeSegment' object structure, quality presets, codec choices, or metadata preservation implications. With high schema coverage, the baseline is 3, and the description doesn't enhance parameter understanding beyond the structured documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '剪辑视频片段' (clip video segments) with '毫秒级精度的时间段裁剪' (millisecond-precision time segment cropping). It specifies the verb (clip/crop) and resource (video segments) with precision details. However, it doesn't explicitly differentiate from sibling tools like 'splitVideo' or 'mergeVideos' which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'splitVideo' (which might split at specific points rather than crop segments) or 'mergeVideos' (which combines videos). There's no context about prerequisites, limitations, or typical use cases for this specific clipping operation.
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 states what the tool does but doesn't describe how it behaves—such as whether it's read-only, what kind of information is returned, error handling, or performance characteristics. This leaves significant gaps for a tool that presumably reads and processes video metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex video metadata. It doesn't hint at the structure or type of information returned (e.g., duration, resolution, codec), which could be critical for an agent to understand the tool's utility and integration into workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'filePath' clearly documented in the schema as '视频文件路径' (video file path). The description doesn't add any additional meaning beyond this, such as format examples or constraints, but the schema provides adequate baseline information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get') and resource ('视频文件的详细信息' meaning 'detailed information of video files'), making the purpose immediately understandable. It doesn't specifically distinguish from siblings like 'getTaskStatus' or 'getSupportedFormats', but the focus on video file details is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for usage, or differentiate it from sibling tools like 'getTaskStatus' or 'getSupportedFormats', leaving the agent to infer appropriate usage scenarios.
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 mentions '智能适配' (intelligent adaptation) for formats and resolutions, hinting at automatic processing, but doesn't clarify critical behaviors: whether merging is destructive to source files, if it requires specific permissions, processing time expectations, error handling, or output format details. For a complex video processing tool with 7 parameters, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('合并多个视频文件') and adds a key feature ('支持不同格式和分辨率的智能适配'). There is zero wasted text, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, video processing with potential side effects), lack of annotations, and no output schema, the description is incomplete. It doesn't address what the tool returns (e.g., success status, error messages), behavioral nuances like file overwriting or resource usage, or how it differs from siblings. For a mutation tool with rich parameters, this minimal description leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema itself (e.g., '输入视频文件路径数组' for inputPaths, enum descriptions for codecs). The description adds no additional parameter semantics beyond implying format/resolution adaptation, which is already covered by schema fields like 'resolution', 'videoCodec', and 'audioCodec'. Baseline 3 is appropriate as 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '合并多个视频文件' (merge multiple video files) with the added feature of '智能适配' (intelligent adaptation) for different formats and resolutions. It specifies the verb (merge) and resource (video files), but doesn't explicitly distinguish it from sibling tools like 'clipVideo' or 'splitVideo' beyond mentioning format/resolution adaptation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'batchProcess' (which might handle multiple files differently) or 'clipVideo'/'splitVideo' (which modify rather than merge videos). There's no context about prerequisites, limitations, or typical use cases beyond the basic functionality stated.
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 full burden but discloses minimal behavioral traits. It states what the tool does (splitting with three methods) but doesn't cover critical aspects: whether it's destructive to the original file, permission requirements, rate limits, error handling, or output behavior. For a tool with 10 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that states the core functionality and supported methods. Every word earns its place with zero waste. It's appropriately sized for a tool with clear parameters documented elsewhere, though it could benefit from more context given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, error conditions, file format requirements, or how the split methods interact with encoding parameters. For a video processing tool with multiple configuration options, this leaves too much undefined for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond implying the three split methods (duration, size, segments) which correspond to parameters splitBy, duration, maxSize, and segmentCount. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance understanding of parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '分割视频文件' (split video files) with specific methods '按时长、大小或段数分割' (by duration, size, or number of segments). It distinguishes from siblings like clipVideo (likely clips rather than splits) and mergeVideos, but doesn't explicitly contrast with batchProcess which might handle similar operations. The verb+resource+methods are specific, though sibling differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file format compatibility), when not to use it, or how it differs from siblings like clipVideo or batchProcess. The agent must infer usage from the tool name and parameters alone, which is insufficient for informed selection.
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 the full burden of behavioral disclosure. It only states what the tool does ('获取支持的视频格式和编码') without adding any context about traits like whether it's a read-only operation, if it requires authentication, rate limits, or what the return format might be. For a tool with zero annotation coverage, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: '获取支持的视频格式和编码'. It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence earns its place by clearly stating the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough to convey the basic purpose. However, it lacks details on behavioral traits and usage guidelines, which are needed for full context. Since there's no output schema, the description doesn't explain return values, but that's acceptable given the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional information is required or provided, which is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取支持的视频格式和编码' (Get supported video formats and encodings). It specifies the verb '获取' (get) and the resource '支持的视频格式和编码' (supported video formats and encodings), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'getVideoInfo', which might also provide format-related information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as whether it should be used before processing videos or as a reference for other tools like 'clipVideo' or 'mergeVideos'. Without such information, users must infer usage from the purpose alone.
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:

[![video-clip-mcp MCP server](https://glama.ai/mcp/servers/pickstar-2002/video-clip-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pickstar-2002/video-clip-mcp)

Score Badge

Copy to your README.md:

[![video-clip-mcp MCP server](https://glama.ai/mcp/servers/pickstar-2002/video-clip-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pickstar-2002/video-clip-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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-clip-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server