proofcut

Overview Schema Source Related Servers Discussions Admin

unspoken_rm

Destructive

Restore a word marked as unspoken back into captions and verification. Use word index or phrase to remove the mark without editing the transcript file.

Instructions

Unmark a word unspoken_add marked, putting it back into captions and verify.

Address it by word_index, or by a phrase resolving to exactly one word. Refuses a word that is not marked. The transcript file is never edited either way — a mark is a manifest entry — so no cue or caption renumbers. unspoken_ls lists the marks; undo restores 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.
`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 has to resolve to exactly one word.
`clip_id`	Yes	The transcript holding the marked word.
`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 marked word. 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 holding the marked word."

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 has to resolve to exactly one word."

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 marked word. 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: -"unspoken_rmArguments"
```

First observedv0.24.0Sep 15, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations mark this as destructive (destructiveHint=true) and not read-only. The description adds key nuance: the transcript file is never edited, only a manifest entry changes, so no renumbering occurs. It also discloses the refusal behavior for unmarked words. This adds value beyond the annotations and clarifies the actual 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 composed of three sentences, each carrying distinct information: the core action, the addressing method and refusal, and the side-effect transparency plus sibling pointers. It is front-loaded with the primary purpose and avoids fluff. Slightly longer than minimal but well-organized.

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 tool with six parameters and an output schema, the description covers the essential behavioral aspects: what it does, how to address, refusal, side effects, and related tools. It doesn't repeat parameter details already in the schema, and the output format is presumably covered by the output schema. It is complete enough for an agent to invoke 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?

The input schema already describes all six parameters in detail (100% coverage), including word_index, phrase, clip_id, after, occurrence, and path. The description reiterates that addressing is by word_index or a phrase resolving to exactly one word, but this is already in the schema. It does not add new parameter-specific semantics, so the baseline of 3 is appropriate.

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 states a specific action ('Unmark a word'), names the resource type (word marked by unspoken_add), and gives the effect (putting it back into captions and verify). It explicitly references the sibling unspoken_add, which differentiates it clearly from other tools like unspoken_ls and undo.

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 gives clear addressing options (word_index or phrase) and notes the refusal of unmarked words. It mentions alternatives: unspoken_ls lists marks and undo restores one, which helps an agent choose between them. However, it doesn't explicitly state conditions like 'use when you want to remove a mark' vs 'use undo to revert a removal', but the context is sufficient.

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

Deploy Server