proofcut

Overview Schema Source Related Servers Discussions Admin

hold_rm

Destructive

Remove a hold's record and its owned cue from a VO track, leaving the spliced silence as an ordinary manufactured gap. Revert with undo if needed.

Instructions

Drop a hold's record and its owned cue — the spliced silence stays.

vo_extend's own irreversibility, inherited: there is no clean "un-splice", only proofcut undo. After this the gap reverts to being an ordinary manufactured silence, a coherent pre-existing state rather than a broken one.

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.
`clip_id`	Yes	The VO track the hold was spliced into.
`gap_word_index`	Yes	The hold's address, with `clip_id`. The record and its owned cue go; the spliced silence stays, since there is no clean un-splice — only `undo`.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.25.0Sep 16, 2026

addedInput schema / properties / clip_id / description

Added value: +"The VO track the hold was spliced into."

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

addedInput schema / properties / gap_word_index / description

Added value: +"The hold's address, with `clip_id`. The record and its owned cue go; the spliced silence stays, since there is no clean un-splice — only `undo`."

removedInput schema / properties / gap_word_index / title
```
Removed value: -"Gap Word Index"
```

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"
+]

removedInput schema / title
```
Removed value: -"hold_rmArguments"
```

First observedv0.24.0Sep 15, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Beyond the destructiveHint annotation, the description adds critical nuance: the operation is irreversible in the sense that there is no clean un-splice, and the gap reverts to a 'coherent pre-existing state' rather than a broken one. It also states what persists (the spliced silence) and what disappears (the record and cue). This is meaningful behavioral disclosure that the annotation alone does not convey.

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 concise—two short paragraphs—and front-loads the primary action in the first sentence. The additional explanation about irreversibility and the resulting state is valuable but delivered in slightly poetic language ('spliced silence stays', 'coherent pre-existing state') that, while not verbose, could be more direct. Overall it is well-structured and avoids redundancy.

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 a destructive tool, the description covers the key operational aspect (what is removed and what remains) and the irreversibility condition. It does not explain domain concepts like 'record' or 'owned cue', but these are likely defined elsewhere or in the sibling tools' context. Given that an output schema exists (not shown here but flagged), the tool's return information is presumably documented there. The description is complete enough for an agent familiar with the domain.

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 parameter descriptions already explain each field adequately. The description itself adds minimal parameter semantics, only clarifying that gap_word_index plus clip_id forms the hold's address and that 'the record and its owned cue go'—which slightly enriches the parameter meaning. However, this is marginal beyond what the schema already provides, so the baseline 3 is appropriate.

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 description clearly states the tool drops a hold's record and its owned cue, with the explicit note that the spliced silence remains. This distinguishes it from sibling tools like hold_under_rm (which likely removes a 'hold under' region) and cue_rm (which would remove a cue without necessarily the hold record). However, the verb 'Drop' is informal and the exact scope of 'record' and 'owned cue' is implicit, requiring domain familiarity.

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

Usage Guidelines2/5

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

The description does not provide explicit when-to-use guidance relative to alternative hold-removal tools. It mentions that undo is the only way to revert, but never states 'use this when you want to completely remove a hold and its cue, versus hold_under_rm for partial removal' or similar. The context about irreversibility is behavioral, not usage-directional, so an agent is left to infer when this is the right choice among several hold-related sibling tools.

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

Deploy Server