proofcut

Overview Schema Source Related Servers Discussions Admin

follow

Destructive

Add a clip after another on the timeline with a cut or crossfade, preserving timing and framing. Use it to splice two recordings together.

Instructions

Put a second recording on the timeline after the first, cut or dissolved.

The window's recording, then the terminal's: clip_id plays its span spliced in after after, and everything after moves later. Words, events, retime stretches and reframe windows of either clip keep their meaning, so the incoming clip is retimed and framed like any other. dissolve seconds crossfade into it from its own frames before the in-point; the film is no longer for it. The reply gives the join and the dissolve; plan=true writes nothing, and undo takes the splice back.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ease`	No	The crossfade's curve: linear (the default), ease, ease-in or ease-out.	linear
`path`	No	The project directory to act on. Omit it — the usual case — when this server is bound to a project (started as `proofcut -C DIR mcp`, or inside a project; `ping` says which): it then resolves to that one bound project, a relative path resolves against it, and a path outside it is refused by name. Unbound, `path` is the whole address and omitting it refuses rather than guessing.
`plan`	No	Resolve the whole call and report what it would do, writing nothing. Prefer it over doing the thing and undoing it.
`after`	Yes	The clip on the timeline it follows — the first recording.
`clip_id`	Yes	The incoming recording, a registered clip with picture.
`src_end`	No	Seconds into clip_id where it ends. Default its end. Not with until_event.
`at_event`	No	Splice in after this event of `after` (name or name#k). Omitted: after the last of `after` the timeline plays.
`dissolve`	No	Seconds of crossfade into it; 0, the default, is a cut. Drawn from clip_id's own frames before its in-point, so it needs that much of the file before the start, and the film is no longer for it.
`src_start`	No	Seconds into clip_id where it starts. Default its head. Not with from_event.
`from_event`	No	Start at this event of clip_id instead of src_start.
`until_event`	No	End at this event of clip_id instead of src_end.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.37.0Sep 20, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations already mark destructiveHint=true, and the description goes well beyond that: it says 'everything after moves later,' explains that retime stretches and reframe windows keep their meaning, and warns that a dissolve consumes source frames before the in-point so 'the film is no longer for it.' It also discloses the dry-run behavior and the undo path, giving an agent a clear picture of 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.

Conciseness4/5

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

The description is dense but efficient: the core action is front-loaded, and the second paragraph packs in behavior, reply contents, dry-run, and undo without filler. The phrase 'The window's recording, then the terminal's' is slightly opaque, but overall the structure earns its length.

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

Completeness4/5

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

For an 11-parameter mutating tool with an output schema, this description covers the main side effects, safety options, and outcome semantics. It does not explicitly enumerate every parameter, but the schema does that; the main gap is the absence of an explicit routing distinction from sibling timeline-editing tools.

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 100%, so the baseline is 3. The description adds relational context by tying clip_id and after into the splicing operation and by explaining the dissolve behavior, but it does not substantially augment the per-parameter documentation already present in the schema.

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

Purpose4/5

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

The first sentence states a concrete operation: 'Put a second recording on the timeline after the first, cut or dissolved.' The second paragraph further clarifies that clip_id is spliced in after after and shifts subsequent content later. It is clear and specific, though it does not explicitly name a sibling tool to differentiate from.

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

Usage Guidelines3/5

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

The description conveys when the tool is used—splicing one recording after another—and even mentions plan=true as a non-writing way to preview. However, it gives no explicit guidance on when to choose follow over sibling timeline tools such as cut_by_time, seed_timeline, or dissolve, so usage context is mostly implied rather than stated.

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

Deploy Server