Provides audio and video transcription through OpenAI's API, allowing local files to be transcribed with configurable model, language, task, prompt, and API key.
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., "@audiototext-mcp transcribe /home/user/recordings/meeting.mp3 and summarize it"
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.
An MCP server that exposes local audio and video transcription through the audiototext engine.
Python 3.11+
ffmpeg available on PATH
For local transcription: install the local extra of cykk-audio-transcriber
For OpenAI transcription: install the api extra and set OPENAI_API_KEY
Related MCP server: jackai-stt-mcp
pip install "audiototext-mcp[local]"The package can also use the OpenAI backend:
pip install "audiototext-mcp[api]"audiototext-mcpThe server uses MCP stdio transport. Configure the command in an MCP client such as Claude Desktop, Cursor, or another compatible host:
{
"mcpServers": {
"audiototext": {
"command": "audiototext-mcp"
}
}
}transcribe_file accepts a local file_path and optional model, language, task, prompt, and api_key arguments. It returns JSON containing the detected language, full text, and timestamped segments.
The server reads local files, so only configure it in clients you trust. API keys should preferably be supplied through OPENAI_API_KEY rather than tool arguments.
For browser-based transcription workflows, MP3 to Text is suitable for MP3 files, while MP4 to Text is designed for MP4 video transcription.
MIT
Transcribe a local audio or video file and return JSON with text and timestamps.
Uses local Whisper by default. Set api_key (or OPENAI_API_KEY) to use the OpenAI speech API instead. The file must be readable by the MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | transcribe | |
| model | No | small | |
| prompt | No | ||
| api_key | No | ||
| language | No | Auto-Detect | |
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose engine selection, API-key switching, and the file-readable requirement. However, it omits meaningful behavioral traits such as potential third-party data transmission when using the OpenAI API, model download behavior, or format/duration limits.
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?
Three sentences, front-loaded with the main purpose, followed by engine-selection notes and a constraint. There is no filler; every sentence contributes 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 6-parameter tool with no annotations, the description covers the core call path and output shape, and the output schema covers return values. But optional parameter semantics and behavioral caveats are missing, so an agent cannot fully reason about non-default invocations.
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 0%, so the description must compensate. It adds semantics only for file_path (must be readable) and api_key (selects OpenAI API), while task, model, prompt, and language remain unexplained in both schema and description.
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?
Description specifies verb 'Transcribe', resource 'local audio or video file', and expected return 'JSON with text and timestamps', so the tool's function is unambiguous. There are no siblings to differentiate from, and the name is reinforced without being a mere tautology.
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?
It gives concrete context: the default local Whisper path, when to switch to OpenAI speech API via api_key (or OPENAI_API_KEY), and a prerequisite that the MCP server must be able to read the file. It doesn't name alternative tools, but no siblings exist and the backend-selection guidance is enough for an agent to proceed correctly.
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.0transcribe_fileScored across 1 tool
With only one tool, there is no possibility of confusion. The tool's purpose is clear and distinct by default.
The single tool name 'transcribe_file' follows a clear verb_noun convention. With only one tool, there is no naming inconsistency to evaluate.
A single tool is slightly below the typical 3-15 range, but it is well-scoped for a dedicated audio-to-text server. The tool fully addresses the server's narrow purpose without unnecessary additions.
The tool covers the complete transcription workflow: accepts local audio or video files, returns transcript with timestamps, and supports both local Whisper and OpenAI API backends. There are no obvious missing operations for this domain.
Transcribe audio and video into speaker-labelled transcripts, subtitles, clips, and cited Q&A.
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 recordings into a speaker-labelled transcript with timestamps and a summary.
