Detecta mentiras con alta confianza en la transcripción automática.
Whisper produce esto cuando hay 30 segundos de silencio:
"Gracias por vernos. Por favor, suscríbete a mi canal."
Confianza: 0.88. Sin error, sin aviso. Tu sistema posterior lo consume como un hecho.
Este proyecto detecta eso — y otras seis formas en las que los pipelines de ASR producen basura en silencio.
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 tableSalida:
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 flagsTres alucinaciones detectadas. Cero llamadas a la API. Cero falsos positivos en la muestra limpia:
PYTHONPATH=src python -m trusted_transcription.cli detect corpus/sample/clean_transcript.json --format table
# No hallucinations detected.Related MCP server: this-needs-a-call
Audio -> Whisper -> [7 detectors] -> [LLM repair] -> [scoring] -> Trusted transcriptLa detección es determinista. No hay ningún LLM en el bucle hasta que se activa una alerta. Los 7 detectores son regex, aritmética y estadística: se ejecutan en 0.06 segundos, no cuestan nada y nunca alucinan por sí mismos.
La corrección es limitada. El LLM (Claude) recibe únicamente salida estructurada, un umbral de confianza de 0.7 y permiso explícito para decir "No toco esto." La corrección sin restricciones empeora las cosas el 23% de las veces (ADR 0004 documenta el experimento).
El humano permanece en el bucle en las alertas críticas que el LLM no puede resolver. ~70% de las transcripciones pasan sin supervisión; el resto se enruta a revisión con los segmentos exactos resaltados.
Detector | Qué detecta | Cómo |
| Misma frase de 5 a 50 veces | Frecuencia de n-gramas en ventana deslizante |
| "Gracias por vernos" en silencio | Patrones fantasma conocidos + ratio palabra/segundo |
| El prompt del sistema se filtra en la salida | Coincidencia de patrones en marcadores de instrucción |
| Las marcas de tiempo se solapan, se invierten o se detienen | Aritmética por pares en segmentos consecutivos |
| Texto coherente sin relación con el contexto | Distancia de Jaccard con el vocabulario vecino |
| La transcripción en francés se vuelve inglés | Etiqueta de idioma + marcadores de palabras funcionales |
| Secciones omitidas en silencio | Ratio de cobertura + palabras por minuto |
El modo 7 es el más peligroso: todas las demás alucinaciones producen basura visible. Esta no produce nada — y nada parece correcto.
Catálogo completo con síntomas y causas: docs/failure-modes.md
PYTHONPATH=src python -m trusted_transcription.mcp_server5 herramientas expuestas a través de stdio: transcribe, detect_hallucinations, repair, score, estimate_cost. Cualquier agente compatible con MCP puede manejar el pipeline.
Configuración de Claude Code:
{"mcpServers": {"trusted-transcription": {"command": "tt-mcp"}}}PYTHONPATH=src python -m trusted_transcription.cli cost 60
# Whisper API: $0.3600
# LLM repair: $0.0360
# Total: $0.3960
# Per hour: $0.40¿Por qué dos modelos en lugar de un ajuste fino? ¿Dónde queda el humano? ¿Por qué lo determinista antes que lo probabilístico?
0001 — Dos modelos en serie (se probó un ajuste fino LoRA y se abandonó)
pip install pytest
PYTHONPATH=src python -m pytest tests/ -v
# 13 passed in 0.06sSin llamadas a la API, sin archivos de audio. Lógica pura sobre transcripciones sintéticas.
Esta es la capa de calidad genérica extraída de una plataforma de transcripción de grado legal en producción. La plataforma procesa dictados formales donde una palabra equivocada supone una responsabilidad legal: un pipeline de Whisper + Claude que funciona sin supervisión en ~70% de los casos, en una flota de nueve servidores, con facturación diaria.
El código de la plataforma está bajo NDA. Las técnicas, los detectores y las decisiones de arquitettura se publican aquí. Los callejones sin salida también — están en los ADR, y son la razón por la que las afirmaciones sobre el sistema de producción son creíbles.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Guillain-RDCDE/Trusted-Transcription'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
