proofcut

Overview Schema Source Related Servers Discussions Admin

attribute_speakers

Idempotent

Assign each spoken word to the speaker whose mic was loudest, using the existing transcript without re-transcribing. Reports ambiguous spans for human review, with optional apply.

Instructions

Label each word with the mic that was loudest while it was spoken.

For a co-hosted recording captured on one mic per speaker. It is one pass over the transcript that is already attached — never a second ASR run, and transcribing each mic separately is measured and dead: half of each mic's own transcript is the other person, at every isolation tried. Transcribe once, from the mix or either mic, then call this.

streams are ffmpeg audio ordinals into the registered container (0, 1), and labels names them in the same order — one label per stream, defaulting to speaker1, speaker2. The speaker lands on the word: it is a label and never an address, so every cue, description, mark, music anchor and caption still resolves through (clip_id, word_index) and nothing else moves.

It reports; it does not decide below the floor. apply is off by default. The rule is ~99% correct per word on clear speech and at chance on words spoken over each other, and margin_db is what half-knows the difference — anything under it comes back in ambiguous_spans to go and listen to, with the three words either side. Read unmeasurable separately from ambiguous: it means the mics ran out before the transcript did, which is a different recording problem. Applying keeps any label already on a word this refuses to call.

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.
`apply`	No	Write the labels onto the words. Off by default — it reports first, and applying keeps any label already on a word this refuses to call.
`limit`	No	How many ambiguous spans to return; the reply also says how many there are in total.
`labels`	No	What to call each stream, in the same order — one per stream. Unset, `speaker1`, `speaker2`.
`clip_id`	Yes	The co-hosted clip: one container, one mic per speaker, one transcript already attached.
`streams`	No	Which audio streams the speakers are on, as ffmpeg audio ordinals (`[0, 1]`). Unset, the container's readable audio streams in order.
`margin_db`	No	How much louder one mic has to be to be believed, in dB. It reports a default and is not a threshold to trust: on words spoken over each other the rule is at chance, and anything under this margin comes back in `ambiguous_spans` to go and listen to.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedv0.25.0Sep 16, 2026

addedInput schema / properties / apply / description

Added value: +"Write the labels onto the words. Off by default — it reports first, and applying keeps any label already on a word this refuses to call."

removedInput schema / properties / apply / title
```
Removed value: -"Apply"
```

addedInput schema / properties / clip_id / description

Added value: +"The co-hosted clip: one container, one mic per speaker, one transcript already attached."

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

removedInput schema / properties / labels / anyOf

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

addedInput schema / properties / labels / description

Added value: +"What to call each stream, in the same order — one per stream. Unset, `speaker1`, `speaker2`."

addedInput schema / properties / labels / items
```
Added value: +{
+  "type": "string"
+}
```
removedInput schema / properties / labels / title
```
Removed value: -"Labels"
```
addedInput schema / properties / labels / type
```
Added value: +[
+  "array",
+  "null"
+]
```

addedInput schema / properties / limit / description

Added value: +"How many ambiguous spans to return; the reply also says how many there are in total."

removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```

addedInput schema / properties / margin_db / description

Added value: +"How much louder one mic has to be to be believed, in dB. It reports a default and is not a threshold to trust: on words spoken over each other the rule is at chance, and anything under this margin comes back in `ambiguous_spans` to go and listen to."

removedInput schema / properties / margin_db / title
```
Removed value: -"Margin Db"
```

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 / streams / anyOf

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

addedInput schema / properties / streams / description

Added value: +"Which audio streams the speakers are on, as ffmpeg audio ordinals (`[0, 1]`). Unset, the container's readable audio streams in order."

addedInput schema / properties / streams / items
```
Added value: +{
+  "type": "integer"
+}
```
removedInput schema / properties / streams / title
```
Removed value: -"Streams"
```
addedInput schema / properties / streams / type
```
Added value: +[
+  "array",
+  "null"
+]
```

removedInput schema / title

Removed value: -"attribute_speakersArguments"

First observedv0.24.0Sep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint false, idempotentHint true), the description discloses behavior richly: it reports without applying by default, keeps existing labels on words it refuses to call, distinguishes 'unmeasurable' from 'ambiguous', and states accuracy figures (~99% on clear speech, chance on overlap). It also explains that margin_db is not a threshold to trust, which is a nuanced behavioral caveat.

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 long, but it is well-structured with bold headings and logical flow: purpose first, then how it differs from alternatives, then parameter explanations, then behavioral caveats. Each sentence earns its place; nothing is redundant. It is appropriately detailed for a complex tool with many edge cases, though it could be tightened slightly.

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 tool's complexity (7 parameters, output schema present, multiple edge cases), the description covers everything an agent needs: the core operation, when to use it, how parameters interact, the difference between ambiguous and unmeasurable, and the apply behavior. The presence of an output schema further reduces the burden of explaining return values. Nothing critical 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?

The input schema already provides descriptions for all 7 parameters (100% coverage), so the baseline is 3. The description adds significant meaning beyond the schema: it explains streams as ffmpeg audio ordinals in order, labels as names in the same order, margin_db as a reporting floor rather than a decision threshold, and the interplay between apply and existing labels. This extra context lifts the score to 4.

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 crisp, specific verb-resource statement: 'Label each word with the mic that was loudest while it was spoken.' This clearly distinguishes it from transcription tools (transcribe, hear) and from tools that manipulate transcript structure. It also frames the tool as a post-transcription step, which separates it from ASR workflows.

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 when-to-use and when-not-to-use guidance: it is a single pass over an attached transcript, never a second ASR run, and it warns that transcribing each mic separately is 'measured and dead' with concrete evidence. It also tells the user to transcribe once first, then call this tool. This is actionable and leaves no ambiguity about prerequisites.

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

Deploy Server