MCP Media Processing Server

by maoxiaoke

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific media processing tasks like compression, conversion, resizing, and watermarking. However, 'apply-effect' is somewhat ambiguous and could overlap with other image manipulation tools like 'add-watermark' or 'rotate-image', potentially causing confusion in tool selection.
Naming Consistency5/5
All tools follow a consistent verb-noun pattern with hyphenated naming (e.g., 'compress-image', 'convert-video', 'resize-image'). This uniformity makes the tool set predictable and easy to navigate, with no deviations in style or convention.
Tool Count5/5
With 10 tools, the server is well-scoped for media processing, covering common operations for images and videos. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain and not overwhelming for agents.
Completeness4/5
The tool set provides good coverage for core media processing tasks, including compression, conversion, resizing, and trimming. However, there are minor gaps, such as no explicit tools for audio processing or metadata handling, which could limit some workflows but are not critical for basic operations.
Average 2.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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 ISC 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal information. It doesn't mention whether this operation is destructive to the original file, what permissions are needed, potential rate limits, error conditions, or what happens when conversion fails. The description only states what the tool does at a high level without behavioral details.
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 at just four words, with zero wasted language. It's front-loaded with the core purpose and contains no unnecessary elaboration. Every word earns its place in communicating the essential function.
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 file manipulation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, what happens on success/failure, file size limitations, supported input formats, or quality implications of format conversion. The combination of sparse description and missing structured data leaves significant gaps for an agent trying to use this tool effectively.
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 four parameters thoroughly. The description adds no additional parameter information beyond what's in the schema - it doesn't explain parameter interactions, provide format examples beyond what's in the schema, or clarify edge cases. The baseline of 3 is appropriate when 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 verb 'convert' and the resource 'image', specifying the action of changing format. It distinguishes from some siblings like resize-image or rotate-image by focusing on format conversion rather than geometric transformations, though it doesn't explicitly differentiate from all siblings like compress-image which might also involve format changes.
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 when format conversion is appropriate compared to compression (compress-image), applying effects (apply-effect), or using the more general execute-ffmpeg tool. No prerequisites, exclusions, or contextual usage information is provided.
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 offers minimal behavioral insight. It mentions conversion but doesn't disclose performance characteristics (e.g., processing time, resource usage), error conditions, or what happens to the original file. For a tool that likely involves file I/O and processing, this is 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?
Extremely concise with a single sentence that directly states the tool's purpose. No wasted words or unnecessary elaboration, 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?
For a video conversion tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, potential side effects, or how it interacts with sibling tools. The agent would need to infer too much from minimal information.
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 parameters are well-documented in the schema. The description adds no additional parameter context beyond implying format conversion, which is already covered by the 'outputFormat' parameter description. Baseline 3 is appropriate when the schema does 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 'Convert video to different format' states the basic action (convert) and resource (video), but it's vague about scope and doesn't distinguish from sibling tools like 'convert-image' or 'trim-video'. It lacks specificity about what conversion entails beyond format change.
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 on when to use this tool versus alternatives like 'compress-video', 'trim-video', or 'execute-ffmpeg'. The description provides no context about use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names 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. 'Add watermark to image' implies a mutation operation that creates a new watermarked image file, but it doesn't disclose important behavioral traits like whether the original file is modified or preserved, what file formats are supported, error conditions, or performance characteristics. The description is too minimal to provide adequate behavioral context for a tool with 6 parameters.
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 at just four words, with zero wasted language. It's front-loaded with the core action and immediately communicates the tool's primary function. Every word earns its place, making this description maximally efficient in terms of word economy.
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 tool with 6 parameters, no annotations, and no output schema, the description is insufficiently complete. While concise, it doesn't provide enough context about the tool's behavior, limitations, or relationship to sibling tools. The agent would need to rely heavily on the input schema alone, missing important contextual information about when and how to use this tool effectively.
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%, meaning all parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
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 'Add watermark to image' clearly states the action (add) and target resource (watermark to image), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling tools like 'apply-effect' or 'convert-image' which might also involve image manipulation, leaving some ambiguity about when this specific tool should be chosen over alternatives.
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. With sibling tools like 'apply-effect', 'compress-image', and 'convert-image' available, there's no indication whether this is the only tool for watermarking or if other tools might also handle watermarks. No context about prerequisites, typical use cases, or exclusions is provided.
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 offers minimal behavioral information. It states the action ('apply visual effect') but doesn't disclose whether this modifies the original file or creates a new one, what happens if output parameters aren't provided, whether there are file format limitations, or what happens on failure. The description doesn't contradict annotations (since none exist), but provides inadequate behavioral context for a mutation tool.
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 at just 5 words, front-loading the core purpose with zero wasted words. Every element earns its place, making it easy to parse while conveying the essential function.
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 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address what the tool returns (success/failure indicators, output location confirmation), doesn't explain behavioral aspects like file handling, and provides no context about limitations or prerequisites despite the tool performing a potentially complex image transformation.
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?
With 100% schema description coverage, the baseline is 3. The description doesn't add any parameter semantics beyond what's already documented in the schema - it doesn't explain what the effects do, how intensity interacts with different effects, or provide guidance on parameter combinations. The schema already documents all parameters thoroughly.
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 ('apply') and target ('visual effect to image'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'convert-image' or 'resize-image' which also modify images, leaving some ambiguity about when to choose this specific tool.
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. With multiple sibling tools that also process images (convert-image, resize-image, add-watermark, etc.), there's no indication of when visual effects are appropriate versus other image transformations or which effects might be preferred for specific use cases.
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 offers minimal behavioral insight. It mentions ImageMagick as the backend but doesn't disclose side effects (e.g., overwriting files), performance traits, or error handling. For a mutation tool, this is 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 a single, efficient sentence with zero wasted words. It front-loads the core purpose ('Compress PNG image') and includes implementation detail only where necessary.
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 insufficient. It doesn't explain what the tool returns (e.g., success status, output path), potential errors, or file system impacts, leaving critical gaps for agent usage.
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 parameters are well-documented in the schema. The description adds no additional parameter context beyond implying PNG format support, aligning with the baseline for high schema coverage.
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 ('Compress') and resource ('PNG image'), and specifies the implementation method ('using ImageMagick'). It distinguishes from siblings like 'resize-image' or 'convert-image' by focusing on compression, though it doesn't explicitly contrast with them.
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 like 'resize-image' (which might also reduce file size) or 'convert-image' (which could include compression). The description lacks context about typical use cases or prerequisites.
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 for behavioral disclosure. 'Compress video file' implies a mutation operation that creates a new file, but it doesn't specify whether the original file is modified, what formats are supported, error handling, or performance characteristics. This is a significant gap for a tool with destructive potential.
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 maximally concise with just three words that directly convey the core functionality. There's zero wasted language, and it's perfectly front-loaded with the essential information.
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 compression tool with no annotations and no output schema, the description is insufficient. It doesn't address what compression algorithm is used, supported formats, whether the operation is lossy/lossless, expected output characteristics, or error conditions. The agent would need to guess about important behavioral aspects.
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 description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for all 4 parameters. The baseline score of 3 reflects adequate schema documentation, but the description doesn't enhance understanding of parameter relationships or practical usage.
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 'Compress video file' clearly states the verb ('compress') and resource ('video file'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'trim-video' or 'convert-video' that also operate on video files, which prevents a perfect 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 like 'trim-video' or 'convert-video'. There's no mention of prerequisites, use cases, or exclusions, leaving the agent to 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.
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 'Execute any FFmpeg command' but doesn't mention critical aspects like required permissions, whether it's read-only or destructive, error handling, rate limits, or what happens to the input file. For a powerful execution tool with zero annotation coverage, this is a significant gap.
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 directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, with every word earning its place.
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 complexity of executing arbitrary FFmpeg commands, no annotations, and no output schema, the description is incomplete. It doesn't address safety concerns, error conditions, output behavior, or how it differs from specialized siblings. For a general-purpose execution tool in this context, more guidance 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?
The schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain FFmpeg option syntax beyond the schema's example). The baseline of 3 is appropriate when 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 verb 'Execute' and the resource 'FFmpeg command with custom options', making the purpose understandable. However, it doesn't distinguish this general-purpose FFmpeg execution tool from its more specialized siblings like 'compress-video' or 'convert-video', which would require explicit differentiation to earn 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/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 the more specific sibling tools (e.g., compress-video, convert-video, trim-video). It lacks any context about alternatives, prerequisites, or exclusions, leaving the agent to guess based on tool names 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 states the core function but omits critical details: whether the operation is destructive (overwrites files?), what permissions are needed, supported image formats, error handling, or output location specifics. For a mutation tool with zero annotation coverage, this is 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('Resize image to specified dimensions') earns its place by conveying essential information concisely.
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 6-parameter mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about behavioral traits (destructiveness, auth needs), output details (where files are saved, return values), and usage context. The high parameter count and mutation nature require more comprehensive guidance.
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 fully documents all 6 parameters. The description adds no parameter-specific information beyond implying 'dimensions' relates to width/height. It doesn't explain parameter interactions (e.g., how maintainAspectRatio affects dimensions) or constraints (e.g., valid pixel ranges). Baseline 3 is appropriate when 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 ('Resize') and resource ('image') with the specific goal of achieving 'specified dimensions'. It distinguishes from siblings like 'rotate-image' or 'compress-image' by focusing on dimension changes rather than orientation or file size reduction. However, it doesn't explicitly differentiate from all siblings (e.g., 'convert-image' might also resize).
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 like 'compress-image' (for size reduction) or 'convert-image' (for format changes with possible resizing). The description lacks context about prerequisites (e.g., file format support) or exclusions (e.g., when not to resize).
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 states the action ('rotate') but doesn't mention critical details like whether the operation modifies the original file, creates a new file, requires specific permissions, or has performance implications. 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 extremely concise with just one sentence ('Rotate image by specified degrees'), which is front-loaded and wastes no words. Every part of the sentence contributes to understanding the tool's purpose, making it efficient and well-structured.
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 complexity of an image manipulation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like file handling, error conditions, or output details, leaving significant gaps for the agent to infer or guess.
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 description doesn't add any parameter semantics beyond what's already in the input schema, which has 100% coverage. It mentions 'specified degrees' but doesn't explain rotation direction, valid ranges, or how parameters interact. With high schema coverage, the baseline is 3, 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 with a specific verb ('rotate') and resource ('image'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools like 'convert-image' or 'resize-image' which might also involve image manipulation, so it doesn't fully distinguish from alternatives.
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 'resize-image' or 'convert-image', nor does it specify scenarios where rotation is appropriate over other image operations. This leaves the agent without context for tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Trim video' implies a mutation operation that modifies video content, but the description doesn't specify whether this is destructive to the original file, what permissions are required, or any rate limits. It mentions saving to the Downloads folder in the schema, but this isn't highlighted in the description itself, leaving behavioral traits largely undocumented.
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 waste—'Trim video to specified duration' directly conveys the core action. It's appropriately sized for a tool with clear parameters and no complex behavioral nuances needing elaboration.
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 complexity of a video editing tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address key contextual aspects like file format support, error handling, output behavior (e.g., where files are saved by default), or how trimming is applied. The schema covers parameter details, but the description lacks overall operational context.
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 all parameters well-documented in the schema (e.g., 'Duration in format HH:MM:SS', 'Absolute path to input video file'). The description adds no additional parameter semantics beyond implying 'duration' and possibly 'startTime' from 'specified duration', but it doesn't explain the relationship between startTime and duration or mention optional parameters like outputPath. 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 'Trim video to specified duration' clearly states the action (trim) and resource (video) with a specific scope (to specified duration). It distinguishes from siblings like 'compress-video' or 'convert-video' by focusing on temporal editing rather than compression or format conversion. However, it doesn't explicitly mention the start time parameter, making it slightly less specific than a perfect 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/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 video file), exclusions (e.g., not for audio files), or comparisons to siblings like 'execute-ffmpeg' for more complex editing. The agent must infer usage from the tool name and parameters 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:

[![mcp-media-processor MCP server](https://glama.ai/mcp/servers/maoxiaoke/mcp-media-processor/badges/card.svg)](https://glama.ai/mcp/servers/maoxiaoke/mcp-media-processor)

Score Badge

Copy to your README.md:

[![mcp-media-processor MCP server](https://glama.ai/mcp/servers/maoxiaoke/mcp-media-processor/badges/score.svg)](https://glama.ai/mcp/servers/maoxiaoke/mcp-media-processor)

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/maoxiaoke/mcp-media-processor'

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