Skip to main content
Glama
Sign In
Arkeonix CapCut MCP

Arkeonix CapCut MCP

by daviilpzDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

capcut_semantic_edit

Apply a CapCut editing action automatically based on a visual scene query, choosing filters, effects, zooms, lower thirds, or canvas blur to match the moment.

Instructions

Automatically apply a CapCut editing action (filter, effect, zoom, lower_third, canvas_blur) matching a visual scene query.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "draft": "<draft>",
      "query": "<query>",
      "action": "<action>"
    },
    "name": "capcut_semantic_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNospecific filter or effect name override (e.g. "Vintage 90s", "Soft Vignette")
draftYes
queryYesvisual scene or emotion to match (e.g. "crying moment", "phone screen", "intro")
scaleNozoom scale factor if action is zoom (e.g. 1.10)
titleNotitle text if action is lower_third
actionYesediting action to apply
subtitleNosubtitle text if action is lower_third
intensityNofilter intensity (0 to 100)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It does convey that the tool automatically matches a scene query to an action, implying AI-driven selection rather than a deterministic explicit choice. However, it does not disclose side effects on the draft, whether the change is persisted, or that the semantic matching may produce varying results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence that front-loads the core behavior and action list. It wastes no words, though it is arguably too brief to cover the full complexity of the tool's behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, no annotations, and no output schema, a more complete description is needed. It does not explain what the tool returns, whether it modifies the draft immediately, how the matching process behaves, or what an agent should expect after invocation. The description is adequate for basic awareness but incomplete for reliable autonomous invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 88%, so the structured schema already documents most parameters like intensity, scale, title, and subtitle. The description adds contextual meaning to 'query' by framing it as a visual scene query and reinforces the action enum values, but it does not explain the 'draft' parameter or how the action selection interacts with the optional parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('apply') and resource ('CapCut editing action') and lists the exact action types it supports. The phrase 'matching a visual scene query' clearly distinguishes it from sibling tools like capcut_apply_filter or capcut_apply_effect, which apply specific named effects rather than auto-selecting based on a scene description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies the tool is for cases where a visual scene query should automatically drive the choice of editing action. However, it does not explicitly say when to prefer this over the more direct sibling tools like capcut_apply_filter or capcut_add_lower_third, nor does it state exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools