video-editor-mcp

by gxtontata

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
Disambiguation5/5
Each tool targets a distinct video/audio editing operation with clear separation: inspecting, extracting, trimming, merging, converting, resizing, cropping, rotating, speed/volume changes, frame grabbing, overlays, fades, compression, and GIF generation. Even overlapping pairs like convert_format vs compress_video or extract_frame vs generate_gif have well-defined differences in purpose and output.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase with underscores (get_media_info, extract_audio, trim_video, etc.). There are no mixed conventions, camelCase, or vague verbs, making the toolset highly predictable.
Tool Count4/5
With 16 tools, the set is slightly above the typical 3-15 sweet spot, but each tool serves a distinct common editing need. The count feels justified given the broad scope of video editing, though one or two could be consolidated (e.g., add_text_overlay and add_watermark are both overlays).
Completeness4/5
The toolset covers core video editing workflows: inspect, trim, merge, convert, transform (resize/crop/rotate), audio adjustment, frames, text/watermark overlays, fades, compression, and GIF export. Missing operations like video stabilization or color grading are minor gaps for a basic editor, and agents can accomplish most tasks without dead ends.
Average 3.6/5 across 16 of 16 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only mentions the basic overlay operation. It does not mention that it creates a new output file, any format requirements, or potential side effects, leaving the agent under-informed about the tool's impact.
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 clear sentence with no redundant words. It is efficiently structured and immediately conveys the core operation.
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 video processing and the absence of output schema and annotations, the description is too sparse. It lacks details on output behavior, supported formats, or any caveats, making it incomplete for an AI agent to fully understand the tool's implications.
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 coverage is 67%, and the description adds slight context by mentioning position ('corner or the center'), which aligns with the position enum. However, it does not explain other parameters like opacity or scale_width, so it only marginally supplements the schema.
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 ('Overlay') and resource ('logo/watermark image onto a video'), and specifies position options ('chosen corner or the center'). It distinguishes from sibling add_text_overlay by focusing on an image watermark, though it doesn't explicitly name the alternative.
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 add_text_overlay. The description simply states what it does without any context on suitable scenarios or exclusions.
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 only states the operation at a high level and omits details about whether the input file is overwritten, whether a new output file is created, whether re-encoding occurs, or constraints such as the crop region needing to be within the source bounds. This leaves the agent with insufficient information about side effects.
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, front-loaded sentence with no filler. It is appropriately concise and easy to parse, and every word contributes to the meaning. However, this conciseness sacrifices detail.
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 six parameters and no output schema or annotations, the one-sentence description is incomplete. It does not explain the relationship between x/y and width/height, behavior when the crop region extends beyond the source video, or the nature of the output file. Critical context is missing.
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 already documents all six parameters with descriptions and defaults (x and y default to 0). The description adds no additional semantic information about parameters beyond what the schema provides, so it receives the baseline score for full 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 uses the specific verb 'Crop' and identifies the resource 'video' and the result as 'a rectangular region.' This clearly distinguishes it from sibling operations like resize_video, which scales the entire frame, and trim_video, which selects a time range. However, it could be slightly more explicit that this selects a sub-region of the original rather than just any rectangle.
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 does not state, for example, that crop_video should be used to remove unwanted edges while resize_video should be used to change overall dimensions. There is no mention of prerequisites, typical use cases, or exclusions.
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, the description carries the full burden of behavioral disclosure. It only states the basic operation without mentioning side effects such as overwriting the output file, how zero durations are handled, or whether the source file is modified. Key behavior like the default fade duration of 0 (effectively disabling fades) is not disclosed.
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 concise sentence with no wasted words. It is front-loaded with the core action and targets. While it could be slightly more detailed to cover defaults, the brevity is acceptable for a simple tool and does not hinder clarity.
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 has 5 parameters (2 required), no output schema, and no annotations, the description is too thin. It does not explain the default behavior of fade_in_duration and fade_out_duration (both 0), the default target ('both'), or the resolution of relative paths beyond what the schema states. The description alone would leave an agent uncertain about how to prevent fades or which target is assumed.
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 (80%), so a baseline of 3 applies. The description adds little beyond the schema: it echoes 'video, audio, or both' which maps to the target enum, and 'fade-in and/or fade-out' maps to the duration parameters. No additional parameter meaning is provided beyond what the schema already contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and identifies the resource ('fade-in and/or fade-out') along with target options ('video, audio, or both'). This clearly distinguishes it from sibling tools like trim_video or extract_audio, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the operation, but it does not explicitly mention when to use this tool versus alternatives or provide exclusions. No sibling comparison or contextual guidance is given, so the agent must infer usage from the name and description.
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. It only states the conversion without disclosing details like output overwrite behavior, dependencies (e.g., ffmpeg), or how the segment is determined. The 'segment' reference is vague and relies on schema params (start_time, duration) that are not explained.
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 declarative sentence that is front-loaded and contains zero filler. It is appropriately sized and immediately conveys the core 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?
Given the tool has 6 parameters, no output schema, no annotations, and is one of many similar video tools, the description is unduly sparse. It fails to explain return values, parameter meanings, or typical usage scenarios, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only input_path and output_path have descriptions). The description adds minimal semantic value, mentioning 'segment' but not elaborating on start_time, duration, fps, or width. It does not compensate for the 4 undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Convert a segment of a video') and resource ('animated GIF'), distinguishing it from siblings like extract_frame (single frame) and trim_video (video output). It uses a verb+resource structure that is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage—when a GIF is needed from a video segment—but provides no explicit alternatives or exclusion criteria. It does not mention when to use this instead of convert_format or trim_video, leaving the agent to infer.
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 the operation, without revealing side effects (e.g., writes to output_path, whether input is preserved, codec/quality behavior, or any limitations). The description adds almost no context beyond the core action.
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 short sentence that front-loads the primary action. It is concise and every word contributes meaning, though it could be slightly more informative without losing conciseness. This is efficient but minimal.
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?
The tool has 4 parameters, no output schema, and no annotations. The description does not mention return values, file handling behavior, or any caveats. It is inadequate for an agent to fully understand the tool's behavior, especially given the lack of output schema and the presence of multiple sibling tools with overlapping scope.
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 50% (only input_path and output_path are described). The description gives a high-level mapping (rotate→rotation, flip→flip) but does not explain parameter semantics beyond what the enum values already show. It adds some value but does not fully compensate for the missing descriptions on rotation and flip.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rotate and/or flip) and the resource (video). This is a specific verb+resource that distinguishes it from sibling tools like crop_video, resize_video, and convert_format, each of which targets a different transformation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context—it is for rotating or flipping videos—but provides no explicit alternatives or when-not-to-use guidance. Since the tool's name and action are self-evident, the usage is implied rather than explicit.
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 does state the primary action and the mute option, which adds some transparency, but it does not mention side effects like re-encoding, overwriting, or whether the video track is preserved.
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, concise sentence that front-loads the action and includes the mute alternative. Every word earns its place with no redundancy.
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 simple nature of the tool and full schema coverage, the description is adequate but not rich. It lacks usage context, behavioral limitations, or output expectations, which would be valuable since there is no output schema or annotations.
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 coverage is 100%, so the baseline is 3. The description does not add parameter semantics beyond what the schema already provides, such as volume_factor behavior or mute ignoring volume_factor, but these are already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: changing the audio volume of a video, with an option to mute entirely. This specific verb+resource combination distinguishes it from sibling tools like extract_audio or convert_format.
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 about when to use this tool versus its siblings, nor any mention of alternatives or prerequisites. The description implies use for volume adjustment but does not offer any contextual direction.
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 the core action without mentioning input validation, file overwriting behavior, codec support, or any side effects.
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 sentence, immediately clear, and contains no redundant wording.
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?
The description is adequate for basic invocation but lacks context about return values, error cases, or format compatibility. Without annotations or an output schema, it leaves gaps for an agent fully understanding the tool's behavior.
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?
Both parameters are fully described in the schema with clear path resolution semantics. The tool description adds no additional meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'extract' with a clear resource 'audio track from a video file' and output 'MP3'. This clearly distinguishes it from sibling tools like extract_frame and convert_format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when audio needs to be extracted from a video, but provides no explicit guidance on when to use this over alternatives like convert_format. No exclusions or prerequisites are mentioned.
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. It states the side effect of saving an image, but does not disclose overwrite behavior, handling of invalid timestamps, or required permissions. This is minimal disclosure for a write operation.
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, clear sentence with no extraneous words. It front-loads the action and outcome.
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?
The tool is relatively simple, and the schema covers all parameters. However, with no annotations or output schema, the description should address edge cases like overwriting output or timestamp out-of-range, which it does not. It is minimally complete but leaves behavioral 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% coverage with descriptions for all three parameters (timestamp, input_path, output_path). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Grab' and clearly identifies the resource (a single still frame from a video) and the action (at a given timestamp, saved as an image). This distinguishes it from sibling tools like extract_audio or trim_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extracting still frames but does not explicitly compare to alternatives or state when not to use it. The context is clear but no exclusions are given.
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 does disclose two key behaviors: the text is 'burned' onto the video (irreversible) and can be time-limited. However, it does not mention permissions, whether the input file is modified, or the output format, which would be valuable.
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 action. No wasted words; every element (burn text, optional time range) adds value.
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 8 parameters, lack of output schema, and no annotations, the description is too sparse. It does not explain what the output is (e.g., the output_path), whether the original video is changed, or any prerequisites or side effects. The time-range functionality is mentioned but not expanded upon.
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 already covers 63% of parameters with descriptions (input/output paths, start/end times, font color). The tool description only reiterates the text and time range, adding no new parameter semantics. This is acceptable given the moderate schema coverage, but the description could have reinforced key parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Burn text') and the target resource ('onto a video'), with examples ('caption or title') that make the purpose unambiguous. It distinguishes itself from sibling tools like add_watermark by focusing specifically on text overlays.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through examples (caption/title) and the time-range option, but it does not explicitly state when to use this tool versus alternatives like add_watermark or add_fade. There are no exclusions or alternative names mentioned, so guidance is only implicit.
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. It discloses one behavioral trait: aspect ratio is preserved when only one dimension is given. However, it does not mention other potentially relevant behaviors like output overwrite semantics, format/codec implications, or what happens when both dimensions are provided (e.g., distortion). This is a notable gap given the lack of annotations.
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 two concise sentences, immediately stating the action ('Resize/scale a video') and adding one essential detail about aspect ratio. No redundant words or filler; it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple resize tool with no annotations and no output schema, the description covers the core function, parameter flexibility, and a key behavioral aspect. It lacks some finer details (e.g., effects of providing both dimensions, file handling), but given the tool's simplicity and the fact that output is implied by output_path, it is reasonably complete.
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 50%, with only input_path and output_path described. The description adds meaning by explaining that width and height can be provided individually or together and clarifies aspect ratio behavior. However, it does not explicitly state that width/height are optional (though inferred from the sentence) or define units. It partially compensates for the missing schema descriptions but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Resize/scale a video' with a specific verb and resource, clearly distinguishing it from siblings like crop_video or rotate_video. The mention of width/height and aspect ratio preservation adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for resizing/scaling but does not explicitly compare with alternatives or state when-not-to-use. The 'Provide width, height, or both' is more parameter guidance than contextual usage guidance, and no exclusions or sibling alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the key behavior of inferring output format from the output_path extension, which is valuable. However, it does not mention overwrite behavior, codec defaults, or whether input is modified, leaving some behavioral 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?
Two concise sentences front-load the main purpose and add one essential detail about extension inference. No filler or redundancy.
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?
For a simple two-parameter tool, the description covers the core purpose and format determination. However, it lacks explicit guidance on use cases, potential side effects (e.g., overwriting), and error handling, making it adequate but not comprehensive.
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?
Input schema fully documents both parameters with detailed descriptions of path resolution relative to MEDIA_DIR. Since coverage is 100%, the description adds minimal extra meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb+resource ('Convert a video/audio file to a different container/codec') and differentiates from sibling tools by focusing on format conversion rather than specific operations like trimming or extraction. The extension inference detail reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (converting file formats/containers), but does not explicitly name exclusions or alternatives. The use case is implied and distinct from siblings, though no explicit when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses the auto-scaling behavior to handle different resolutions and codecs, which is valuable context. However, it does not explain whether this involves re-encoding, potential quality loss, or other side effects that could affect the user's expectations.
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 two sentences, front-loaded with the primary action, and contains no redundant filler. Every word earns its place.
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?
The tool is relatively simple and the schema covers both parameters well, but with no output schema and no annotations, the description could be more complete by mentioning the output format or any limitations. It covers the core behavior but leaves some contextual 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 already provides thorough descriptions for both parameters, including relative/absolute path resolution and ordering. The description adds no parameter-specific meaning beyond what the schema covers, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool concatenates two or more video files into one in a given order, using the specific verb 'concatenate'. This distinguishes it from sibling tools that trim, convert, resize, or otherwise manipulate single videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for joining videos in a specified order, but it does not explicitly mention alternatives or exclusions. The usage is obvious from the purpose, but there is no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It accurately describes the core trimming action but does not mention practical details like whether the source is preserved, what happens if the output exists, or edge cases such as invalid time ranges.
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, front-loaded sentence that directly states the operation with no unnecessary words. Every part contributes to understanding the tool's purpose.
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?
For a 5-parameter tool with no output schema, the description covers the core purpose but leaves gaps such as return value, error behavior, and output format expectations. It is adequate but not fully comprehensive for an agent relying solely on this description.
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% (all five parameters are described in the schema). The description adds the relational meaning between start_time, end_time, and duration, but this is only a minor enhancement over the schema, which already notes mutual exclusivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Cut' and identifies the resource as 'a video', clearly defining the operation as extracting a clip between a start time and an end or duration. This distinguishes it from spatial editing tools like crop_video and from extract_frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (trimming videos by time range) but does not explicitly name alternatives or state when not to use it. The context is sufficient for an agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the quality/size tradeoff via CRF, which is useful, but it does not disclose potential side effects like overwriting the output path, the lossy nature of re-encoding, or processing time. This is adequate but not thorough.
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 three sentences, front-loaded with the core purpose, and wastes no words. Every sentence contributes either to what the tool does or how to use a key parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with no output schema and no annotations, the description covers the main purpose and parameter semantics well. It lacks caveats about overwriting or lossy encoding, but given the tool's straightforward nature and schema for paths, it is reasonably complete.
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?
Schema descriptions cover input_path and output_path (50% coverage). The description adds meaningful semantics for crf, which lacks a schema description, by explaining the quality/size relationship and suggesting a default. It does not elaborate on preset, but the enum values are self-explanatory. The added value on crf compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Reduce a video file size by re-encoding it with a given quality level (CRF).' It identifies a specific verb, resource, and method, and distinguishes itself from sibling tools like resize_video or convert_format by focusing on quality-based compression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when the tool might be used (to reduce file size) and provides CRF value guidance, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. It gives implied usage context but lacks clear 'use this instead of X' guidance found in higher-scoring examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the responsibility to disclose behavioral traits. It does so by noting that 'audio pitch is preserved' and explaining speed_factor semantics with examples. However, it does not mention output file handling (e.g., overwriting) or potential side effects, leaving some room for added detail.
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, containing only two sentences. It is front-loaded with the main action and immediately provides the key parameter guidance, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema, and the description sufficiently covers its core functionality and parameter semantics. It does not explain return values, but for a file-processing tool this is often unnecessary. The input/output paths are fully described in the schema, so the description is complete enough for effective use.
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 description adds crucial meaning to the speed_factor parameter, which lacks a schema description: 'speed_factor > 1 speeds up, < 1 slows down (e.g. 2 = 2x faster, 0.5 = half speed).' This compensates for the missing schema coverage for that parameter, while input_path and output_path are adequately described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Speed up or slow down a video.' This is a specific verb+resource pair that distinguishes it from sibling tools like trim_video or adjust_volume, which address different video properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for changing playback speed but provides no explicit 'when to use' or exclusions. It does not mention alternative tools or cases where this tool should not be used, such as when only trimming duration is needed. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'Inspect' clearly signals a non-destructive, read-only operation, and the property list sets expectations for the return content. It does not discuss failure modes or unsupported formats, but the essential safety profile is communicated.
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 compact sentence with a clear verb and a comma-separated list of returned properties. Every word earns its place, and it is appropriately front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one well-documented parameter, no output schema), the description adequately conveys function and return value expectations. Minor gaps include lack of output format details and handling of unsupported file types, but these are not critical for an inspection tool.
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 single parameter has 100% schema description coverage, including path resolution semantics. The tool description adds no extra parameter-level meaning beyond the overall purpose, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Inspect' as a specific verb, identifies the resource as 'a video or audio file', and enumerates the exact metadata returned (duration, resolution, codecs, fps, bitrate, file size). This clearly distinguishes it from the sibling tools, which are all media transformation operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need media metadata rather than modification, and the sibling tool names make the alternative operations obvious. However, it does not explicitly state 'use this when...' or name specific exclusions, so it stops short of full guidance.
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-editor-mcp MCP server](https://glama.ai/mcp/servers/gxtontata/video-editor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gxtontata/video-editor-mcp)

Score Badge

Copy to your README.md:

[![video-editor-mcp MCP server](https://glama.ai/mcp/servers/gxtontata/video-editor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gxtontata/video-editor-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/gxtontata/video-editor-mcp'

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