proofcut

Overview Schema Source Related Servers Discussions Admin

cue_rm

Destructive

Remove a picture cue from a project by addressing its transcript word or phrase. Ambiguous cues are refused and listed, and shots re-project from the remaining cues.

Instructions

Remove one picture cue, addressed the way cue_add placed it.

Give word_index, or phrase to resolve against clip_id's transcript (its first word, cue_add's own binding). Refuses, listing every cue, when none sits at that word — cue_ls shows the table first. Shots re-project from the cues that remain; no other cue moves. Replacing a cue's asset is cue_rm then cue_add, since cue_add refuses an occupied word. 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.
`after`	No	A forward cursor over a phrase's matches: any match at or before this word index is skipped. -1, the default, means from the start.
`phrase`	No	Address it by wording instead; it resolves to its first word, the way `cue_add` placed it.
`clip_id`	Yes	The transcript the cue was addressed against.
`occurrence`	No	Disambiguate a phrase by count when it matches more than once, 1-based in transcript order among the matches after `after`: 1 is the first, 2 the second. Unset, an ambiguous phrase is refused — listing every candidate's range and text — rather than guessed at.
`word_index`	No	The word the cue sits on. Give this or `phrase`.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed21 schema fields changedv0.25.0Sep 16, 2026

addedInput schema / properties / after / description

Added value: +"A forward cursor over a phrase's matches: any match at or before this word index is skipped. -1, the default, means from the start."

removedInput schema / properties / after / title
```
Removed value: -"After"
```

addedInput schema / properties / clip_id / description

Added value: +"The transcript the cue was addressed against."

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

removedInput schema / properties / occurrence / anyOf

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

addedInput schema / properties / occurrence / description

Added value: +"Disambiguate a phrase by count when it matches more than once, **1-based** in transcript order among the matches after `after`: 1 is the first, 2 the second. Unset, an ambiguous phrase is refused — listing every candidate's range and text — rather than guessed at."

removedInput schema / properties / occurrence / title
```
Removed value: -"Occurrence"
```
addedInput schema / properties / occurrence / type
```
Added value: +[
+  "integer",
+  "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"
+]

removedInput schema / properties / phrase / anyOf

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

addedInput schema / properties / phrase / description

Added value: +"Address it by wording instead; it resolves to its first word, the way `cue_add` placed it."

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

removedInput schema / properties / word_index / anyOf

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

addedInput schema / properties / word_index / description

Added value: +"The word the cue sits on. Give this or `phrase`."

removedInput schema / properties / word_index / title
```
Removed value: -"Word Index"
```
addedInput schema / properties / word_index / type
```
Added value: +[
+  "integer",
+  "null"
+]
```
removedInput schema / title
```
Removed value: -"cue_rmArguments"
```

First observedv0.24.0Sep 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the destructiveHint=true annotation, the description discloses concrete behavioral effects: refusal with a full cue listing when the address is empty, re-projection of shots from remaining cues, and that no other cue moves. It also explains why replacement must be rm-then-add, and that `undo` reverses it. This is exactly the extra behavioral context annotations cannot provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is compact and front-loaded: action first, then addressing rules, then refusal behavior, then side effects, then workflow guidance. Every sentence contributes behavioral or usage value; there is no fluff or repetition of structured schema content.

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

Completeness5/5

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

Given the rich input schema and the presence of an output schema, the description supplies all the missing contextual glue: how to address a cue, what happens on failure, side effects on shots, the replacement pattern, and undo behavior. The agent has everything needed to decide when and how to call this tool correctly.

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%, with each parameter already richly documented, so the description carries little additional per-parameter burden. It does reinforce the central `word_index`/`phrase` addressing relationship and ties it to `cue_add`'s binding, but largely restates what the schema already says. Baseline 3 is appropriate here.

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 — 'Remove one picture cue' — and immediately anchors addressing to `cue_add`'s placement semantics. This cleanly distinguishes it from siblings like `cue_add`, `cue_reresolve`, `unspoken_rm`, and `hold_rm`. An agent can tell exactly what the tool does at a glance.

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

Usage Guidelines5/5

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

The description explicitly tells the agent to provide `word_index` or `phrase`, and explains what to do when no cue sits at the word (`cue_ls` shows the table first). It also names the replacement workflow (`cue_rm` then `cue_add`) and notes that `undo` restores it, giving clear when-to-use and alternative context. This is strong practical guidance beyond mere tool naming.

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

Deploy Server