Detects cuts inside selected clips and applies cuts or creates markers at each detected cut; select clips first to edit timelines based on scene changes.
Detect cuts inside the selected clips (select them first with select_clips) and cut them, add markers or make subclips
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | What to do at each detected cut | |
| sensitivity | No | ||
| applyCutsToLinkedAudio | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the whole burden. It usefully discloses the scope (only clips in the current selection) and that it is a mutating operation ('cut them'), but says nothing about reversibility/undo, whether linked audio is affected by default, or where the resulting markers land.
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 front-loaded sentence that puts the operation and its prerequisite first, then the outcomes. It is tight, though the trailing 'or make subclips' is wasted text since that capability is not actually available.
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?
No output schema and no annotations, so the description must cover behavior; it omits sensitivity tuning, linked-audio behavior, and any indication of what is returned or how cuts are surfaced. The schema's own gap on two of three parameters is not compensated.
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 only 33%. The description partially maps the action enum ('cut them, add markers'), but says nothing about the sensitivity enum or applyCutsToLinkedAudio, which are entirely undocumented in the schema — the two parameters most likely to change the result are left opaque.
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?
States a specific verb and resource ('Detect cuts inside the selected clips') and names the three outcomes (cut, add markers, make subclips), which distinguishes it from razor_clip and add_marker. However, 'make subclips' does not exist in the action enum (only ApplyCuts and CreateMarkers), so the stated capability set is broader than what the schema permits.
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?
Gives an explicit prerequisite and routes the agent to the sibling that satisfies it: 'select them first with select_clips'. There is no when-not guidance or explanation of when to prefer ApplyCuts vs CreateMarkers, so usage is clear but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.