capcut-mcp

by JmsLdrn

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: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct function: listing, reading, cloning, adding different media types, manipulating segments (trim/move/split/delete), setting properties, validating, saving, and discarding. The add_* tools are distinguished by media type, and raw_patch is explicitly an advanced escape hatch.
Naming Consistency4/5
Most tools follow a 'capcut_verb_noun' pattern (e.g., list_drafts, add_video, delete_segment), but a few deviate: validate, save, and discard are bare verbs, and raw_patch is adjective_noun. The prefix is consistent, so the inconsistency is minor.
Tool Count5/5
17 tools is well-scoped for a video editing server, covering asset insertion, timeline manipulation, session management, and validation without feeling bloated. Each tool serves a necessary role in the editing workflow.
Completeness4/5
The surface covers the core lifecycle: reading, cloning, adding assets, editing segments, and saving/validating. Minor gaps exist (e.g., no direct draft deletion, no text content editing, no effect/transition tools), but raw_patch fills advanced needs, so agents can work around these.
Average 3.3/5 across 17 of 17 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says nothing about side effects, track creation defaults, or the meaning of key behaviors like what happens when trackIndex is omitted. The description is far too vague to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It lacks necessary detail and context, so the sentence does not 'earn its place' as a helpful descriptor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, no annotations), this description is grossly incomplete. It offers only a minimal statement, leaving the agent with insufficient information to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 36%, meaning most parameters are undocumented. The description itself does not explain any of the 14 parameters; it merely repeats the verb 'add'. It adds no semantic value beyond what the parameter names already imply.
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 a specific action ('Add') and resource ('an image') on a track, which distinguishes it from sibling tools like add_video or add_audio. However, it does not explicitly mention those siblings or elaborate on the 'at a time' nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, such as capcut_add_video or capcut_add_text. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Remove a segment' reveals no side effects, permanence, permissions, or potential for undo. It gives no more information than the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the text is extremely short, it is under-specified rather than concise. It omits essential behavioral context and parameter meaning, so the brevity results in a lack of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 must explain behavior, effects, and usage. A single phrase 'Remove a segment' is inadequate for an agent to understand the tool's function, risks, or integration with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what 'draft' or 'segmentId' represent or how they are used. The description completely fails to compensate for the missing schema parameter details.
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 a specific verb ('Remove') and resource ('a segment'), clearly indicating a deletion operation. It distinguishes from siblings like trim, split, and move, but adds no scope or context beyond the tool's name.
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 such as capcut_split_segment or capcut_move_segment. There are no context, prerequisites, or exclusions 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic operation ('Add an audio clip') and does not mention track selection behavior, whether new tracks are created, default insertion behavior, or any effects on existing timeline content.
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 front-loaded sentence with no filler, which is efficient. However, the phrase 'at a time' is ambiguous and the brevity comes at the cost of important context, so it is not an optimal example of concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, no annotations, and no output schema, this one-sentence description is severely incomplete. It fails to mention required inputs like draft, file, and atSec, or key behaviors such as track allocation and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 36% description coverage, and the tool description does not explain any of the 14 parameters or the 3 required ones. It adds no semantic value beyond the schema's own sparse descriptions of atSec, durSec, trackIndex, srcStartSec, and trackRenderIndex.
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 a specific action verb ('Add') and identifies the resource ('an audio clip'), which clearly separates it from sibling tools like capcut_add_video or capcut_add_image. It also hints at temporal/track placement with 'at a time on a track,' but the phrase is awkward and does not explicitly differentiate from other add tools beyond the media type.
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?
There is no explicit guidance on when to use this tool instead of capcut_add_video, capcut_add_image, or capcut_add_track. The intended usage is only implied by the name and the action phrase, so the tool lacks the explicit 'use when/when not' context that would help an agent choose correctly.
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?
There are no annotations to fall back on, and the description only states 'Add a new track' without disclosing behavioral details such as whether existing content is affected, what constitutes a valid track, or what the result of the operation looks like. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/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 enumerates the track types. However, it is too terse to fully inform the agent; brevity is achieved at the cost of essential details.
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 existence of sibling add_* tools, the description does not clarify the relationship or when to prefer this generic tool. With 3 parameters, no annotations, and no output schema, the description is too minimal to provide complete context 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?
The schema has 0% description coverage, so the description must compensate, but it only lists the type enum which already appears in the schema. It provides no explanation of the 'name' or 'draft' parameters, leaving their meaning and format unclear.
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 'Add' and the resource 'track', with an explicit list of allowed types (video, audio, text, sticker). However, it does not differentiate this tool from sibling tools like capcut_add_video, capcut_add_audio, etc., which likely create specific track types.
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 the more specific add_* sibling tools. It does not mention alternatives, exclusions, or typical 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, the description carries full responsibility for behavioral disclosure. It states the core behavior (splitting into two) but omits important details such as whether the draft is mutated immediately, any validation on atSec (e.g., must lie within segment duration), and what identifiers the resulting segments will have.
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 clearly front-loads the action and object. Every word contributes to meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, this brief description is inadequate for a mutating operation. It does not explain the workflow context (e.g., whether the draft must be saved via capcut_save after splitting), the constraint that atSec must fall within the segment's timeline range, or the resulting segment structure. An agent would struggle to use it correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at atSec via 'timeline time'. No guidance is provided for the draft or segmentId parameters, nor does it specify the unit or valid range for atSec. The parameter names alone are insufficient for correct invocation.
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 ('split') with a clear resource ('a segment') and a temporal parameter ('at a timeline time'). This distinguishes it from sibling tools like trim_segment (which alters boundaries) and delete_segment.
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 explicit guidance is provided about when to use split versus trim_segment or other editing operations. The description only states what the tool does, not when it should be preferred over alternatives.
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 burden of disclosing behavioral traits. It only states that properties are set, but omits details such as whether the operation is idempotent, requires an existing draft, or has side effects on other segment properties. The mutation implied by 'Set' is not elaborated.
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 that immediately states the verb and resource, with a concise list of affected properties. Every word contributes to the meaning, and it is well-front-loaded.
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 12 parameters, 2 required parameters, no output schema, no annotations, and 0% schema coverage, this description is far too sparse. It provides a high-level overview but omits essential information like parameter formats, defaults, and required couplings, making it insufficient 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 description coverage is 0%, so the description must compensate. It groups parameters into categories (transform, opacity, volume, speed, visibility), which helps map properties like posX/scale/rotation to 'transform'. However, it lacks units, allowed ranges, or relationships between parameters (e.g., scale vs scaleX/scaleY), leaving significant ambiguity.
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 action ('Set') and resource ('a segment'), and lists the property categories (transform, opacity, volume, speed, visibility). This distinguishes it from sibling tools like capcut_add_video or capcut_move_segment, making its purpose unambiguous.
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 given on when to use this tool versus alternatives (e.g., capcut_move_segment for position changes). The description does not mention prerequisites, exclusions, or recommended contexts, leaving the agent to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states what it checks but does not indicate whether the operation is read-only, what the return value looks like, or whether it modifies the draft. 'Check' implies non-destructive, but the absence of side-effect or outcome details leaves the agent uncertain.
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 tool's purpose and enumerates the validation checks without redundant words. Every element earns 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?
With no annotations and no output schema, the description should explain what the tool returns or how to interpret validation results. It does not, and it also lacks usage context. The simple single-parameter tool is underspecified for an agent to fully understand the tool's role in a workflow.
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 provides only a required string parameter 'draft' with 0% description coverage. The description clarifies that the draft is 'in-session', which adds some meaning. However, it does not explain the expected format (e.g., JSON string, ID) or how the parameter relates to the in-session state, so compensation is partial.
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 ('Check') and identifies the resource ('draft') plus the exact validation criteria (overlaps, duplicate ids/render_index, missing media). It clearly distinguishes this from sibling tools like capcut_read_timeline or capcut_set_props by focusing on validation rather than reading or editing.
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 gives no guidance on when to use this tool versus siblings (e.g., before saving, after edits) and does not mention any alternatives or exclusions. It only implies 'use to validate the draft' but provides no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral risks. It warns 'Use with care' and notes the operations are 'undocumented,' which signals instability, but it does not explain potential side effects, destructiveness, or how deep-merging affects existing draft_content.
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 short sentences, front-loaded with the key concept 'Advanced escape hatch' and immediately stating the action and risk. Every word earns its place with no filler.
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 raw, undocumented mutation tool with no output schema and sparse parameter explanations, the description is too thin. It lacks return/error behavior, what 'draft' refers to, and sufficient context for an agent to safely construct a correct call.
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 description coverage is 0%, so the description must compensate. It clarifies that 'patch' is a JSON patch used for deep-merging, but leaves 'draft' ambiguous (whether it is an ID, path, or serialized content) and provides no details on patch structure beyond the sparse 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 an action ('deep-merge') and a target ('draft_content'), and it differentiates the tool from its siblings by labeling it an 'Advanced escape hatch' with 'undocumented ops.' This is specific and distinguishes it from the higher-level, documented sibling tools.
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 phrase 'Advanced escape hatch' implies use for undocumented operations not covered by the normal sibling tools, and 'Use with care' cautions against casual use. However, it does not explicitly state when to use this tool versus alternatives, nor does it name any alternative tools.
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 must disclose behavioral traits, but it only mentions the prerequisite for a text template. It fails to state that this operation mutates the draft, whether it requires explicit saving via capcut_save, or what happens if the draft lacks a text layer.
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 two sentences and front-loads the purpose, with no filler. It efficiently communicates the core action and a key prerequisite, though at the cost of omitting many details.
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 9 parameters, no annotations, and no output schema, this minimal description is insufficient. It lacks parameter semantics, side effects, prerequisites beyond the template, and usage conditions, making it inadequate 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 description coverage is only 11% (only 'color' has a description). The description adds one semantic clue: the draft must be a text template. However, it does not explain the meaning of text, atSec, posX, posY, durSec, fontSize, trackIndex, or the relationship between these parameters and the overlay behavior.
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 'Add a text overlay' with a specific verb and resource, distinguishing it from sibling tools like add_video and add_image. The additional note about requiring a text template reinforces the tool's specific scope.
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: it is for adding a text overlay and requires a text template (a draft with a text layer), referencing CAPCUT_TEMPLATE_DRAFT. However, it does not explicitly mention when not to use the tool or name alternatives, so it stops short of a 5.
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 move action without mentioning preconditions (e.g., open draft), side effects on the timeline (e.g., overlapping segments), persistence, or return values. This leaves critical behavioral traits undisclosed for a mutation 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 wasted words. It succinctly conveys the operation's core without redundancy, achieving high conciseness and appropriate structure.
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 absence of an output schema and annotations, the description should provide more context about the operation's effects, return value, and prerequisites. It only describes the basic action, leaving the agent unaware of potential side effects, persistence behavior, or expected outcomes, making it incomplete for a mutation 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?
Schema description coverage is 0%, so the description must compensate. It does add meaning for atSec ('new start time') and trackIndex ('another track'), but it does not explain the draft or segmentId identifiers, nor specify units (e.g., seconds) or indexing. The compensation is partial; some parameters remain semantically under-specified.
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 identifies the action ('Move') and the resource ('a segment'), while specifying the key aspects: a new start time and optionally another track. This distinguishes it from sibling tools like trim_segment (changes duration), delete_segment (removes), and set_props (modifies 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 repositioning segments but does not explicitly contrast with alternatives or provide exclusion criteria. It lacks guidance like 'use this when you need to change a segment's position instead of trimming or deleting.' The context is clear but not explicitly scoped relative to other tools.
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 a mutation ('change') but does not disclose side effects on the timeline, whether changes are reversible, any constraints on combined parameters, or required permissions. The lack of detail on what happens when multiple timing fields are set together is a notable gap for an editing 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 sentence that is front-loaded and free of filler. It conveys the core action and scope in just a few words, earning top marks for conciseness and structure.
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, no annotations, no output schema, and zero schema descriptions, the description is far from complete. It does not explain the full parameter set, side effects, or usage context relative to sibling tools. The description is too thin to support correct selection and invocation for an agent in all but the most obvious cases.
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 description coverage is 0%, so the description must explain all parameters. It maps 'start', 'duration', and 'source in-point' to atSec, durSec, and srcStartSec respectively, but it does not describe the required parameters 'draft' and 'segmentId' at all. It also lacks detail on units or interactions between parameters, leaving the agent with incomplete guidance for invoking the tool correctly.
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: 'Change a segment start / duration / source in-point (seconds).' It identifies the specific resource (segment) and the exact attributes being modified, distinguishing it from siblings like move_segment, split_segment, and delete_segment. The verb 'change' and the focused timing attributes leave no ambiguity about the tool's 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?
The description implies the use case: adjusting a segment's timing properties. It gives clear context for when to use this tool (when you need to modify start time, duration, or source in-point) but does not explicitly exclude alternatives or mention when not to use it. Since no explicit exclusions or alternative tool names are provided, it earns a 4 rather than a 5.
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 provided, the description carries the burden of behavior disclosure. It reveals the crucial non-persistent session edit behavior, which is valuable. But it omits other side effects, such as whether existing clips are replaced or how the new clip interacts with the timeline's current content.
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: the first states the core purpose, the second provides the essential persistence caveat. Every word earns its place, with no filler or redundancy.
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 14 parameters, no output schema, and no annotations, the description is too thin. It omits important context such as expected return values, how the clip behaves relative to existing timeline segments, and the meaning of the many optional transform properties. The session/save note is helpful but insufficient for complete guidance.
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 description coverage is only 36%, and the description adds no parameter information. Many parameters like file, posX, scale, speed, volume, opacity, rotation, draft, and trackRenderIndex have no guidance in either the schema or the description, leaving the agent to guess their meaning.
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 adds a video clip to a track, using a specific verb and resource. It also differentiates from sibling tools like capcut_add_image, capcut_add_audio, and capcut_add_track by specifying 'video clip' and 'on a track'.
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 provides workflow context by noting this is a session edit and to call capcut_save to persist. However, it does not explicitly state when to use this tool versus alternatives like capcut_add_image or capcut_add_audio, nor does it mention any exclusions or prerequisites.
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 provided, the description carries the burden of behavioral disclosure. It adds valuable context by explaining that 'empty:true clears all clips/tracks for a fresh build', which goes beyond the tool name. However, it does not disclose potential overwrite behavior, error conditions, or permission requirements, but the core behavior is reasonably transparent.
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 with no wasted words. The main action is front-loaded, and the second sentence explains a critical flag. Every part 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 has no output schema, so the description should indicate what the tool returns or any side effects. It does not. It also omits details about existing destination folders or error handling. For a simple clone tool this may be sufficient, but there are clear gaps given missing return-value 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 0%, so the description must compensate. It provides meaning for the 'empty' parameter ('clears all clips/tracks') but does not elaborate on 'base' or 'newName' beyond their self-explanatory names. This partial compensation is adequate for a simple clone operation but leaves some semantic gaps.
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 action: 'Copy a draft folder to a new name'. This is a specific verb+resource combination that distinguishes it from siblings like capcut_list_drafts, capcut_read_timeline, and capcut_trim_segment. The mention of 'valid scaffolding' and 'fresh build' adds context for its intended use.
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 gives some usage context ('valid scaffolding', 'fresh build') but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It implies usage for creating a new draft from an existing one, but no direct comparison to sibling tools is provided.
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 full burden. It explicitly states 'Read-only,' a key behavioral trait for safety, and enumerates the returned data (canvas, fps, tracks, segment details). It does not mention error conditions or permissions, but for a read tool this is substantial.
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?
A single, tightly packed sentence that conveys the tool's purpose, scope, and read-only safety guarantee. Every word earns its place, with no filler or redundant repetition of the tool name.
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 read tool with no output schema, the description adequately lists the major return components (canvas, fps, tracks, segments with their fields). It is missing edge-case behavior like draft-not-found errors or authentication requirements, but the core functionality is clearly covered.
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?
The schema has one 'draft' string parameter with no description (0% coverage). The description only says 'Read a draft,' which minimally implies that the parameter is the draft to read, but it does not clarify whether it expects an ID, path, or name, nor provide any format or example.
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 'Read' with a defined resource ('a draft') and enumerates the scope (canvas, fps, tracks, segments). This clearly distinguishes it from sibling tools like capcut_list_drafts, which lists drafts rather than reading a single draft's full timeline.
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 usage is implied by the read-only nature and the explicit content scope, but there is no direct guidance on when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. It does not contrast with capcut_list_drafts or other sibling tools.
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?
Without annotations, the description must disclose behavioral traits. The verb 'List' implies a read-only operation, and the mention of 'duration and lock status' clarifies the return information. The specific path also removes ambiguity about the data source, though it does not explicitly state that no modifications occur or discuss 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 of about 15 words, starting with the verb 'List' and immediately naming the resource. It avoids unnecessary details, making it concise and well-structured.
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 zero-parameter list tool without an output schema, the description covers the essential aspects: action, location, and output fields. It does not explicitly state that returned draft identifiers can be used with sibling tools like capcut_read_timeline, but this is implied. The description is largely complete, with minor room for contextual linkage.
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 input schema has no parameters, so the description is not required to explain parameter syntax. The description instead provides the fixed location of the drafts, which is useful context beyond the empty schema. Baseline 4 is appropriate for zero-parameter tools.
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 the tool 'List CapCut drafts' with a specific path and identifies the output fields (duration and lock status). This clearly distinguishes it from sibling tools like capcut_read_timeline or capcut_clone_draft, which operate on individual drafts rather than listing 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that listing drafts is a prerequisite for selecting a draft to operate on with sibling tools, nor does it indicate any exclusions or special conditions.
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 provided, the description carries the full burden. It explicitly states that unsaved session edits are dropped and the draft is reloaded from disk, conveying the destructive nature toward unsaved changes. It could mention irreversibility, but the core behavior is transparent.
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 lead with the action verb and contain no filler. Every word contributes to the meaning.
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 tool with one parameter and no output schema, the description covers the essential behavior and context. It does not describe return values, but that is not required without an output schema. The main gap is the param meaning, already penalized.
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 0% and the description does not explicitly explain the 'draft' parameter beyond referring to 'the draft.' It implies the parameter identifies which draft to reload but does not specify it as an ID, name, or path. The description only partially compensates for the missing schema documentation.
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 ('Drop') and identifies the resource ('unsaved session edits') with a clear outcome ('reload the draft from disk'). It clearly distinguishes this from sibling tools like capcut_save and capcut_read_timeline.
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 the use case: when you want to abandon unsaved modifications and return to the last saved state. It does not explicitly name alternatives or exclusions, but the context is clear enough given the sibling tool set.
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 full burden and does a good job: it discloses side effects (.mcpbak backup), a validation step, and a refusal condition with an escape hatch (force:true). It does not describe failure behavior or overwrite semantics, but the disclosed traits are meaningful and non-obvious.
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 sentences with no waste. The primary action is front-loaded, and the secondary details (backup, validation, refusal) are packed into a parenthetical and a short second sentence, each earning its place.
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 tool's moderate complexity (2 params, no output schema, no annotations), the description covers the core behavior well. The missing piece is the meaning of 'draft' and what happens when validation fails, which would be useful without an output schema to fill those 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?
Schema description coverage is 0%, so the description must compensate. It explains 'force' by tying it to the refusal condition, but 'draft' remains ambiguous—it could be content or an identifier. Partial compensation yields a middle score.
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 has a specific verb+resource ('Write session edits to disk') and clearly differentiates from sibling editing tools by focusing on persistence. The parenthetical details (backup, validation) and the CapCut-open guard further distinguish its 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?
The description clearly implies when to use it (after editing, to persist) and includes a conditional guard (refuses if CapCut is open unless force:true). However, it does not explicitly name alternatives or state when not to use it, so it stops short of full explicit 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:

[![capcut-mcp MCP server](https://glama.ai/mcp/servers/JmsLdrn/capcut-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JmsLdrn/capcut-mcp)

Score Badge

Copy to your README.md:

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

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