Skip to main content
Glama
danielrosehill

Open Router Audio Transcription MCP

by danielrosehill
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Open Router Audio Transcription MCP

An MCP server that transcribes audio files using OpenRouter's audio-capable language models.

Features

  • Verbatim transcription — exact word-for-word output including filler words, false starts, and repetitions

  • Cleaned transcription — lightly edited for readability: removes fillers, adds punctuation, sentence boundaries, and paragraph breaks; omits content not intended for transcription

  • Custom prompt transcription — direct the transcription with your own prompt for specialized use cases

Related MCP server: audio-transcription-mcp

Supported Models

Model

Provider

google/gemini-3-flash-preview (default standard)

Google

google/gemini-3.1-flash-lite-preview (default budget)

Google

xiaomi/mimo-v2-omni

Xiaomi

openai/gpt-audio

OpenAI

openai/gpt-audio-mini (budget)

OpenAI

mistralai/voxtral-small-24b-2507

Mistral

openai/gpt-4o-audio-preview

OpenAI

Supported Audio Formats

mp3, wav, ogg, flac, m4a, aac, webm, wma, opus

Setup

1. Get an OpenRouter API key

Sign up at openrouter.ai and create an API key at openrouter.ai/keys.

2. Add to Claude Code

Run the following command to add the MCP server to Claude Code:

claude mcp add audio-transcription -e OPENROUTER_API_KEY=your-api-key-here -- npx -y or-audio-transcription-mcp

Or add it manually to your Claude Code MCP settings (~/.claude/settings.json or project .mcp.json):

{
  "mcpServers": {
    "audio-transcription": {
      "command": "npx",
      "args": ["-y", "or-audio-transcription-mcp"],
      "env": {
        "OPENROUTER_API_KEY": "your-api-key-here"
      }
    }
  }
}

Alternative: Install from source

git clone https://github.com/danielrosehill/OR-Audio-Transcription-MCP.git
cd OR-Audio-Transcription-MCP
npm install
npm run build

Then configure with a direct path:

claude mcp add audio-transcription -e OPENROUTER_API_KEY=your-api-key-here -- node /path/to/OR-Audio-Transcription-MCP/dist/index.js

Tools

transcribe_audio

Transcribe an audio file.

Parameter

Type

Required

Description

file_path

string

Yes

Absolute path to the audio file

mode

"verbatim" | "cleaned" | "custom"

Yes

Transcription mode

custom_prompt

string

When mode=custom

Custom prompt to direct the transcription

model

string

No

OpenRouter model ID (defaults to google/gemini-3-flash-preview)

budget

boolean

No

Use budget model (google/gemini-3.1-flash-lite-preview). Ignored if model is set

list_transcription_models

Lists all available audio transcription models.

License

MIT

Available Tools

2 tools
list_transcription_modelsA

List available OpenRouter models that support audio transcription.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral load, and 'List' implies a read-only, non-destructive operation, which is reasonable. However, it says nothing about authentication requirements, whether a live API key is needed, pagination, or result ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. The scope qualifier ('that support audio transcription') is the one piece of information that distinguishes this list from a generic model listing, and it is stated directly.

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

Completeness4/5

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

For a parameterless read-only listing tool with no output schema, the description is close to sufficient. The only real gap is that it doesn't hint at what the returned entries contain (e.g., model identifiers usable in transcribe_audio), which an agent would need to chain the two calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is empty, so there are no parameter semantics to document. The baseline for a zero-parameter tool is a 4; the description adds nothing here because nothing is required.

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

Purpose4/5

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

States a specific verb (List) and resource (OpenRouter models) with a scope qualifier (support audio transcription). An agent can tell it apart from the sibling transcribe_audio, which performs transcription rather than discovery, though the description never names that sibling explicitly.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of the transcribe_audio sibling as an alternative. Usage is only weakly implied by the fact that a preceding model-discovery step would logically precede a call to transcribe_audio.

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

transcribe_audioB

Transcribe an audio file using OpenRouter. Supports verbatim, cleaned, or custom prompt modes.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYesTranscription mode. 'verbatim': exact word-for-word transcription including filler words. 'cleaned': lightly edited for readability (removes fillers, adds punctuation, paragraph breaks). 'custom': use a custom prompt to direct the transcription.
modelNoOpenRouter model to use for transcription. Defaults to 'google/gemini-3-flash-preview'. Available models: xiaomi/mimo-v2-omni, google/gemini-3.1-flash-lite-preview, google/gemini-3-flash-preview, openai/gpt-audio, openai/gpt-audio-mini, mistralai/voxtral-small-24b-2507, openai/gpt-4o-audio-preview
budgetNoUse the default budget model instead of the standard model. Budget model: 'google/gemini-3.1-flash-lite-preview'. Ignored if 'model' is explicitly set.
file_pathYesAbsolute path to the audio file to transcribe. Supported formats: mp3, wav, ogg, flac, m4a, aac, webm, wma, opus
custom_promptNoCustom prompt to direct the transcription (required when mode is 'custom'). This replaces the default system prompt entirely.

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries full behavioral burden. It states the operation is a transcription and mentions modes but does not disclose whether it's synchronous (likely, given no job id), what format the output takes, whether it consumes tokens/budget, or error conditions (unsupported format, missing file). For a call to an external paid AI service, this is a significant transparency gap.

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?

Two short sentences, front-loaded with the verb+resource. It's efficiently sized and wastes no words, though the second sentence only echoes enum values already in the schema.

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?

A tool that hits an external AI service with a freeform custom_prompt path, budget/model selection, and no output schema deserves more: expected return shape (raw transcript? JSON?), sync vs async, cost behavior. The description covers neither return values nor operational behavior, leaving material gaps.

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% with rich enum descriptions for 'mode' and model lists for 'model', so the schema does the heavy lifting. The description's 'verbatim, cleaned, or custom prompt modes' repeats the enum values without adding semantics. Baseline 3 applies.

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

Purpose4/5

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

States a specific verb+resource: 'Transcribe an audio file'. The OpenRouter mention situates it as an external-service call, and the mode enumeration hints at behavior. It doesn't differentiate from the sibling list_transcription_models, but the sibling's name makes the boundary obvious.

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

Usage Guidelines3/5

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

The description implies usage via 'mode' options but never says when to choose this tool over alternatives, nor what prerequisites (audio access, file existence) exist. The sibling handles model listing, so the reader can infer a rough workflow but nothing is stated explicitly.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedlist_transcription_models
    • First observedtranscribe_audio
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one discovers available transcription models, the other performs the transcription. There is no plausible way to confuse them.

Naming Consistency5/5

Both names follow a consistent snake_case verb_noun pattern (list_transcription_models, transcribe_audio) and are predictable for the domain.

Tool Count3/5

Two tools is on the thin side for a server, even a focused one; a discovery tool plus a single action tool leaves little room for variation. It is workable but borderline minimal.

Completeness4/5

The core workflow (find a model, then transcribe) is covered end to end. Some useful operations like batch transcription or job status are absent, but they are minor gaps an agent can work around.

Resources

Related MCP Connectors

Related MCP Servers