Gemini Transcription MCP

transcribe_audio_custom

Transcribe audio with a user-defined prompt to control output format and processing. For custom transcription instructions beyond standard tools.

Instructions

Transcribes an audio file using Gemini via OpenRouter with a user-defined custom prompt. Provides full control over how the model processes and formats the transcription. Use this when you need specific transcription instructions not covered by other tools.

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.
`custom_prompt`	Yes	The custom prompt/instructions to send along with the audio. Should describe how to transcribe and format the content. The prompt should instruct the model to return JSON with at minimum a "transcript" field.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.1Aug 30, 2026

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that transcription runs through Gemini via OpenRouter and uses a custom prompt, but it does not disclose side effects like saving to output_dir, how audio is supplied, return behavior, or any limitations. This is a significant gap for an 11-parameter tool.

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 two sentences with no filler. The primary purpose is front-loaded first, and the usage guidance follows immediately. Every sentence earns its place.

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?

Given 11 parameters, no annotations, and no output schema, the description is too thin to be contextually complete. It does not explain what a successful call returns, whether a transcript file is saved, or how the audio transport options relate. The rich schema helps, but the description still leaves important operational context unstated.

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?

The input schema has 100% parameter coverage with detailed descriptions, so the description does not need to restate parameter meanings. It adds the general concept of a custom prompt, but this is already captured by the custom_prompt parameter schema. Baseline 3 is appropriate.

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 states a specific action — transcribing an audio file — and the differentiator: a user-defined custom prompt. It distinguishes this tool from siblings by emphasizing full control over processing/formatting and positioning it as the option for instructions not covered by other tools.

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?

The description explicitly says to use this tool when specific transcription instructions are needed and not covered by other tools. It provides clear context but does not name sibling alternatives or state when not to use it, so it falls just short of full exclusion 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_custom

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools