Ripple-delete specified time ranges from the primary storyline, sliding later clips left and optionally keeping or deleting connected B-roll and titles.
Ripple-delete time ranges from the primary storyline, e.g. [[12.5, 15], [40, 41.2]]. Later clips slide left. connected="keep" re-attaches B-roll/titles anchored inside a removed range at the cut point; "delete" removes them like FCP does.
| Name | Required | Description | Default |
|---|---|---|---|
| ranges | Yes | ||
| connected | No | keep |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose key behavior: later clips slide left, connected items anchored inside a removed range are re-attached at the cut point under "keep" or removed like FCP under "delete". It omits that this is a destructive edit requiring undo, and says nothing about whether it acts only on the primary storyline or also on connected lanes.
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?
Three tight sentences, lead sentence carries verb+resource+argument example, then behavior, then the enum semantics. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an unannotated destructive timeline mutation with no output schema, the description covers ripple mechanics and the connected flag but leaves gaps an agent needs: prerequisites (which timeline), undo/reversibility expectations, and any indication of what is returned. Adequate but not 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 0%, so the description must compensate and largely does: it gives an example shape for ranges ([[12.5, 15], [40, 41.2]]) and explains both enum values of connected with concrete consequences. It still leaves the time unit (seconds?) and ordering/overlap rules for ranges unstated.
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 ('Ripple-delete time ranges from the primary storyline') with a concrete example of the range argument. The ripple/primary-storyline scoping is clear, but it never names the obvious counterpart sibling keep_ranges or distinguishes itself from delete_clip/remove_silences, so sibling differentiation is left to inference.
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 implied by the ripple semantics and the connected=
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.