proofcut

Overview Schema Source Related Servers Discussions Admin

seed_timeline

DestructiveIdempotent

Lay one or more recordings end to end as a new timeline, silence-cut by default. Replaces the current project timeline, snapshots the old one for undo, and accepts auto-editor expressions for custom cuts.

Instructions

Lay a clip down as the timeline, silence-cut by auto-editor by default.

A list of clips lays several recordings end to end in that order, each silence-cut the same way — a footage dump seeded once, cleaned once, then split. clips reports each one.

edit_expr passes auto-editor's edit language straight through, e.g. "(or audio:0.03 motion:0.06)".

Writes project.otio and replaces any timeline already there — every cut made since the last seed included. It seeds a project rather than re-cutting one, and a re-seed with the same arguments lands the same timeline. The old one is snapshotted first, so undo puts it back.

Input Schema

TableJSON Schema

Name	Required	Description
`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.
`margin`	No	How much to leave either side of kept audio, in auto-editor's own notation (e.g. `0.2s`), so an edge lands in the silence rather than on the breath.
`clip_id`	Yes	The clip to lay down as the timeline, or a list of recordings laid end to end in that order. Several must all have picture.
`edit_expr`	No	auto-editor's edit language, passed straight through — e.g. `(or audio:0.03 motion:0.06)`. It replaces the threshold-based rule.
`threshold`	No	auto-editor's audio loudness threshold, 0–1. Lower keeps quieter material.
`remove_silences`	No	Silence-cut the clip on the way in, through auto-editor. On by default; false lays the whole clip down untouched.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.43.0Sep 24, 2026

addedInput schema / properties / clip_id / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]

changedInput schema / properties / clip_id / description

Previous value: -"The clip to lay down as the timeline."New value: +"The clip to lay down as the timeline, or a list of recordings laid end to end in that order. Several must all have picture."

removedInput schema / properties / clip_id / type
```
Removed value: -"string"
```

Changed19 schema fields changedv0.25.0Sep 16, 2026

addedInput schema / properties / clip_id / description

Added value: +"The clip to lay down as the timeline."

removedInput schema / properties / clip_id / title
```
Removed value: -"Clip Id"
```

removedInput schema / properties / edit_expr / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / edit_expr / description

Added value: +"auto-editor's edit language, passed straight through — e.g. `(or audio:0.03 motion:0.06)`. It replaces the threshold-based rule."

removedInput schema / properties / edit_expr / title
```
Removed value: -"Edit Expr"
```
addedInput schema / properties / edit_expr / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / properties / margin / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / margin / description

Added value: +"How much to leave either side of kept audio, in auto-editor's own notation (e.g. `0.2s`), so an edge lands in the silence rather than on the breath."

removedInput schema / properties / margin / title
```
Removed value: -"Margin"
```
addedInput schema / properties / margin / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / properties / path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / path / description

Added value: +"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."

removedInput schema / properties / path / title
```
Removed value: -"Path"
```

addedInput schema / properties / path / type

Added value: +[
+  "string",
+  "null"
+]

addedInput schema / properties / remove_silences / description

Added value: +"Silence-cut the clip on the way in, through auto-editor. On by default; false lays the whole clip down untouched."

removedInput schema / properties / remove_silences / title
```
Removed value: -"Remove Silences"
```

addedInput schema / properties / threshold / description

Added value: +"auto-editor's audio loudness threshold, 0–1. Lower keeps quieter material."

removedInput schema / properties / threshold / title
```
Removed value: -"Threshold"
```

removedInput schema / title

Removed value: -"seed_timelineArguments"

First observedv0.24.0Sep 15, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already indicate destructive and idempotent behavior, but the description adds valuable detail: 'Writes `project.otio` and **replaces any timeline already there** — every cut made since the last seed included.' It also discloses the undo safety net ('The old one is snapshotted first, so `undo` puts it back') and explains the silence-cutting default, which fully transparently expands on the annotations.

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 well-structured, front-loading the core purpose in the first sentence. It uses three paragraphs to cover single clips, multiple clips, and the edit expression, then explains the write/destructive behavior. While slightly verbose, every sentence adds relevant context and no filler or redundancy is present. The use of bold for the destructive action improves scannability.

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?

Given the tool's complexity (6 parameters, 1 required, destructive and idempotent), the description covers most key aspects: the operation, behavior with lists, edit expression passing, parameter defaults (via schema), and the replacement/undo mechanism. It does not explicitly mention expected return values or error scenarios, but an output schema exists, so that burden is partially relieved. A few edge cases like handling of `path` when unbound are already in the schema, so the description is sufficient for an agent to correctly invoke the tool.

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 all parameters already have detailed descriptions. The tool description adds marginal context, such as explaining that `edit_expr` passes auto-editor's edit language straight through and that `clip_id` as a list lays recordings end to end. These nuances are already partly present in the schema, so the description adds limited 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.

Purpose5/5

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

The description opens with a specific verb and resource: 'Lay a clip down as the timeline, silence-cut by auto-editor by default.' It clearly distinguishes from siblings by stating it 'seeds a project rather than re-cutting one' and explicitly references the `split` and `clips` tools. The purpose is unambiguous and behaviorally distinct from the listed siblings like `timeline_status` or `timeline_view`.

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 explains when this tool is appropriate: it seeds a project rather than re-cutting one, and mentions that a re-seed with the same arguments yields the same timeline. It also references `split` and `clips` as subsequent operations. However, it does not explicitly state when NOT to use it or offer a direct comparison with alternatives like `split` or `undo`. The guidance is clear but not exhaustive.

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

Deploy Server