Raskadr is a read-only CapCut MCP server for discovering, inspecting, validating, and dry-run planning video edits without modifying projects.
Check Raskadr health and CapCut draft store discovery (raskadr_health)
List local CapCut projects and basic metadata (raskadr_list_projects)
Inspect tracks, segment IDs, canvas, FPS, and timing for a project (raskadr_inspect_project)
Run read-only compatibility, storage, editor-process, and timeline integrity checks (raskadr_check_compatibility)
Create validated dry-run edit plans for split, trim, move, and delete operations with before/after previews (raskadr_plan_edit)
All tools are non-mutating in this version: nothing writes to real CapCut projects
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., "@Raskadr inspect the timeline of my most recent CapCut project"
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.
Raskadr is an independent, open-source CapCut MCP server for safe AI-assisted video editing. It lets Model Context Protocol (MCP) clients inspect local CapCut desktop projects and create validated, reviewable edit plans while keeping the timeline editable in CapCut.
Current status — v0.1.0: the public MCP tools are non-mutating. Raskadr can discover, inspect, validate, and dry-run timeline edits. Writing to a real CapCut project remains disabled until the safety gates are proven against a wider compatibility fixture set.
Related MCP server: Mendix Context Bridge
Raskadr connects AI agents to editable CapCut desktop drafts through MCP. Instead of treating video editing as an opaque render-only task, it works with timeline structure: projects, tracks, clips, source ranges, frame rates, and edit operations.
The long-term goal is an AI video editing workflow that can analyze source footage, remove pauses and failed takes, choose strong fragments, synchronize cuts with music, generate captions, add B-roll and motion, balance audio, review a preview, and save the result as an editable CapCut project.
Raskadr is not affiliated with ByteDance or CapCut.
Editable output: the target is a normal CapCut project, not only a flattened video render.
Review before write: edits are represented as versioned plans with before/after timeline summaries.
Safety first: project confinement, compatibility checks, fingerprints, isolated copies, validation, backup, and exact rollback are built into the editing path.
Agent-friendly interface: MCP tools expose structured project information and operations to compatible AI clients.
Clean architecture: domain rules, application workflows, CapCut adapters, safety infrastructure, and the MCP boundary remain separate and independently testable.
High-level direction: Raskadr is designed to grow beyond raw timeline commands into repeatable editing workflows and automated quality checks.
Raskadr uses capcut-cli as a confined low-level adapter. Raskadr adds the MCP interface, edit-plan lifecycle, project safety boundaries, transaction checks, and future AI editing workflows around that engine.
Raskadr 0.1.0 currently supports:
automatic discovery of the local CapCut desktop draft store;
listing CapCut projects and basic metadata;
inspecting tracks, segments, canvas settings, FPS, and timing;
read-only version, storage, editor-process, and structural lint checks;
versioned dry-run plans for split, trim, move, and delete;
stale-plan and concurrent-project-change detection;
frame-aware timeline invariants and overlap prevention;
isolated write verification against a copied project;
atomic save, post-write validation, snapshot restoration, and exact rollback verification.
No public MCP tool writes to the user's real CapCut drafts in this release.
Tool | Purpose | Writes to project |
| Verify that Raskadr can locate the CapCut draft store | No |
| List local CapCut projects and basic metadata | No |
| Inspect tracks, segment IDs, canvas, FPS, and timing | No |
| Check version support, storage layout, running editor processes, and lint results | No |
| Validate and preview | No |
Node.js 20 or newer;
npm;
CapCut desktop with local project drafts;
an MCP-compatible client.
git clone https://github.com/n1ghtmare-dev/raskadr-capcut-mcp.git
cd raskadr-capcut-mcp
npm ci
npm run checkStart the MCP server over stdio:
node dist/index.jsAdd Raskadr as a stdio server in an MCP-compatible client's configuration. Replace the example path with the absolute path to your clone:
{
"mcpServers": {
"raskadr": {
"command": "node",
"args": [
"/absolute/path/to/raskadr-capcut-mcp/dist/index.js"
]
}
}
}Raskadr discovers the standard CapCut draft location automatically. To use a custom directory, pass an environment variable through the MCP configuration:
{
"mcpServers": {
"raskadr": {
"command": "node",
"args": [
"/absolute/path/to/raskadr-capcut-mcp/dist/index.js"
],
"env": {
"RASKADR_CAPCUT_DRAFTS_DIR": "/absolute/path/to/com.lveditor.draft"
}
}
}
}Once the server is connected, an MCP client can use requests such as:
List my local CapCut projects.Inspect the tracks and clip timings in the project named "Product demo".Check whether "Product demo" is safe and compatible for editing.Create a dry-run plan that splits segment "segment-1" at 12.5 seconds,
moves "segment-2" to 18 seconds, and show the before/after timeline.The MCP client should call raskadr_list_projects and raskadr_inspect_project first to obtain exact project and segment identifiers.
CapCut draft formats are version-sensitive, and a project that successfully saves can still be structurally damaged. Raskadr therefore fails closed when safety evidence is missing or inconsistent.
Implemented safeguards include:
project-root confinement and path traversal rejection;
symbolic-link refusal for projects, draft JSON, and isolated workspaces;
no-follow file access and concurrent-change detection;
bounded-memory fingerprints for large project trees;
strict runtime validation at the MCP and application boundaries;
project, fingerprint, FPS, operation-ID, and timing validation;
refusal while CapCut is running or compatibility checks fail;
isolated full-project copies and immutable snapshots;
free-disk-space checks before creating working copies;
atomic save and structural validation through the low-level adapter;
rollback verification and retention of recovery evidence when rollback cannot be proven;
transactional in-memory edits that leave the source object unchanged on failure.
Raskadr follows an inward dependency rule:
MCP boundary → CapCut adapters → application use cases → domain
↘ safety infrastructure ↗The domain and application layers do not depend on CapCut, MCP, Zod, the filesystem, or Node.js runtime APIs. See the architecture documentation for the complete edit-plan lifecycle and safety invariants.
Planned high-level AI video editing capabilities include:
media ingestion and reusable analysis caches;
transcription, silence, pause, filler-word, scene, and speaker detection;
automatic talking-head and short-form first cuts;
animated captions, B-roll, zooms, punch-ins, overlays, and reframing;
beat-synchronized cuts and voice/music balancing;
preview rendering and automated visual, timing, and audio QA;
constrained iterative improvement;
editable CapCut project delivery with an edit decision report.
See the detailed Raskadr roadmap.
Install dependencies and run every reliability gate:
npm ci
npm run checkRun the test suite with coverage:
npm run test:coverageRun the TypeScript MCP server during development:
npm run devThe project uses strict TypeScript settings, architecture boundary tests, MCP integration tests, filesystem safety tests, isolated write/rollback tests, and randomized frame-rate and clip-speed invariants. CI runs the full check on Node.js 20 and 22.
The current safety round-trip has been verified against a copied CapCut 6.7 desktop project on macOS.
Other CapCut versions and operating systems require additional compatibility fixtures.
split and trim reject clips with keyframes or attached materials that cannot yet be redistributed safely.
Deleting a segment does not yet garbage-collect shared materials.
Caption generation, media analysis, B-roll, beat detection, audio mixing, preview rendering, and real-project mutation are roadmap features, not 0.1.0 capabilities.
The source code is licensed under AGPL-3.0-only.
The Raskadr name and logos are not granted under the software license. See TRADEMARKS.md and NOTICE.
Raskadr is independent software and is not affiliated with, sponsored by, or endorsed by ByteDance or CapCut. CapCut is referenced only to describe software interoperability.
Run read-only version, storage, editor-process, and timeline integrity checks before any edit is planned.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Exact project folder name returned by raskadr_list_projects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It explicitly labels the operation as read-only, a key behavioral trait that signals no mutation. It also enumerates the categories of checks performed. It does not describe failure behavior or return format, but for a read-only validation tool this is acceptable.
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 entire description is one tight, front-loaded sentence. The read-only safety trait comes first, followed by the specific check categories and the timing constraint. 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?
For a tool with one parameter and no output schema, the description provides sufficient context to decide when and how to invoke it. The main omission is what the result of the checks looks like (pass/fail, report), but the core calling intent is clear.
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 description coverage is 100% and the single 'project' parameter is already well documented as an exact folder name returned by raskadr_list_projects. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline 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 uses a specific verb ('Run') and identifies a precise resource: read-only version, storage, editor-process, and timeline integrity checks. It clearly frames the tool as a pre-edit validation step, which distinguishes it from siblings like raskadr_health or raskadr_plan_edit without needing to inspect schemas.
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 explicitly states when to use the tool: 'before any edit is planned.' This gives clear contextual timing and implicitly positions it before raskadr_plan_edit. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether Raskadr can find the local CapCut draft store. This tool never writes files.
| 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 behavioral disclosure burden, and it satisfies the key concern by explicitly stating 'This tool never writes files.' It also frames the operation as a read-only check, though it does not describe output or error behavior.
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 short sentences deliver the purpose and the key safety trait with no filler. The main action is front-loaded in the first sentence.
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 zero-parameter diagnostic tool with existing sibling names, the definition states the target resource and the no-write guarantee. It leaves the exact return shape unspecified, but 'Check whether' sufficiently implies a boolean or status result for this simple case.
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 and the schema coverage is 100%, so there is nothing for the description to add. The baseline of 4 applies because no parameter semantics are needed.
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 ('Check') and resource ('local CapCut draft store'), and the safety guarantee distinguishes it from sibling tools that list, inspect, plan, or check compatibility. An agent can tell this is a diagnostic health check rather than a project operation.
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 phrasing implies this should be used to verify Raskadr can locate the draft store before other workflows, and 'never writes files' suggests it is safe to run. However, it does not explicitly name alternatives or state when not to use it, leaving usage comparison to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect tracks, segment ids, and timing for one CapCut project without writing files.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Exact project folder name returned by raskadr_list_projects |
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 explicitly states 'without writing files', which signals a read-only operation and the absence of side effects. However, it does not describe the return format, error handling, or prerequisites beyond having the project name, which is a minor gap for an inspection 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 a single, front-loaded sentence with no fluff. It immediately states what the tool inspects and its read-only nature. Every word earns its place, making it highly efficient for agent consumption.
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 one-parameter read-only tool, the description is largely complete: it states the purpose, the resource, and the key safety trait. Minor omissions—such as expected return structure or behavior when the project doesn't exist—are not critical for an inspect operation, but the lack of explicit sibling differentiation slightly reduces completeness.
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 description coverage is 100%—the single parameter 'project' has a clear description ('Exact project folder name returned by raskadr_list_projects'). The tool description does not add significant meaning beyond what the schema already provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Inspect' and the exact resource ('tracks, segment ids, and timing for one CapCut project'), which clearly distinguishes it from siblings like raskadr_list_projects (which lists projects) and raskadr_plan_edit (which likely edits). The read-only qualifier ('without writing files') further clarifies its role.
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 this tool is used to inspect a specific project's details, but it does not explicitly state when to choose it over alternatives like raskadr_check_compatibility or raskadr_plan_edit. There are no 'use when' or 'instead of' statements, leaving some ambiguity for an agent deciding between related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List local CapCut desktop projects without modifying them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 does disclose a key behavioral trait: the tool does not modify projects, which is a meaningful safety guarantee. However, it does not mention return format, error behavior, or whether it scans local storage, leaving some uncertainty about the operation'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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It communicates the action, the resource, and the safety property in a compact form, which is ideal for a zero-parameter tool.
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 read-only list operation, the description captures the essential elements: what it lists, where those items are located, and that it does not modify them. The exact return structure is not specified, but the verb 'List' reasonably implies a collection of projects. It could be more complete by pointing to raskadr_inspect_project for per-project details, but this is not strictly necessary for invoking the tool correctly.
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 and an empty input schema, so the baseline of 4 applies. The description does not need to explain parameter semantics because there are no parameters to document. This is a case where the schema fully covers the parameter surface, and the description adds no unnecessary detail.
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 states a specific verb ('List') and a specific resource ('local CapCut desktop projects'), making the tool's purpose immediately clear. It also adds the scope 'without modifying them,' which reinforces its read-only nature. However, it does not explicitly contrast with sibling tools like raskadr_inspect_project, so differentiation is left implicit.
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 gives no guidance on when to use this tool versus alternatives such as raskadr_inspect_project or raskadr_check_compatibility. The phrase 'without modifying them' implies a safe listing operation, but there are no explicit conditions, prerequisites, or exclusion statements to help an agent choose this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and preview split, trim, move, and delete operations without writing to the CapCut project.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Exact project folder name returned by raskadr_list_projects | |
| operations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It explicitly states the critical non-destructive trait: 'without writing to the CapCut project.' It also indicates the behavior of validating and previewing. It does not detail failure responses or return format, but the core safety-relevant behavior is clearly 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 a single, focused sentence with no filler. The action and the critical non-writing guarantee are both front-loaded, making it easy for an agent to grasp the tool's purpose immediately.
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 tool has a moderately complex schema with discriminated operation types and no output schema or annotations. The description covers the core purpose and safety property, but it omits the expected response shape, the relationship to raskadr_inspect_project for obtaining segment IDs, and any workflow guidance. It is adequate for selection but not fully complete for confident 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 description names the four operation types, which partially maps to the operations union in the schema, but it does not explain the project parameter or how operations should be structured. Schema description coverage is only 50%, so the description should compensate more; it does not add significant meaning beyond what the schema already provides.
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 ('Validate and preview') and names the exact resources it operates on ('split, trim, move, and delete operations'), while also stating that it does not write to the CapCut project. This clearly differentiates it from siblings like raskadr_health, raskadr_list_projects, and raskadr_inspect_project, none of which plan or preview edits.
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 makes the intended usage context clear: use this tool when you need to validate or preview editing operations without applying them. However, it does not explicitly mention alternatives or state when not to use it, such as pointing to an actual edit-apply tool.
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.
v0.1.0raskadr_check_compatibilityraskadr_healthraskadr_inspect_projectraskadr_list_projectsraskadr_plan_editMost tools have clear, distinct responsibilities: list projects, inspect a project, and plan an edit are easy to tell apart. However, raskadr_health and raskadr_check_compatibility overlap somewhat as both are read-only environment/integrity checks, which could cause an agent to pick the wrong one.
All tools share the raskadr_ prefix and use snake_case, with most following a verb_noun pattern like list_projects and inspect_project. raskadr_health breaks that pattern slightly by using a noun instead of a verb.
Five tools is well-scoped for a read-only CapCut draft planning server. Each tool covers a distinct stage: health check, listing, inspection, compatibility validation, and edit planning.
The tool set forms a complete read-only workflow: verify access, list projects, inspect a project, check compatibility, and preview edits. Since the server explicitly avoids writing files, no CRUD operations are missing for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only AI project discovery, verification, comparison, shortlisting, and stack planning.
A real timeline video editor for AI agents: journaled edits, FFmpeg/MLT rendering, exports
AI video editor: create projects, edit timelines, add captions and effects, and render videos.
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/n1ghtmare-dev/raskadr-capcut-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
