Gemini Transcription MCP

transcribe_audio

Convert audio files (MP3, WAV, OGG, etc.) into edited transcripts with filler words removed, punctuation, and paragraph breaks. Handles large files via automatic compression.

Instructions

Transcribes an audio file using Gemini via OpenRouter. Returns a lightly edited transcript with filler words removed, verbal corrections applied, punctuation added, and paragraph breaks inserted. Large files are automatically compressed. Supports MP3, WAV, OGG, FLAC, AAC, AIFF, and many more formats (auto-converted). This is the recommended default tool.

Input Schema

TableJSON Schema

Name	Required	Description
`vad`	No	Enable Voice Activity Detection preprocessing. Strips silence and non-speech audio before transcription using Silero VAD. Useful for recordings with long pauses or background noise.
`model`	No	Model to use: "lite" for Gemini 3.1 Flash Lite (default, cost-efficient), "flash" for Gemini 3 Flash (more capable). Also accepts full OpenRouter model IDs.
`file_url`	No	HTTP(S) URL where the audio file can be fetched. PREFERRED transport for remote clients — use a presigned URL from `s3-stage <path>` on the workstation. Provide this OR file_content.
`ssh_host`	No	SSH host (and optional port, e.g. host:2222) to pull the audio file from. Provide with ssh_path.
`ssh_path`	No	Remote file path on the SSH host. Provide with ssh_host.
`ssh_port`	No	Optional SSH port when pulling the file.
`ssh_user`	No	Optional SSH username when pulling the file.
`file_name`	No	Optional name of the audio file, including the extension. Helpful when using URLs without a filename.
`output_dir`	No	Optional directory path where the transcript will be saved as a markdown file. If provided, saves the transcript with a descriptive filename derived from the title.
`file_content`	No	Base64-encoded audio content. AVOID for anything beyond a few seconds of audio — base64 inlining of audio is large and unreliable. Prefer file_url with `s3-stage` for local workstation files. Provide this OR file_url.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.1Aug 30, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context: large files are automatically compressed, formats are auto-converted, and the output is processed (filler removed, punctuation added). It also implies a network call via OpenRouter. This goes beyond the schema, though it omits details like cost or latency.

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?

The description is tightly written with no filler. The main purpose and output behavior are front-loaded, followed by format support and the default-tool recommendation. Every sentence contributes value.

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?

Despite having 10 parameters and no output schema, the description is reasonably complete when combined with the rich schema. It explains core behavior and the default status, while the schema documents each parameter, including transport preferences (file_url vs file_content) and output_dir behavior. Minor gaps like explicit mention of saving behavior could be added, but overall it is sufficient for a tool of this complexity.

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 the baseline is 3. Every parameter is well-documented in the schema itself, and the description adds little parameter-specific meaning beyond overall behavioral hints like 'large files are automatically compressed'.

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

Purpose5/5

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

The description clearly identifies the verb 'transcribes an audio file' and specifies the resource, along with the output transformation ('lightly edited transcript with filler words removed, verbal corrections applied, punctuation added, and paragraph breaks inserted'). It also positions itself as the 'recommended default tool', distinguishing it from siblings like transcribe_audio_raw or transcribe_with_preset.

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

Usage Guidelines4/5

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

Explicitly states it is the recommended default tool, giving clear context for when to choose it. However, it does not name specific alternatives or exclusions, so it stops short of full when/when-not guidance.

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

Deploy Server

transcribe_audio

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools