Skip to main content
Glama

unspoken_add

Idempotent

Mark a transcript word that was never spoken in the recording, so captions and verification stop expecting it. Address by word index or phrase.

Instructions

Mark a word the transcript holds and the recording never said.

Whisper transcribes straight across a retake splice and emits words from both takes interleaved, so words appear in the index that nobody said. They are in the transcript and nowhere else — not the audio, not the render — so captions draw them and verify expects them.

This writes a mark beside the transcript and never touches the transcript itself: word indices must not renumber, or every cue pointing at one would move. Captions, caption_view and verify all stop expecting the word; no audio, timing or shot changes, because the seconds around it are the take that was kept. Echoes the word it resolved to, plus three either side.

Addressed by word_index or phrase — but unlike cue_add, a phrase resolving to more than one word is refused rather than bound to an edge: unspoken addresses exactly one word, and picking a side of a wider match would silently mark the wrong one half the time. Narrow the phrase, or pass occurrence= if it is disambiguation rather than width.

Prefer unspoken_detect to find them: it is evidence rather than reading, and reading for sense provably misses the grammatical ones.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoThe 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.
afterNoA forward cursor over a phrase's matches: any match at or before this word index is skipped. -1, the default, means from the start.
phraseNoAddress it by wording instead — but unlike `cue_add`, a phrase matching more than one word is refused rather than bound to an edge: a mark addresses exactly one word.
clip_idYesThe transcript holding the word.
occurrenceNoDisambiguate 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_indexNoThe word to mark. Give this or `phrase`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed21 schema fields changedv0.25.0
    • 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 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 — but unlike `cue_add`, a phrase matching more than one word is refused rather than bound to an edge: a mark addresses 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 word to mark. 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_addArguments"
  2. First observedv0.24.0

TDQS

A4.9/5.0
Behavior5/5

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

The description details side effects beyond the annotations: it 'writes a mark beside the transcript and never touches the transcript itself,' ensuring word indices don't renumber, and that captions, caption_view, and verify stop expecting the word. It also clarifies no audio/timing/shot changes occur. Since annotations only state readOnlyHint=false and idempotentHint=true, this adds substantial behavioral context without contradicting any structured hint.

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?

Every sentence earns its place: purpose, cause, side effects, addressing semantics, and guidance are organized logically. It is front-loaded with the core action, then expands into rationale and constraints. Despite its length, there is zero filler—each paragraph serves a distinct purpose.

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?

For a tool with six parameters and an output schema, the description covers all essential aspects: how to address a word (index or phrase), disambiguation rules, side effects on downstream systems, and the recommended sibling tool. It also mentions the refusal behavior for ambiguous phrases, which is critical for correct usage. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the behavioral difference between word_index and phrase (refusal on multi-word matches), the meaning of occurrence as 1-based disambiguation, and the interaction with `after`. While not strictly necessary given the schema, these clarifications improve selection and invocation confidence.

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 precise verb and resource: 'Mark a word the transcript holds and the recording never said.' It immediately explains the root cause (Whisper splicing artifacts) and contrasts with siblings like cue_add and unspoken_detect, making the tool's unique role unmistakable. An agent can instantly distinguish it from similar editing tools.

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 directs users to 'Prefer `unspoken_detect` to find them' and explains why reading is insufficient. It also contrasts with cue_add, stating that ambiguous phrases are refused rather than bound to an edge, and clarifies when to narrow or use occurrence. This gives clear when-to-use and when-not-to-use guidance with concrete alternatives.

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