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 Server Create a new project called 'My Video' and add subtitles at the beginning."
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 (Model Context Protocol) server that gives AI assistants full control over CapCut video editing projects. Create projects, import media, add text/subtitles, manage audio, and edit timelines — all through AI-powered tools.
AI Assistant ──MCP Protocol──▶ CapCut MCP Server ──Read/Write JSON──▶ CapCut Draft Files
(Python/FastMCP) (draft_content.json)CapCut stores every project as a folder with a draft_content.json file. This MCP server reads and writes those files directly. You edit via the AI, then open the project in CapCut to preview and export.
Related MCP server: CapCutAPI-Complete MCP Server
# Clone your repository
git clone https://github.com/baizo7/capcut_MCP_server-.git
cd capcut_MCP_server-
# Using pip
pip install -e ".[cli]"
# Or using uv (recommended)
uv pip install -e .On Windows, open your Gemini MCP configuration file located at:
%USERPROFILE%\.gemini\config\mcp_config.json
Add this to your mcpServers object:
{
"mcpServers": {
"capcut": {
"command": "python",
"args": ["-m", "capcut_mcp.server"],
"env": {
"CAPCUT_DRAFTS_PATH": "C:\\Users\\LENOVO\\AppData\\Local\\CapCut\\User Data\\Projects\\com.lveditor.draft"
}
}
}
}Note: After saving, restart the IDE for the new server to boot up.
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"capcut": {
"command": "python",
"args": ["-m", "capcut_mcp.server"]
}
}
}Add to .cursor/mcp.json in your project:
{
"mcpServers": {
"capcut": {
"command": "python",
"args": ["-m", "capcut_mcp.server"]
}
}
}Once configured, your AI assistant can use commands like:
"Create a new TikTok project called 'Summer Vibes'"
"Import all videos from D:\footage\vacation and add them to the timeline"
"Add subtitles: 'Hello!' at 0-2s and 'Welcome!' at 2-5s"
"Trim the first clip to start at 3 seconds"
If you are running the MCP server using Python installed from the Microsoft Store (which is common in Gemini IDE and Cursor), Windows automatically sandboxes writes to AppData\Local.
The Issue: The AI will create projects perfectly, but Windows hides them from CapCut.
The Fix: We built an automatic "Sandbox Escape" into the server using PowerShell! However, for best results, we highly recommend changing CapCut's default save location (Settings -> Project -> Save to) to your Documents folder, and updating your CAPCUT_DRAFTS_PATH environment variable to match it.
Because we are editing the raw JSON save files on your hard drive behind CapCut's back, CapCut does not instantly update its screen while you are actively editing a timeline.
To see changes: You must click the "X" in CapCut to return to the Home screen, then click the project again to force CapCut to reload the timeline from the hard drive.
For new projects: Simply switch tabs (e.g., from "Space" to "Home") to refresh the project list.
Environment Variable | Description | Default |
| Path to your CapCut drafts folder | Auto-discovered |
The server automatically checks these locations for CapCut projects:
%LOCALAPPDATA%\CapCut\User Data\Projects\com.lveditor.draft
%LOCALAPPDATA%\CapCut\User Data\Drafts
Tool | Description |
| List all CapCut projects on this computer |
| Detailed project info: tracks, materials, segments |
| Create a new empty project (with canvas presets) |
| Clone a project as a template |
| Delete a project (requires confirmation) |
| Show available canvas sizes (landscape, portrait, etc.) |
Tool | Description |
| Import a video file to the timeline |
| Add an image as a still clip |
| Batch-import all media from a folder |
| List all assets in a project |
| Remove an asset and its timeline clips |
Tool | Description |
| Add a text overlay at a specific time |
| Bulk-add subtitles from a structured list |
| Change font, color, size, alignment |
| Change the text content |
Tool | Description |
| Add background music or sound effects |
| Adjust volume of a specific clip |
| Mute all clips on a track |
| Restore volume on a muted track |
Tool | Description |
| Trim a clip's start/end point |
| Split a clip into two parts at a timestamp |
| Move a clip to a new timeline position |
| Remove a clip from the timeline |
| Arrange clips sequentially with optional gaps |
| Change playback speed (slow-mo, fast-forward) |
Automatic backups: Every edit creates a .backup of the draft before modifying
Non-destructive: Delete operations require explicit confirmation
Validation: All file paths are verified before import
# Install in development mode
pip install -e ".[dev]"
# Run tests
python -m pytest tests/ -v
# Test with MCP Inspector (browser-based)
npx -y @modelcontextprotocol/inspector python -m capcut_mcp.server⚠️ Unofficial: This server reverse-engineers CapCut's project format. It is not affiliated with ByteDance.
⚠️ Backups: The server automatically backs up projects before modification, but always keep your own backups of important projects.
⚠️ ffprobe: For accurate video/audio duration detection, install FFmpeg and ensure ffprobe is on your PATH. Without it, the server uses default duration estimates.
Add an audio file (music, sound effect, voiceover) to the project.
| Name | Required | Description | Default |
|---|---|---|---|
| volume | No | Volume level from 0.0 (silent) to 1.0 (full). Default 1.0. | |
| start_ms | No | Where to place the audio on the timeline (ms). Default 0. | |
| file_path | Yes | Absolute path to the audio file (MP3, WAV, AAC, FLAC, etc.). | |
| trim_end_ms | No | End trim in the source audio (ms). Use -1 for full duration. | |
| project_name | Yes | Name of the CapCut project. | |
| trim_start_ms | No | Start trim in the source audio (ms). Default 0. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 merely states 'add' without disclosing behavioral traits such as whether the audio is appended, replaced, or if there are limits. The impact on the timeline or project state is not addressed.
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, concise sentence with no wasted words. It is front-loaded with the core action and resource, making it immediately clear.
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?
Although an output schema exists, it is not shown in the input. The description lacks information on return values or how parameters like trim and volume interact. Given the tool's complexity (6 parameters), the description is insufficient for complete understanding.
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%, so the schema already documents all parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline expectation.
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 verb 'add' and the resource 'audio file', with examples of audio types (music, sound effect, voiceover). This effectively distinguishes it from sibling tools like add_image, add_video, etc.
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 usage for adding audio files but lacks explicit guidance on when to use this tool versus alternatives (e.g., add_media_batch for multiple files). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an image to the project's video track as a still clip.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the image file. | |
| duration_ms | No | How long to show the image (ms). Default 5000 (5 seconds). | |
| position_ms | No | Where to place it on the timeline (ms). Use -1 to append. | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states basic action without disclosing behavior like error handling (e.g., missing file), overwrite behavior, or timeline effects.
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?
Single sentence that directly conveys the purpose without extraneous words. Front-loaded and efficient.
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?
Adequate for a simple add operation, but lacks specification on file format support, error behavior, and interaction with existing clips. Output schema exists but unknown content.
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%, so baseline is 3. Description adds 'still clip' context but does not provide additional meaning beyond the schema's 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?
Clearly states the action 'Add' and the resource 'an image to the project's video track as a still clip'. This distinguishes it from sibling tools like add_video (adds video) and add_audio (adds audio).
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?
No guidance on when to use vs. alternatives like add_media_batch. No prerequisites or limitations mentioned (e.g., supported image formats, project existence).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import all media files from a folder into the project sequentially.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Glob pattern to filter files (e.g., "*.mp4", "*.jpg"). Default "*" for all media. | * |
| folder_path | Yes | Absolute path to the folder containing media files. | |
| project_name | Yes | Name of the CapCut project. | |
| image_duration_ms | No | Duration for each image clip (ms). Default 5000. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only mentions 'sequentially' but doesn't disclose error handling, blocking behavior, or whether the operation is atomic. With zero annotation coverage, this is insufficient.
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?
One short sentence that is efficient and front-loaded with the action. However, it could include more structured information such as prerequisites or return value without becoming verbose.
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 is too brief given the tool has 4 parameters and an output schema. It omits prerequisites, return value explanation, and behavior details beyond 'sequentially'. It needs more 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?
Schema description coverage is 100%, so all parameters are described in the schema. The tool description adds no additional meaning to the parameters; it only adds a behavioral note ('sequentially'). Baseline 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?
Description clearly states 'Import all media files from a folder into the project sequentially.' It specifies the verb 'import', the resource 'media files from a folder', and the behavior 'sequentially', distinguishing it from sibling tools like add_image or add_video that add single files.
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?
No guidance on when to use this tool vs alternatives. For example, it doesn't mention that for adding individual files one should use add_image or add_video, nor does it indicate prerequisites such as the project must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add multiple subtitle entries to the project in bulk.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Text color hex for all subtitles. Default "#FFFFFF". | #FFFFFF |
| font_size | No | Font size for all subtitles. Default 12.0. | |
| subtitles | Yes | A list of subtitle objects, each with: - "text": The subtitle text (required) - "start_ms": Start time in milliseconds (required) - "end_ms": End time in milliseconds (required) | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the basic action. It does not disclose any side effects (e.g., overwriting existing subtitles), or the significance of optional parameters like color and font_size. The schema covers parameter details, but behavioral context is missing.
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, concise sentence that precisely conveys the tool's function without unnecessary words. It is appropriately sized for quick comprehension.
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 is minimal but sufficient to understand the tool's basic purpose. However, given the presence of many sibling tools and the lack of clarity on how this differs from 'add_text', it feels incomplete. The existence of an output schema slightly reduces the need to describe returns.
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%, so the schema adequately documents all parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline expectation but providing no extra 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 clearly states the verb 'Add', the resource 'subtitle entries', and the qualifier 'in bulk', which distinctively indicates this tool adds multiple subtitles at once. This contrasts with siblings like 'add_text' which likely handles single text entries.
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 no guidance on when to use this tool versus alternatives such as 'add_text' or 'add_media_batch'. It does not specify prerequisites or context that would help an agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a text overlay to the project at a specific time.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Text color as hex string (e.g., "#FFFFFF" for white, "#FF0000" for red). | #FFFFFF |
| content | Yes | The text content to display. | |
| start_ms | No | When the text appears on the timeline (milliseconds). | |
| alignment | No | Text alignment — 0=left, 1=center, 2=right. Default 1 (center). | |
| font_size | No | Font size. Default 15.0. | |
| duration_ms | No | How long the text stays visible (ms). Default 3000 (3s). | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only mentions adding text at a specific time, lacking details about effects on the project, error handling, or return values.
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?
Single sentence with no wasted words. Verb first, clearly states action and target.
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 having 7 parameters and an output schema, the description is minimal and does not explain key context like that it modifies a CapCut project, that it creates an overlay, or how it interacts with the timeline.
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%, so parameters are well-described in the schema. The description adds no additional meaning beyond 'at a specific time' which is already in the schema.
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 it adds a text overlay to the project at a specific time. It distinguishes from sibling tools like add_image and add_video, but does not differentiate from add_subtitles.
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?
No guidance on when to use this tool versus alternatives like add_subtitles or update_text_content. No exclusions or context of usage provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a video file to the project's main video track.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the video file on disk. | |
| position_ms | No | Where to place the clip on the timeline (milliseconds). Use -1 to append after the last clip. | |
| trim_end_ms | No | End trim point in the source video (ms). Use -1 for full duration. | |
| project_name | Yes | Name of the CapCut project. | |
| trim_start_ms | No | Start trim point in the source video (ms). Default 0. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It only states a basic action without disclosing effects on existing clips, error handling, or behavioral traits like overwrite 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?
Single sentence, front-loaded with key information, no fluff. Efficiently communicates the core action.
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 having an output schema (which covers return values), the description lacks context about requiring an existing project, the meaning of 'main video track', and other usage nuances. Fails to provide a complete picture.
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% with detailed parameter descriptions. The tool description adds no extra meaning beyond the action; baseline 3 is appropriate since schema already provides all necessary parameter semantics.
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 verb 'Add', the resource 'video file', and the target 'project's main video track'. It effectively distinguishes from sibling tools like add_audio or add_image.
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?
No guidance on when to use this tool versus alternatives (e.g., add_media_batch for multiple files, or add_image for images). Missing context like prerequisites (project must exist) or file format restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new empty CapCut project.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | Frames per second (default 30). | |
| name | Yes | Name for the new project. | |
| width | No | Custom canvas width (overrides preset if provided). | |
| height | No | Custom canvas height (overrides preset if provided). | |
| preset | No | Canvas preset — one of: landscape (1920x1080), portrait (1080x1920), square (1080x1080), youtube, tiktok, instagram_reel, instagram_post. | landscape |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It only states 'create new empty project' without disclosing whether permissions are needed, what the initial state is, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words, conveying the core purpose effectively.
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 tool has 5 parameters and an output schema, the description is minimal. It does not explain that the project is created empty and ready for media, nor does it mention any required steps after creation. The presence of an output schema reduces the need to describe return values, but context for the creation workflow is missing.
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%, so the description adds no additional parameter info beyond what's in the schema. Baseline 3 is appropriate as the description does not elaborate on usage of parameters like 'fps' or 'preset'.
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 verb 'create' and the resource 'new empty CapCut project', accurately distinguishing from sibling tools like 'add_audio' or 'add_video' which operate on 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?
No guidance on when to use this tool versus alternatives. For instance, it does not mention that this should be called before adding media, or that it replaces 'duplicate_project' for initial creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a clip from the timeline.
| Name | Required | Description | Default |
|---|---|---|---|
| segment_id | Yes | ID of the segment to delete. | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'delete' without disclosing side effects (irreversible? frees resources?). This lack of behavioral context increases risk for an AI agent.
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 only one sentence, which is concise but omits necessary behavioral and usage information. Conciseness should not come at the cost of completeness; here it sacrifices guidance.
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 tool's simplicity (2 params, output schema exists), the description still lacks important context like whether deletion is immediate/permanent or if any undo mechanism exists. This is incomplete for safe agent usage.
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%, and the parameter descriptions in the schema are clear ('ID of the segment to delete', 'Name of the CapCut project'). The description adds no extra meaning beyond the schema, so baseline score 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 clearly states the action and resource: 'Delete a clip from the timeline.' It uses a specific verb ('delete') and resource ('clip'), and distinguishes well from sibling tools like trim_clip, split_clip, or move_clip.
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?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., open project, existing clip) or when not to use it, which is needed for such a destructive operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a CapCut project.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be set to True to actually delete. Safety check. | |
| project_name | Yes | Name of the project to delete. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose important behavioral traits like irreversibility or the requirement for the 'confirm' parameter. The safety check is only in the schema, not in the description.
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, concise sentence with no wasted words. However, it could be slightly expanded to include key behavioral details.
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 presence of an output schema and two parameters, the description is incomplete. It omits the need for the 'confirm' parameter and does not explain return values or side effects.
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%, so the schema already explains both parameters (project_name, confirm). The description adds no additional meaning beyond what the schema 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 clearly states the action (delete) and the resource (CapCut project), distinguishing it from siblings like create_project, duplicate_project, and delete_clip. It is specific and unambiguous.
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?
No guidance is provided on when to use this tool versus alternatives, such as delete_clip for removing individual clips. The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate an existing CapCut project.
| Name | Required | Description | Default |
|---|---|---|---|
| new_name | Yes | Name for the duplicated project. | |
| source_name | Yes | Name of the project to copy. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fails to disclose any behavioral details such as whether the source project is modified, whether duplication is deep or shallow, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) with no wasted words. However, it is so brief that it sacrifices behavioral completeness, making it slightly less effective than a well-structured few sentences.
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 tool's simplicity and existence of an output schema, the description is still incomplete. It omits important context like whether duplication preserves all media, metadata, or settings, and whether the source remains unchanged.
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?
Input schema has 100% description coverage, so the schema already documents parameters. The description adds no additional meaning beyond what the schema provides, so baseline 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 clearly identifies the action ('duplicate') and resource ('existing CapCut project'), and the verb distinguishes it from sibling tools like 'create_project' which would create a new project from scratch.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., create_project, get_project_info). The description simply states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a CapCut project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_name | Yes | The name of the project to inspect. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It only says 'Get detailed information' but doesn't disclose behavioral traits such as read-only nature, error handling (e.g., if project not found), or authentication requirements.
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 sentence of 9 words with no excess information. It is efficiently front-loaded and earns 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?
The tool has a simple interface with one parameter and an output schema (present but not shown). The description covers the basic purpose but lacks usage context and behavioral details. It is minimally complete.
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 has 100% coverage with one required parameter 'project_name' described as 'The name of the project to inspect.' The description adds no extra meaning beyond the schema, so baseline score 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 clearly states the tool retrieves detailed information about a CapCut project. The verb 'get' and resource 'project info' are specific. However, it doesn't distinguish from sibling tools like list_projects (which lists projects) or duplicate_project, but the purpose is clear enough.
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?
No guidance on when to use this tool versus alternatives. For example, it doesn't clarify that this tool is for a single project while list_projects lists all projects. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available canvas size presets for creating new projects.
Shows all preset names and their resolutions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates a read-only listing operation without destructive behavior. Adequately discloses basic 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 concise sentences with no wasted words, front-loading the main action.
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?
Has output schema; description explains the output content. Complete for a simple list tool with no parameters.
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?
No parameters exist; baseline for 0 params is 4. Description adds no param info, but not 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 clearly states the tool lists canvas size presets for creating projects and mentions specific output (names and resolutions). It distinguishes from sibling tools like create_project.
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?
Usage is implicitly clear (before creating a project) but no explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all materials (assets) registered in a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the tool lists materials. It does not disclose any behavioral traits like side effects, permissions, rate limits, or result format beyond the basic operation.
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, concise sentence with no unnecessary words. It gets straight to the point without any fluff.
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 is simple with one parameter and an output schema. The description minimally states the purpose but lacks additional context like what constitutes a material or how the output is structured. It is adequate but not enriched beyond the bare minimum.
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% and the parameter 'project_name' is documented in the schema. The description does not add any extra meaning or context for the parameter beyond what the schema provides, so a 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 clearly states the verb 'List' and the resource 'all materials (assets) registered in a project.' It distinguishes this tool from siblings like 'list_projects' and 'list_canvas_presets' by specifying the exact scope.
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?
No guidance on when to use this tool versus alternatives such as 'get_project_info' or 'remove_material'. There is no explicit context for usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all CapCut projects found on this computer.
Returns a summary of each project including name, duration, resolution, FPS, and number of tracks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states it returns a summary of projects (read-only), but does not disclose any potential side effects, performance concerns, or scope limitations (e.g., all projects regardless of state). Adequate but not comprehensive.
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 efficiently communicate the tool's purpose and output. Every sentence adds value with no redundancy.
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 tool has no parameters, siblings cover other lists, and an output schema exists (though not shown), the description fully covers what an agent needs to know to invoke and interpret results.
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 no parameters, so the required baseline is 4. The description does not need to add parameter info beyond what the schema (empty) 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 clearly states the verb 'List' and the resource 'all CapCut projects found on this computer,' making it highly specific and distinctive from sibling tools that list other entities like canvas presets or materials.
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?
While the description clearly implies when to use (when listing projects is needed), it lacks explicit guidance on exclusions or alternatives. However, given the sibling tools are distinct, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a clip to a different position on the timeline.
| Name | Required | Description | Default |
|---|---|---|---|
| segment_id | Yes | ID of the segment to move. | |
| project_name | Yes | Name of the CapCut project. | |
| new_position_ms | Yes | New start position on the timeline (ms). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states the basic action without mentioning side effects (e.g., whether other clips shift, if bounds are checked, or if the operation is reversible).
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 unnecessary words. It is appropriately concise for the tool's simplicity.
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 presence of an output schema, the description lacks information about behavior and return values. For a timeline modification tool, more detail about the result (e.g., what the output contains) and constraints (e.g., valid position range) would be expected.
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%, and each parameter already has a clear description in the schema. The tool description does not add additional context beyond what the schema provides, so it meets the baseline of 3.
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 action ('Move a clip') and the target ('to a different position on the timeline'), which distinguishes it from tools like trim_clip or split_clip. However, it could better differentiate from 'reorder_clips,' which may also involve moving clips in a timeline context.
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?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like 'reorder_clips' or how prerequisites (e.g., project must exist) should be handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mute all clips on a specific track.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | The track number (0-based). Use get_project_info to see tracks. | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the action 'mute' but does not clarify whether it is a toggle or sets a mute state, nor does it mention effects on existing clip volume settings or reversibility (though sibling unmute_track exists).
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, concise sentence that immediately conveys the core function with no unnecessary words. It is well front-loaded.
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 tool's simplicity (2 parameters, output schema exists), the description adequately covers the main behavior. It could mention error cases or confirmation of mute action, but it is largely complete for an agent.
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% and both parameters have clear descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline for high coverage without extra 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 clearly states the action (mute) and the resource (all clips on a specific track). It effectively distinguishes from sibling tools like unmute_track (which unmutes) and set_volume (which adjusts volume, not mute).
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 (to mute an entire track) but does not explicitly provide guidance on when not to use, prerequisites, or comparisons with alternatives like muting individual clips.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a material and all its segments from the project.
| Name | Required | Description | Default |
|---|---|---|---|
| material_id | Yes | The ID of the material to remove (use list_materials to find IDs). | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It notes removal of segments but does not mention irreversibility, required permissions, or any side effects. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and contains no superfluous information. It efficiently conveys the core action.
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 tool's simplicity and the presence of an output schema (not shown), the description adequately covers the main purpose. It could mention reversibility or impacts on the project, but overall it is sufficient for a straightforward removal operation.
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%, and the description adds no additional meaning beyond the schema. The schema itself provides adequate descriptions for both parameters.
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 verb ('Remove') and the resource ('a material and all its segments from the project'). It distinguishes itself from sibling tools (e.g., delete_clip, delete_project) by specifying 'material' and including 'segments'.
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?
No explicit guidance on when to use this tool vs alternatives. While it is the only tool for removing materials, the description does not provide context such as prerequisites or when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reorder clips on a track so they play sequentially without gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| gap_ms | No | Gap to insert between clips (ms). Default 0 (no gap). | |
| track_index | Yes | The track number (0-based). | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like destructive nature, permission requirements, or undo behavior. For a mutating tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with the core purpose.
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?
Description is adequate for a simple reorder tool, but lacks details on edge cases (e.g., invalid track index, empty track) and uses no annotations for safety context.
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%, so the schema sufficiently documents the parameters. The description adds no extra 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?
Description clearly states the action (reorder) and the resource (clips on a track) with the outcome (sequential playback without gaps). It is specific but does not explicitly distinguish from sibling tools like move_clip.
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?
No explicit guidance on when to use this tool vs alternatives such as move_clip or delete_clip. The phrase 'so they play sequentially without gaps' implies a use case but does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the playback speed of a clip.
| Name | Required | Description | Default |
|---|---|---|---|
| speed | Yes | Playback speed multiplier. 1.0 = normal, 2.0 = 2x fast, 0.5 = half speed. | |
| segment_id | Yes | ID of the segment to adjust. | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose reversibility, side effects (e.g., duration changes), or permissions required. The simple statement 'Change the playback speed' offers minimal behavioral insight.
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?
Single sentence, no redundancy. Efficient but could be more structured (e.g., listing effects). Still, it's appropriately short for a simple operation.
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 good schema coverage and an output schema, the description lacks important context: valid speed range, constraints, or behavioral effects. For a tool with no annotations, this makes it insufficiently complete.
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%, so each parameter has a description. The tool description adds no extra parameter meaning beyond the schema, which already explains speed multiplier and IDs. Baseline 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 clearly states the action (Change) and resource (playback speed of a clip), distinguishing it from sibling tools like set_volume or trim_clip. However, it does not specify clip type (audio/video), which is implicit from context.
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?
No guidance on when to use this tool versus alternatives like split_clip or trim_clip. No prerequisites or conditions mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adjust the volume of a specific clip (video or audio).
| Name | Required | Description | Default |
|---|---|---|---|
| volume | Yes | Volume level from 0.0 (silent) to 1.0 (full volume). Values above 1.0 will boost volume. | |
| segment_id | Yes | ID of the segment to adjust. | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as mutation effects, reversibility, or authorization needs. The only behavioral detail is the volume range from the parameter description, which is already in the 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 a single, concise sentence that conveys the essential information without any unnecessary words. It is well front-loaded.
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 having an output schema and clear schema coverage, the tool description is too brief for a mutation operation with three required parameters. It does not mention the effect on the project, any side effects, or the return value context.
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 input schema covers all parameters with descriptions (100% coverage), so the tool description adds no extra meaning beyond what is already documented. 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 specifies the verb 'adjust' and the resource 'volume of a specific clip', distinguishing it from sibling tools like mute_track which operate on tracks, not clips. It also clarifies that it applies to both video and audio clips.
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?
No guidance is provided on when to use this tool versus alternatives like mute_track or set_clip_speed. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a clip into two parts at a specific timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| at_ms | Yes | The timeline position (ms) at which to split the clip. Must be within the clip's time range. | |
| segment_id | Yes | ID of the segment to split. | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states 'split into two parts' without detailing side effects (e.g., whether the original clip is removed or two new clips are created), permissions needed, or consequences for the timeline.
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 sentence with no wasted words, but it is minimal. Could be slightly improved with additional context without harming conciseness.
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 existence of an output schema, the description need not detail return values. However, it omits any mention of timeline behavior or segment id changes, which are important for a split operation. Adequate but not fully complete.
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 input schema has 100% coverage and already describes the three parameters. The description adds no extra semantic value beyond the schema, so baseline 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 clearly states the verb 'split', the resource 'clip', and the specific condition 'at a specific timestamp'. It distinguishes from sibling tools like trim_clip or delete_clip.
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?
No guidance is provided on when to use split vs. alternatives like trim_clip, or prerequisites such as the project being open. The description lacks context for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trim a clip by adjusting its start and/or end point.
| Name | Required | Description | Default |
|---|---|---|---|
| new_end_ms | No | New end time relative to the source material (ms). Trims the end of the clip. | |
| segment_id | Yes | ID of the segment to trim. | |
| new_start_ms | No | New start time relative to the source material (ms). Trims the beginning of the clip. | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It only states the basic trimming action without disclosing destructive behavior, reversibility, or limitations (e.g., cannot extend beyond source). Minimal transparency.
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?
Single sentence with no unnecessary words. Directly conveys the action.
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?
With output schema present, return format is assumed covered. However, the description lacks details about behavioral consequences and usage context. For a moderately complex tool (4 parameters), some additional context (e.g., whether it's destructive) is expected but missing.
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% with detailed parameter descriptions. The tool's description adds the general context of trimming but does not add meaning beyond what the schema already provides. 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?
Description clearly states the verb 'trim' and resource 'clip', and specifies adjusting start/end point. This distinguishes it from sibling tools like split_clip or delete_clip.
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?
No guidance provided on when to use this tool versus alternatives (e.g., split_clip). No mention of prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unmute (restore volume on) all clips on a specific track.
| Name | Required | Description | Default |
|---|---|---|---|
| volume | No | Volume level to set (default 1.0 = 100%). | |
| track_index | Yes | The track number (0-based). | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It says 'unmute (restore volume on)', but the input schema includes a 'volume' parameter with a default of 1, implying the tool sets a specific volume rather than restoring the previous state. This nuance is not 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 a single sentence of 12 words, efficiently conveying the core functionality without redundancy.
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 having an output schema, the description lacks information about prerequisites (e.g., track must exist), behavior when track is already unmuted, and clarification of the volume parameter's semantics. This leaves gaps for an AI agent.
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%, so baseline is 3. The description does not add meaning beyond the schema: it doesn't explain the 'volume' parameter's role in the unmute context (e.g., that 1.0 is full volume).
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 action ('unmute') and the resource ('all clips on a specific track'). It effectively distinguishes from the sibling tool 'mute_track', making the purpose unambiguous.
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 use for restoring volume on a previously muted track, but does not explicitly state when not to use it or compare with alternatives like 'set_volume'. The context of sibling 'mute_track' helps, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the text content of an existing text overlay.
| Name | Required | Description | Default |
|---|---|---|---|
| new_text | Yes | The new text content. | |
| segment_id | Yes | ID of the text segment to update. | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It indicates a mutation operation but lacks details on side effects, permissions, or reversibility. The action is straightforward, so basic clarity is achieved.
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 concise sentence with no wasted words. It is front-loaded with the action and resource. Could be slightly more informative without losing conciseness.
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 3-parameter tool with an output schema, the description is adequate but minimal. It does not mention prerequisites (e.g., segment must exist) or error conditions. With no annotations, additional context would improve 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?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema. It does not elaborate on permissible values for new_text or how to obtain segment_id.
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 it updates the text content of an existing text overlay. It distinguishes itself from siblings like add_text (adds new text) and update_text_style (updates style rather than content).
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 usage when needing to change text of an existing overlay but provides no explicit guidance on when not to use it or when to use sibling tools instead, such as update_text_style for style changes or add_text for new overlays.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the styling of an existing text overlay.
| Name | Required | Description | Default |
|---|---|---|---|
| bold | No | Set bold style (optional). | |
| color | No | New text color hex (optional). | |
| italic | No | Set italic style (optional). | |
| alignment | No | New alignment — 0=left, 1=center, 2=right (optional). | |
| font_size | No | New font size (optional). | |
| segment_id | Yes | ID of the text segment to update (from get_project_info or add_text). | |
| project_name | Yes | Name of the CapCut project. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden but only states 'update styling' without disclosing behavioral traits like destructive nature, overwrite behavior, or required permissions.
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?
Single clear sentence with no excess, but could be more informative without becoming verbose.
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 having an output schema, the description lacks crucial context about how updates apply (e.g., partial vs full overwrite), constraints, and prerequisites for a mutation tool with 7 parameters.
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%, so baseline is 3. Description adds no additional meaning beyond the schema's 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?
Description uses specific verb 'Update' and resource 'styling of an existing text overlay', clearly distinguishing it from sibling 'update_text_content' which updates text content.
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?
Description implies use for styling changes versus content changes, but provides no explicit when-to-use, prerequisites, or alternatives.
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.0add_audioadd_imageadd_media_batchadd_subtitlesadd_textadd_videocreate_projectdelete_clipdelete_projectduplicate_projectget_project_infolist_canvas_presetslist_materialslist_projectsmove_clipmute_trackremove_materialreorder_clipsset_clip_speedset_volumesplit_cliptrim_clipunmute_trackupdate_text_contentupdate_text_styleEach tool has a clearly distinct purpose, targeting specific media types, editing actions, or project management. No overlapping or ambiguous tools.
All tool names follow a consistent verb_noun snake_case pattern, such as add_video, delete_clip, list_projects. The pattern is uniformly applied across all tools.
With 25 tools, the server covers a broad range of video editing operations (project management, media import, editing, text, audio) without being overwhelming. This is well-scoped for a CapCut MCP.
The tool set covers core workflows: project lifecycle, media addition, basic editing (trim, split, speed, volume), and text manipulation. Missing advanced features like effects, transitions, or export, but the core surface is mostly complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI video editor: create projects, edit timelines, add captions and effects, and render videos.
Edit video by talking to your AI — search footage, cut timelines, apply effects, add captions.
Create and edit AI videos from chat: plan shots, generate scenes, and export stories and ads.
Agentic video editing on real footage: cut, caption, reframe, score, and export at full quality.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/baizo7/capcut_MCP_server-'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
