proofcut

Overview Schema Source Related Servers Discussions Admin

transcript_checks

Read-onlyIdempotent

Re-checks an attached transcript against itself to find overlaps, repeats, near-duplicates, and suspect durations before you rely on it or render. Read-only.

Instructions

Re-check an already-attached transcript against itself.

Returns the same four findings attach_transcript does — near_duplicates, suspect_durations, overlaps, repeats — for a transcript attached earlier, whose findings were reported once and are otherwise gone. Omit clip_id for every clip that has a transcript.

Read overlaps before anything derived from this transcript is drawn on screen. A seam there is whisper reading across a retake splice and interleaving both takes, which invents words nobody said — and they read as ordinary English, so a human proofread finds some and is blind to the rest. repeats catches the other shape a retake takes: one that survived transcription as distinct, cleanly-timed duplicated words rather than as an interleaved seam.

cut runs the repeat finder over the words the timeline plays, so a retake the edit kept is named before a render: each side's clip_id and word range, ready for cut_by_transcript. Candidates, not verdicts: a line written to repeat reads the same. None before seeding. Reads only; it never writes.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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`	No	One clip to re-check. Omit it for every clip that has a transcript.

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

removedInput schema / properties / clip_id / anyOf

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

addedInput schema / properties / clip_id / description

Added value: +"One clip to re-check. Omit it for every clip that has a transcript."

removedInput schema / properties / clip_id / title
```
Removed value: -"Clip Id"
```
addedInput schema / properties / clip_id / type
```
Added value: +[
+  "string",
+  "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 / title

Removed value: -"transcript_checksArguments"

First observedv0.24.0Sep 15, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent and non-destructive, yet the description adds substantive traits: 'Reads only; it never writes,' the 'None before seeding' state, and that results are candidates not verdicts (a line written to repeat reads the same). It also explains the concrete failure mode overlaps detects, which annotations cannot 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?

Front-loaded with the core action and the returned findings before the diagnostic rationale, and every paragraph is thematically coherent. It is on the long side and spends real estate on the whisper/retake narrative, but that content is decision-relevant rather than filler.

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?

With an output schema, 100% parameter coverage and full annotations, the description only needs to supply intent and caveats, which it does. Minor gap: it enumerates four findings, then introduces `cut` separately without stating whether it is a fifth returned key or a distinct mode, leaving a small ambiguity.

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 both parameters (path, clip_id) are already fully documented in the schema. The description only restates the clip_id omission rule and adds no syntax or format detail beyond it, so the baseline 3 applies.

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?

States a specific verb and resource ('Re-check an already-attached transcript against itself') and immediately distinguishes scope from the sibling attach_transcript by naming the exact four findings both return and the condition that separates them (already attached, findings otherwise gone). An agent can tell it apart from attach_transcript and get_transcript without opening a schema.

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?

It gives a clear when-to-use rule ('for a transcript attached earlier, whose findings were reported once and are otherwise gone') and an operating instruction ('Omit clip_id for every clip that has a transcript' / 'Read overlaps before anything derived from this transcript is drawn on screen'). It stops short of an explicit when-not-to-use or a named either/or against attach_transcript, but context is unambiguous.

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

Deploy Server