Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@capcut-mcp what CapCut projects do I have?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that reads — and builds — CapCut projects on your own machine.
Point Claude at it and ask in plain language: what's in my CapCut projects, is any media missing, make me a 15 second vertical edit of this video cut on the beat. It works on the local draft library CapCut already keeps on disk.
This is extremely experimental and is not guaranteed to work.
CapCut's draft format is undocumented, changes with the app, and differs between platforms and versions. Everything here was worked out by reading drafts CapCut wrote on one Windows install. A project this generates may fail to open, may open with pieces missing, or may look fine and behave oddly.
Open anything it creates in CapCut and check it before you build on it. Nothing here has been tested against CapCut itself — only against the file format. Treat generated projects as drafts to inspect, not as finished work.
It will not touch projects you already have (see Safety), so the realistic worst case is a project that does not open. But back up work you care about anyway.
Tool | Purpose |
| Every project, newest first — duration, resolution, fps, track count |
| One timeline: each track, each segment, its start, length, speed and material |
| Source files a project needs, their size, and whether they still exist |
| Build a new project from clips laid end to end, each optionally trimmed |
| Tempo and beat times of any file with audio |
| Build a new project whose cuts land on the beat |
Times are in seconds throughout. CapCut stores microseconds internally; the conversion happens in one place so nothing downstream has to think about it.
Related MCP server: capcut-mcp
Requires Node 18+, CapCut installed, and ffmpeg/ffprobe on PATH
(used to measure media and to decode audio for beat detection).
git clone https://github.com/<you>/capcut-mcp
cd capcut-mcp
npm installRegister it with Claude Code:
claude mcp add capcut --scope user -- node /absolute/path/to/capcut-mcp/src/index.js--scope user makes it available in every session. Check it came up:
claude mcp list # capcut: ... - ✔ ConnectedAny MCP client works; the server speaks stdio and nothing else.
what CapCut projects do I have?
0625 158.8s 1920x1080 2 tracks
0624 (1) 115.3s 1920x1372 1 track
0720 3.4s 1920x1098 1 trackis any of my footage missing?
0720 -> imsobored.mp4 MISSINGA draft stores absolute paths, so moving or deleting a source leaves the edit pointing at nothing and CapCut says so only when you open the project.
make a 16 second vertical edit of that music video, cut on the beat
project lil-tecca-beat
duration 15.836s across 11 cuts
bpm 166.7 (cut every 4 beats = 1.44s)
canvas 1080x1920Decode to mono PCM with ffmpeg, measure how much energy rises between short windows, and treat peaks in that rise as onsets. Then find the tempo by autocorrelation — which beat spacing do the onsets agree with most — and lay a regular grid at that spacing, slid to whichever phase collects the most onset energy.
The grid matters more than the raw onsets. Onsets are uneven: they fire on a vocal, miss a soft kick, double up on a fill. Cutting straight to them looks jittery. A grid locked to the tempo lands musically.
Cut lengths come from the grid; cut contents are sampled evenly across the source, so a short edit surveys the whole video instead of its opening.
Tempo estimation is octave-ambiguous — a 83 BPM track often reads as 166 BPM.
It rarely matters for editing, since both give cuts on real beats, but it is why
everyNthBeat is the dial to reach for if cuts feel twice as fast as expected.
A segment does not merely point at its clip. It also carries
extra_material_refs — seven linked materials (speed, canvas, sound channel
mapping, vocal separation, animation, placeholder, colour) that must each exist
in the pool with matching ids. Synthesising all of that from nothing is how you
get a draft that opens to an error instead of a timeline.
So the server clones one of your existing projects as a structural template and rewrites only what describes the media and the timing. Every undocumented field is carried across verbatim from a draft CapCut itself wrote. Each segment gets its own copies of the seven linked materials, so two clips never share a speed object and move together when one is changed.
This is also why you need at least one real project before creating anything — there has to be something to copy the shape from.
canvas takes a preset (tiktok, reels, shorts, square, youtube) or
{width, height}. Clips are scaled to cover the frame rather than fit inside
it — left alone, 16:9 footage in a 9:16 canvas sits as a small strip between
black bars. 1920x1080 into 1080x1920 lands at scale ≈3.16, keeping the middle
third of the width.
The crop is centre-locked. If your subject sits off to one side, that shot loses
them; clip.transform in the draft is the lever, and it is not exposed yet.
Only ever creates new project folders. Nothing modifies an existing project. Tests assert the template project is byte-identical afterwards.
Refuses to overwrite. A name that already exists is an error, not a merge.
Refuses while CapCut is running, because the app holds its open draft in memory and writes it back on exit, which would silently discard new work.
Project names are validated before touching disk — anything containing
/, \ or .. is rejected, so a bad argument cannot read outside the draft
root.
Trims that would leave nothing are rejected with the clip's real length.
%LOCALAPPDATA%\CapCut\User Data\Projects\com.lveditor.draft\<project>\
draft_content.json the timeline: tracks -> segments -> material ids
draft_meta_info.json display name and imported media paths
draft_cover.jpg thumbnailOverride with CAPCUT_DRAFT_ROOT if CapCut lives somewhere else. Only Windows
paths are wired up by default; macOS keeps drafts under
~/Movies/CapCut/User Data/Projects/com.lveditor.draft, which should work by
setting that variable, though it is untested.
Never verified against CapCut itself. The structure is checked thoroughly — every material reference resolves, ids are unique across segments, timings are contiguous, the timeline duration equals the sum of its segments — but "well-formed" and "the app accepts it" are different claims and only the first is tested.
One video track. No audio tracks, text, transitions, effects or keyframes.
No transitions between cuts, so a beat edit is hard cuts only.
Centre crop only.
Reads and writes video materials; other material types are passed through from the template untouched.
MIT.
Build a new project whose cuts land on the beat. Cut lengths come from the detected tempo; the footage for each cut is sampled evenly across the source, so a short edit surveys the whole video rather than its opening. Same safety rules as capcut_create_project.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | ||
| name | Yes | Name for the new project. Must not already exist. | |
| clips | No | Optional pool of video files to rotate through, one per cut. | |
| canvas | No | Frame size: a preset (tiktok, reels, shorts, square, youtube) or {width, height}. Defaults to tiktok. | |
| source | Yes | File to take the beat from, and the footage unless `clips` is given. | |
| skipSeconds | No | Ignore this much of the intro when finding the tempo. | |
| everyNthBeat | No | Cut every N beats. Default 4. Lower is faster cutting. | |
| maxDurationSeconds | No | Stop once the edit reaches this long. Default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: cut lengths follow detected tempo, footage is sampled evenly (so short edits survey the whole video), and safety rules align with capcut_create_project. While it doesn't cover all failure modes or return values, these disclosed traits add meaningful context beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences: the first states the core purpose, the second provides a specific behavioral detail (even sampling) and a safety reference. No filler or redundant repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (8 parameters, 88% described) and the creation-oriented nature, the description covers the essential algorithm (beat-synced cuts, tempo-based lengths, even sampling) and safety alignment. It omits return values or failure behavior, but for a project-creation tool these are not critical, especially when sibling tools may document them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 88%, so parameters like everyNthBeat, skipSeconds, and maxDurationSeconds are already well documented. The description adds context about even sampling and tempo detection, which indirectly informs how `clips` and `source` are used, but it does not provide additional per-parameter meaning beyond the schema, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Build a new project whose cuts land on the beat' with specific details about tempo-derived cut lengths and even sampling across the source. This distinguishes it from sibling tools like capcut_create_project (non-beat-synced) and capcut_detect_beats (only detection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a beat-synced edit is wanted) and references 'Same safety rules as capcut_create_project' for behavioral consistency. However, it does not explicitly state when not to use it or name alternative tools for non-beat edits, missing the 'when-not' and 'alternatives' criteria for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a new CapCut project from video files, laid end to end on one track, each optionally trimmed. Creates a new project only — it never modifies an existing one, and refuses if a project of that name is already there. CapCut must be closed. Open the result in CapCut to confirm it loads.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | Frame rate. Defaults to the template project's. | |
| name | Yes | Name for the new project. Must not already exist. | |
| clips | Yes | Clips in order, laid end to end from time zero. | |
| canvas | No | Frame size. A preset name (tiktok, reels, shorts, square, youtube) or {width, height}. Defaults to the first clip's size. Clips are scaled to cover the frame rather than letterboxed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It explicitly reveals non-obvious traits: only creates, never modifies, refuses duplicates, and requires CapCut to be closed. These are critical safety details the schema cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with a clear opening statement and two sentences of critical constraints. Every sentence adds value—no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's effect (create), constraints (duplicate refusal, CapCut closed), and parameter behavior (trimming, canvas scaling). Even without an output schema, it provides enough context for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 4 parameters at 100% coverage, but the description adds meaningful semantics: clips are 'laid end to end on one track', 'each optionally trimmed', and canvas scaling states 'Clips are scaled to cover the frame rather than letterboxed.' This goes beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Build a new CapCut project from video files', a specific verb+resource+layout. It clearly distinguishes itself from siblings like create_beat_edit, list_projects, and read_project by focusing on creation from raw clips and explicitly stating it never modifies existing projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the primary use case and gives a clear exclusion: 'never modifies an existing one, and refuses if a project of that name is already there.' It also provides the prerequisite 'CapCut must be closed' and a suggested follow-up step. While it doesn't explicitly name sibling tools as alternatives, the context is sufficient for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the tempo and beat times of any file with audio. Returns BPM, the spacing between beats, and every beat in seconds. Useful on its own for deciding how long cuts should be.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to a video or audio file. | |
| skipSeconds | No | Ignore this much from the start, so a slow intro does not drag the tempo estimate down. |
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 discloses the output behavior (BPM, beat spacing, beat times in seconds) and implies read-only operation through the verb 'Find'. It does not explicitly state that files are not modified, but the descriptive output is adequate for a simple detection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the action and output front-loaded. Every sentence contributes: what the tool does, what it returns, and when it is useful. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the lack of an output schema and annotations, the description covers the main behavioral contract: inputs are audio-bearing files, outputs are tempo-related metrics. It does not discuss edge cases (e.g., silent files) or usage of the skipSeconds parameter, but the schema fills the latter gap. Overall, it is sufficiently complete for a straightforward detection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for both parameters (path and skipSeconds), so the baseline is 3. The description adds no parameter-specific semantic meaning beyond what the schema already states, though it does reinforce that the tool works with audio content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' and names the resource clearly: tempo and beat times of audio files. It distinguishes itself well from sibling tools like capcut_create_beat_edit or capcut_list_projects by focusing on analysis rather than creation or management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case ('useful on its own for deciding how long cuts should be'), giving the agent context for when to invoke it. However, it does not explicitly mention when not to use it or point to an alternative like capcut_create_beat_edit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the CapCut projects in the local draft library, newest first, with duration, resolution and track count. Start here — every other tool takes a project name from this list.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses sort order (newest first), source (local draft library), and output fields (duration, resolution, track count), but doesn't explicitly state read-only nature or response format. Listing is inherently non-mutating, and the added behavioral details are useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loads the action and immediately adds workflow guidance, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is sufficient: it tells the user what data is returned, sorting, and its role in the workflow, including implicit project names via 'every other tool takes a project name from this list'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter-level meaning to add. Baseline for 0 params is 4, and there are no gaps to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists CapCut projects in the local draft library with specific output fields (duration, resolution, track count) and sort order (newest first). It distinguishes itself from siblings by positioning as the starting point for obtaining project names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Start here' and explains that all other tools take a project name from this list, providing clear when-to-use guidance and context about its role relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the source files a project references, with size, and whether each still exists on disk. Use this to find edits broken by moved or deleted media.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Folder name exactly as capcut_list_projects reports it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It openly states that it reports whether each file "still exists on disk," which is a useful behavioral detail beyond simple listing. It does not mention error cases or permissions, but as a read-only listing tool, the description is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the action and outputs front-loaded. Every word contributes meaning, and it avoids fluff, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter and no output schema, the description covers the essential context: what it lists, what it reports (size and existence), and a concrete use case. It could have mentioned what happens if the project does not exist, but overall it is sufficiently complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter 'project' has a clear description in the schema ("Folder name exactly as capcut_list_projects reports it"). The tool description itself adds no additional parameter guidance, so it meets the baseline for high schema coverage without added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb "List" and clearly identifies the resource: "source files a project references." It further specifies what is included (size, existence on disk), which distinguishes it from sibling tools like capcut_list_projects (which lists projects) and capcut_read_project (which reads project details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: "Use this to find edits broken by moved or deleted media." This tells the agent when and why to use the tool, though it does not explicitly mention alternative tools or when not to use it. This is slightly below the top score because no exclusions or alternative mentions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one project's timeline: every track, and every segment on it with its start time, duration, speed and the material it plays. Times are in seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Folder name exactly as capcut_list_projects reports it. |
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 explicitly frames the operation as 'Read', which implies read-only, and details the output fields and time unit. It does not cover error cases or permissions, but the core read behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two crisp sentences. The first sentence front-loads the purpose and enumerates the return content, and the second adds the unit. Every word earns its place with no redundancy or ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description gives a solid high-level picture of what is returned: tracks, segments with start time, duration, speed, and material. It lacks exact nesting details and error behavior, but the description is adequate for the agent's likely needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter 'project' has a highly descriptive schema comment: 'Folder name exactly as capcut_list_projects reports it.' The tool description adds no further parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read one project's timeline' with a specific verb and resource, then enumerates the exact content returned (tracks, segments, start time, duration, speed, material). This unambiguously differentiates it from siblings like capcut_list_projects and capcut_project_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case by detailing what it reads, but offers no explicit guidance on when to choose it over alternatives or any exclusions. Sibling tools are not referenced, so the agent must infer the appropriate context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0capcut_create_beat_editcapcut_create_projectcapcut_detect_beatscapcut_list_projectscapcut_project_mediacapcut_read_projectEach tool targets a distinct operation: detecting beats, creating beat-synced edits, creating general projects, listing/reading projects, and checking media files. Even the two creation tools are clearly differentiated by their specialized vs. general purpose.
Most tools follow a consistent 'capcut_<verb>_<noun>' pattern (detect_beats, create_project, list_projects, read_project). The exception is 'capcut_project_media', which uses a noun phrase rather than a verb-action form, making it a minor deviation in an otherwise consistent naming scheme.
With 6 tools, the server is tightly scoped for its purpose: analyzing audio, creating projects, and inspecting existing drafts. This is a reasonable size that covers the core workflows without unnecessary bloat.
The set covers project creation (general and beat-based), listing, reading timelines, and checking media integrity. Notable gaps include lack of project deletion, modification, or export/render, but these may be outside the server's intended scope, so the current surface is mostly complete for its niche.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
MCP server for ByteDance Seedance AI video generation
MCP server for generating rough-draft project plans from natural-language prompts.
MCP server for Google Veo AI video generation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dlyrr/capcut-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
