This server provides a full pipeline for transcription quality control: transcribe audio with Whisper, detect hallucinations, optionally repair flagged segments, score the transcript, and estimate processing costs.
transcribe – Convert an audio file (wav, mp3, m4a, flac) into a transcript with timestamps, text, and confidence scores, optionally specifying the language.
detect_hallucinations – Run seven detectors (repetition_loop, silence_hallucination, prompt_echo, temporal_drift, phantom_subtitle, language_switch, completeness) on a transcript and get flagged issues with severity and evidence.
repair – Use an LLM-driven loop to delete, replace, or keep flagged segments, returning structured repair actions with confidence and reasoning.
score – Compute quality metrics such as WER, CER, hallucination rate, and words per minute; optionally compare against a reference transcription for accuracy.
estimate_cost – Estimate processing cost based on audio duration and expected hallucination rate, showing Whisper API cost, LLM repair cost, and total.
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.
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 catches that — and six other ways ASR pipelines silently produce garbage.
git clone https://github.com/Guillain-RDCDE/Trusted-Transcription.git
cd Trusted-Transcription
pip install pydantic click jiwer
PYTHONPATH=src python -m trusted_transcription.cli detect corpus/sample/silence_hallucination.json --format tableOutput:
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 flagsThree hallucinations caught. Zero API calls. Zero false positives on the clean sample:
PYTHONPATH=src python -m trusted_transcription.cli detect corpus/sample/clean_transcript.json --format table
# No hallucinations detected.Related MCP server: rush
Most of those 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. Give the model more audio than the segment and keep only the words that belong to it:
PYTHONPATH=src python -m trusted_transcription.cli windows corpus/sample/forced_cuts.jsonBoundaries never move. In production this removed almost all phantom phrases at once. ADR 0005 has the measurements — and the two variants that looked better and were refused.
Reference — how it works, the context window, the seven detectors, the MCP server, cost estimation, the architecture decisions, the measurement pitfalls, and where this came from.
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.
