This server enables automated transcription QA: Whisper transcription plus detection, repair, scoring, and cost estimation.
Transcribe audio files through Whisper from a local path (WAV/MP3/M4A/FLAC), returning timed text segments with confidence scores and selectable ISO language code.
Run all built-in hallucination detectors on a transcript JSON payload, covering repetition loops, silence/prompt echoes, subtitle phantoms, timing drift, language switches, and completeness issues, yielding severities and evidence.
Apply an LLM-based repair pass to flagged transcript segments, letting the model delete or replace bad content or explicitly leave it untouched while reporting actions with confidence and rationale.
Compute transcript quality metrics such as WER, CER, hallucination rate, and words-per-minute, optionally scored against a supplied reference text.
Estimate processing expense for a known audio duration, including Whisper usage, potential LLM repair overhead under an assumed hallucination-rate parameter, and overall totals.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@trusted-transcription Detect hallucinations in transcript.json and repair any critical flags."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Catch confident lies in automatic transcription — and stop most of them before they exist.
Whisper produces this on 30 seconds of silence:
"Thank you for watching. Please subscribe to my channel."
Confidence: 0.88. No error, no warning. Your downstream system ingests it as fact.
This project comes from a transcription platform where a wrong word is a legal liability. Everything in it was learned in production, measured against a control, and shipped: the detectors that catch the lies, the guards that keep the repair honest, and the prevention layer that removes the cause.
guillain-rdcde.github.io/Trusted-Transcription — paste a transcript or load a sample, press Detect. The same detectors run in your browser; nothing is uploaded.
Related MCP server: rush
git clone https://github.com/Guillain-RDCDE/Trusted-Transcription.git
cd Trusted-Transcription
pip install -e .
tt detect corpus/sample/silence_hallucination.json --format table SEG SEVERITY DETECTOR REASON
--------------------------------------------------------------------------------
2 critical silence_hallucination Known phantom phrase: 'Thank you for watching...'
4 critical repetition_loop N-gram 'nous avons constate' repeated 3x in 8 segments
6 critical temporal_drift Timestamp stall: segments 5 and 6 share [55.30-55.30]
Total: 3 flagsZero API calls, and nothing on the clean sample:
tt detect corpus/sample/clean_transcript.json --format table
# No hallucinations detected.Three small dependencies and no API client. Engines and the repair model are
optional (pip install -e ".[api]"). Or without installing anything:
docker build -t tt . && docker run --rm tt cost 60Prevents. Most phantom phrases are not the model's fault. They appear on
segments your pipeline starved — a few seconds cut at a photo timestamp or a
speaker turn, with no context. tt windows shows what the model will hear once
each short segment gets audio on both sides; boundaries never move. Long files
are cut in nine-minute pieces with the cap on the piece, never on the file, and
the proof that nothing was lost is the sum of the durations (tt chunks).
Detects. Phantom phrases in six languages, repetition loops, a whole output that is a loop, the vocabulary prompt returned instead of the audio, timestamps that drift, a language switch, a line mixing writing systems after which nothing follows the audio any more, minutes of speech with zero words, sections silently dropped, a name spelled letter by letter next to the misheard word. Deterministic, auditable, no model in the loop.
Repairs without making things worse. The correction model can swallow a
paragraph or lengthen a text until the end repeats; both are caught by
comparing what it was sent with what it returned, and the recovery splits the
text rather than falling back on the raw draft. A broken chunk is
re-transcribed alone, never the whole file. A spelled-out name overrides the
dictated one (tt spell).
Measures honestly. Every number in the docs was read against a control run,
because Whisper is not deterministic. Comparing engines takes two measures or
none, and a judge you know is biased (tt bench-report).
Reference — every command, every detector, the MCP server, and the Python entry points.
Failure modes — the catalog, with the control that catches each one.
Architecture decisions — why two models in series, why deterministic before probabilistic, and each production incident that turned into a rule. The dead ends are in there too; they are the reason the claims are credible.
Measurement pitfalls — six ways a transcription benchmark lies, learned the expensive way.
MIT — Guillain d'Erceville — guillain@poulpe.us — GitHub — LinkedIn
Run all hallucination detectors on a transcript. Returns a list of flags with severity, detector name, and evidence. Detectors: repetition_loop, silence_hallucination, prompt_echo, temporal_drift, phantom_subtitle, language_switch, completeness.
| Name | Required | Description | Default |
|---|---|---|---|
| transcript_json | Yes | JSON string of a TranscriptResult |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return shape and enumerates the detectors, which is useful. However, it does not state whether this operation mutates anything, requires prior transcription, or has any side effects or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, with the main action and output in the first sentence and an exhaustive but relevant detector list in the second. Every part earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description explains both input context and output fields. It does not elaborate on what 'TranscriptResult' is or what each detector checks, but the sibling tool transcribe and the detector names supply enough context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter is already described as 'JSON string of a TranscriptResult'. The description adds no further parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Run all hallucination detectors') on a specific resource ('a transcript') and clearly describes the output (flags with severity, detector name, evidence). The detector list differentiates it from siblings like transcribe, repair, score, and estimate_cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Run all hallucination detectors on a transcript' makes the intended use case clear: after transcription, when hallucination detection is needed. It does not explicitly name alternatives or exclusions, but the sibling names make the context obvious enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate processing cost for a given audio duration. Returns breakdown: Whisper API cost, LLM repair cost (if needed), total.
| Name | Required | Description | Default |
|---|---|---|---|
| audio_duration_minutes | Yes | Duration of audio in minutes | |
| expected_hallucination_rate | No | Expected fraction of segments needing repair (0-1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It explains that the tool estimates cost and returns a breakdown, implying a read-only calculation. However, it does not explicitly state that no actual transcription/repair occurs, nor does it disclose pricing assumptions or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The action and resource are front-loaded, and the return breakdown is stated concisely. Every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two parameters and no output schema, the description is largely complete: it names the input and explicitly lists return components. A small gap is the absence of any statement about side effects or calculation basis, but this does not hinder correct calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context by naming 'LLM repair cost (if needed)', which hints at how expected_hallucination_rate factors in, but it does not substantially extend the parameter meaning already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('estimate'), a specific resource ('processing cost'), and the input ('audio duration'), then states the output breakdown. This clearly distinguishes it from the processing-oriented siblings transcribe, detect_hallucinations, repair, and score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is for estimating cost before processing, with no mention of alternatives or exclusions. Context is strong enough for an agent to select it when a cost estimate is needed, but it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the LLM repair loop on flagged segments. The LLM can delete fabricated segments, replace them, or decline to touch them. Returns structured repair actions with confidence and reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| transcript_json | Yes | JSON string of a TranscriptResult with flags |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It openly states that the LLM can delete fabricated segments, replace them, or decline to touch them, and that it returns structured repair actions with confidence and reasoning. This gives the agent a solid picture of the tool's autonomy and output without relying on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences that front-load the primary action, then add behavioral detail and output shape. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description adequately explains the input context (flagged segments), the behavior (delete/replace/decline), and the output shape (structured actions with confidence and reasoning). Slightly more detail about whether actions are applied directly or returned as suggestions would be helpful, but it is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents 'transcript_json' as a JSON string of a TranscriptResult with flags. The description adds workflow context but does not elaborate on the parameter itself, so it neither harms nor significantly improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Run the LLM repair loop') and a clear resource ('flagged segments'), while also enumerating the possible actions the LLM can take (delete, replace, or decline). This clearly differentiates 'repair' from siblings like 'detect_hallucinations' or 'score', which operate at earlier or different stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'on flagged segments' provides clear context that this tool is intended for transcripts that have already been flagged, presumably by 'detect_hallucinations'. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute quality metrics: WER, CER, hallucination rate, words per minute. If a reference transcription is provided, computes accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| reference_text | No | Reference transcription to score against (optional) | |
| transcript_json | Yes | JSON string of a TranscriptResult |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses what metrics are computed and the conditional behavior around reference text, but it does not mention whether the tool mutates anything, what it returns, or how it handles missing reference text beyond omitting accuracy. For a pure computation tool this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The metrics are listed up front, and the conditional behavior is stated second. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter computation tool with fully documented schema, the description is nearly complete. The only notable gap is that it does not describe the output shape or explicitly differentiate from detect_hallucinations, but this is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents transcript_json and reference_text. The description adds the metric names and the role of reference_text in computing accuracy, but it does not add material detail about parameter formats or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Compute'), a clear resource (transcript quality), and enumerates the exact metrics: WER, CER, hallucination rate, words per minute. This distinguishes it from siblings like transcribe and estimate_cost, and the conditional accuracy clause adds further precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool to score transcript quality metrics. However, it does not explicitly state when to prefer this over detect_hallucinations, which also overlaps with 'hallucination rate', nor does it mention any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe an audio file using Whisper. Returns segments with timestamps, text, and confidence scores.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ISO 639-1 language code | fr |
| audio_path | Yes | Path to the audio file (wav, mp3, m4a, flac) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure and does a solid job by stating not only the action but the exact return payload: 'segments with timestamps, text, and confidence scores.' It also names the underlying engine, Whisper, which helps set expectations. It does not detail limitations or prerequisites, but the described behavior is concrete and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence that front-loads the core purpose and follows with the output structure. There is no wasted phrasing or redundant information, and every word contributes to an agent's understanding of what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only two parameters, no output schema, and no annotations, the description covers the essential elements: what it does, how it does it, and what it returns. It could add guidance about how this step fits with sibling tools like detect_hallucinations or repair, but that omission does not prevent correct use of the tool itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters, audio_path and language. The description adds no extra meaning about either parameter, such as default language behavior or audio format handling. The baseline score of 3 is appropriate because the schema does the heavy lifting and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair, 'Transcribe an audio file using Whisper', and clearly distinguishes this tool from sibling tools like detect_hallucinations, repair, score, and estimate_cost, which operate on transcription results rather than producing them. It is immediately obvious what this tool does and how it differs from others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: whenever an audio file needs to be transcribed. It names the input type and the model used, providing clear context. It does not explicitly discuss when not to use it or compare to alternatives, but the sibling names suggest downstream processing rather than competing transcription options, so the basic usage context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0detect_hallucinationsestimate_costrepairscoretranscribeScored across 5 tools
Each tool maps to a distinct stage in the transcription workflow: transcribe, detect hallucinations, repair, score, and estimate cost. There is no functional overlap or ambiguity about which tool to select.
Most tools follow a verb_noun pattern (detect_hallucinations, estimate_cost), while transcribe, repair, and score are single verbs. The naming is still consistent in style and domain, with no mixed casing or confusing variations.
Five tools is well-scoped for an audio transcription quality pipeline. Each tool serves a clear purpose and the set is neither bloated nor thin.
The toolset covers the full core pipeline: transcription, hallucination detection, LLM-based repair, quality scoring, and cost estimation. A minor gap is the lack of separate transcript retrieval or manual editing tools, but repair covers corrections reasonably.
Transcribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
Transcribe audio & video: diarization, timed SRT/VTT, podcasts, paste-a-link, whole-feed batch.
Transcribe audio and video into speaker-labelled transcripts, subtitles, clips, and cited Q&A.
Transform video, audio and images, and generate media from prompts. FFmpeg, captions, models.
