audio-transcriber

Transcribe Audio

transcribe_audio

Idempotent

Convert spoken audio from files or microphone recordings into text, optionally translate to English, and export transcripts as TXT or SRT.

Instructions

Transcribes audio from a provided file or by recording from the microphone.

Input Schema

Name	Required	Description	Default
`fp16`	No	Use FP16 for faster inference.
`task`	No	Task to perform: 'transcribe' or 'translate' (to English).	transcribe
`model`	No	Whisper model to use (e.g., 'base', 'small', 'turbo').	base
`backend`	No	Transcription backend to use: 'faster-whisper' or 'openai-whisper'. Defaults to auto-detect (preferring faster-whisper).
`language`	No	Language code for transcription (e.g., 'en', 'fr'). Auto-detected if not specified.
`directory`	No	Directory for saving recordings or exports.	/root/.local/share/audio-transcriber
`audio_file`	No	Path to the audio file to transcribe. If provided, transcription is performed on this file.
`temperature`	No	Temperature for sampling diversity (0.0 for deterministic).
`export_formats`	No	Formats to export the transcription (e.g., ['txt', 'srt']).
`initial_prompt`	No	Initial text prompt to guide the transcription.
`record_seconds`	No	Number of seconds to record audio from microphone. Must be positive if no audio_file is provided. 0 or negative not supported for recording in this context.
`word_timestamps`	No	Include word-level timestamps in the output.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.3.6Oct 24, 2026

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare idempotent=true, destructive=false and openWorld=false, so the safety profile is covered. The description adds the useful behavioral fact that input can come from a file or live microphone, but says nothing about where exports are written, whether the call blocks during recording, or microphone permissions.

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?

A single front-loaded sentence with zero padding. It is efficient, though it borders on under-specification for a 12-parameter tool rather than being genuinely concise in a way that helps.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a 12-parameter tool that can record from a microphone and write exported files, yet the description never explains the required source combination, where output lands, or call duration behavior. An output schema and annotations exist, but they cannot cover source-selection rules or side-effect semantics the agent needs before calling.

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 all 12 parameters are documented in the schema; baseline 3 applies. The description only reinforces the audio_file vs record_seconds distinction and adds no format, default, or interaction detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('transcribes audio') and two source modes, so the basic action is clear. However, with siblings like audio_transcriber_transcribe, audio_transcriber_record and audio_ingest_transcription, the description gives no hint why an agent would pick this tool over those, so the purpose is only minimally distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus the many transcribe/record siblings, no prerequisites, and no exclusions. The only implied usage is the mutually exclusive file-vs-microphone source, which is left for the agent to infer.

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

Deploy Server