Skip to main content
Glama

cut_by_transcript

Destructive

Cut or keep video segments by selecting transcript word ranges, pad cuts into surrounding silence, and preview changes before applying.

Instructions

Cut or keep inclusive word ranges, e.g. cut=[[30, 45], [120, 131]].

Pass exactly one of cut or keep. pad widens each range on both sides in seconds, to land the cut in the silence between words. The timeline is snapshotted first, so this is undoable.

Every range echoes back the words it resolved to, plus the few words either side of it — an index one past the intended phrase reads fine on its own and is only visibly wrong next to its neighbours. pad_reach names any neighbour the padding eats, since padding is in seconds and the echoed text is not.

through_pause=True (cut only) extends each range's trailing edge through the pause after its last word, whenever that gap is wide enough to have drawn a [N.Ns] marker in the transcript pane — so cutting a phrase also removes the dead air after it instead of leaving it playing. A no-op when the trailing gap is too short to have drawn a marker.

plan=True returns that whole payload — including what the timeline would become — without writing anything. Prefer it over cutting and undoing.

Refused if a range's first or last word claims a suspect duration (see attach_transcript/transcribe's suspect_durations) — that word's end/start is what the cut boundary resolves to, and it is usually hiding a retake rather than ending where it claims. Check the word, then retry with confirm_suspect=True if the boundary is actually fine. Under plan=True these are reported as suspect_boundaries instead of refused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cutNoInclusive word ranges to remove, e.g. `[[30, 45], [120, 131]]`. Pass exactly one of `cut` or `keep`.
padNoWiden each range on both sides, in seconds, so the cut lands in the silence between words rather than on them. `pad_reach` names any neighbour the padding eats.
keepNoInclusive word ranges to keep, everything else going. Pass exactly one of `cut` or `keep`.
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.
planNoResolve the whole call and report what it would do, writing nothing. Prefer it over doing the thing and undoing it.
clip_idYesThe transcript the word ranges address.
through_pauseNoExtend each cut's trailing edge through the pause after its last word, wherever that gap was wide enough to draw a `[N.Ns]` marker — so cutting a phrase also takes the dead air after it. A no-op when the gap is short.
confirm_suspectNoGo ahead even though a boundary word claims a suspect duration. Read the echoed words first — a suspect duration usually means whisper hid a retake inside that word, so the edge is not where it reads.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed25 schema fields changedv0.25.0
    • addedInput schema / properties / clip_id / description
      Added value: +"The transcript the word ranges address."
    • removedInput schema / properties / clip_id / title
      Removed value: -"Clip Id"
    • addedInput schema / properties / confirm_suspect / description
      Added value: +"Go ahead even though a boundary word claims a suspect duration. Read the echoed words first — a suspect duration usually means whisper hid a retake inside that word, so the edge is not where it reads."
    • removedInput schema / properties / confirm_suspect / title
      Removed value: -"Confirm Suspect"
    • removedInput schema / properties / cut / anyOf
      Removed value: -[
      -  {
      -    "items": {
      -      "items": {
      -        "type": "integer"
      -      },
      -      "type": "array"
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / cut / description
      Added value: +"Inclusive word ranges to remove, e.g. `[[30, 45], [120, 131]]`. Pass exactly one of `cut` or `keep`."
    • addedInput schema / properties / cut / items
      Added value: +{
      +  "items": {
      +    "type": "integer"
      +  },
      +  "type": "array"
      +}
    • removedInput schema / properties / cut / title
      Removed value: -"Cut"
    • addedInput schema / properties / cut / type
      Added value: +[
      +  "array",
      +  "null"
      +]
    • removedInput schema / properties / keep / anyOf
      Removed value: -[
      -  {
      -    "items": {
      -      "items": {
      -        "type": "integer"
      -      },
      -      "type": "array"
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / keep / description
      Added value: +"Inclusive word ranges to keep, everything else going. Pass exactly one of `cut` or `keep`."
    • addedInput schema / properties / keep / items
      Added value: +{
      +  "items": {
      +    "type": "integer"
      +  },
      +  "type": "array"
      +}
    • removedInput schema / properties / keep / title
      Removed value: -"Keep"
    • addedInput schema / properties / keep / type
      Added value: +[
      +  "array",
      +  "null"
      +]
    • addedInput schema / properties / pad / description
      Added value: +"Widen each range on both sides, in seconds, so the cut lands in the silence between words rather than on them. `pad_reach` names any neighbour the padding eats."
    • removedInput schema / properties / pad / title
      Removed value: -"Pad"
    • 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 / plan / description
      Added value: +"Resolve the whole call and report what it would do, writing nothing. Prefer it over doing the thing and undoing it."
    • removedInput schema / properties / plan / title
      Removed value: -"Plan"
    • addedInput schema / properties / through_pause / description
      Added value: +"Extend each cut's trailing edge through the pause after its last word, wherever that gap was wide enough to draw a `[N.Ns]` marker — so cutting a phrase also takes the dead air after it. A no-op when the gap is short."
    • removedInput schema / properties / through_pause / title
      Removed value: -"Through Pause"
    • removedInput schema / title
      Removed value: -"cut_by_transcriptArguments"
  2. First observedv0.24.0

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations' destructiveHint, the description discloses crucial behavioral traits: the timeline is snapshotted so the operation is undoable, `plan=True` writes nothing, `pad_reach` and echoed-word feedback explain boundary effects, and suspect durations trigger refusal or `suspect_boundaries` reporting. This is rich, non-obvious behavioral disclosure.

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 long but every sentence carries distinct value: main operation first, then mutually exclusive parameters, then side effects, then safety/refusal behavior. The structure is logical and front-loaded; the length is justified by the tool's complexity.

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 destructive nature, eight parameters, and existing output schema, the description is complete: it covers what happens, what not to do, how to preview safely, how to handle suspect boundaries, and how padding interacts with echoes. An agent has enough context to invoke this correctly.

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

Parameters5/5

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

Even though schema coverage is 100%, the description substantially enriches the parameters: it explains what `pad` does in seconds, what `through_pause` means semantically, how `plan` differs from execution, and what `confirm_suspect` is for. This goes well beyond the baseline schema descriptions.

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 opening sentence states a specific verb and resource: 'Cut or keep inclusive word ranges', with a concrete example showing the exact input shape. This clearly distinguishes it from the sibling `cut_by_time`, which operates on time rather than transcript word ranges.

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 gives explicit constraints ('Pass exactly one of `cut` or `keep`'), mode-specific guidance (`through_pause=True` is cut-only, `plan=True` is preferred over acting and undoing), and a detailed refusal-and-retry workflow for suspect boundaries. These are actionable instructions an agent can follow without inferring.

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