Skip to main content
Glama
danielrosehill

Gemini Transcription MCP

by danielrosehill
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

transcribe_audio_format

Transcribe audio into a formatted document—email, meeting notes, report, or any custom type. Describe the desired format in plain words and receive a ready-to-use transcript.

Instructions

Transcribes an audio file and formats the output as a specific document type. Accepts any freeform format description. Use this when you want a quick ad-hoc format without browsing presets. For curated, high-quality formatting, use transcribe_with_preset instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vadNoEnable Voice Activity Detection preprocessing. Strips silence and non-speech audio before transcription using Silero VAD. Useful for recordings with long pauses or background noise.
modelNoModel 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.
formatYesThe desired output format. Examples: "email", "to-do list", "meeting notes", "technical document", "blog post", "executive summary", "letter", "report", "outline", "development specification". Any description is accepted.
file_urlNoHTTP(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_hostNoSSH host (and optional port, e.g. host:2222) to pull the audio file from. Provide with ssh_path.
ssh_pathNoRemote file path on the SSH host. Provide with ssh_host.
ssh_portNoOptional SSH port when pulling the file.
ssh_userNoOptional SSH username when pulling the file.
file_nameNoOptional name of the audio file, including the extension. Helpful when using URLs without a filename.
output_dirNoOptional 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_contentNoBase64-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.

  1. First observedv0.8.1

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations, the description carries the full disclosure burden, yet it only restates the core function and freeform nature. It does not explain return behavior, whether/when files are saved, validation of format strings, or any limitations of the ad-hoc path.

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?

Three short sentences, all informative: purpose, freeform capability, and usage routing. No fluff or redundancy; front-loaded effectively.

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

Completeness3/5

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

The description handles purpose and one sibling choice, and the rich schema documents all 11 parameters. However, with no output schema and no annotations, the missing return-value/side-effect information and lack of guidance for the other sibling tools leave notable 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 coverage is 100%, so the baseline is 3. The description's 'freeform format' note is already present in the format parameter's schema, so it adds no additional semantic value beyond what the input schema provides.

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?

The description clearly identifies the action (transcribe an audio file and format the output) and the resource (audio file), and explicitly contrasts with transcribe_with_preset. However, with several transcription siblings (transcribe_audio, transcribe_audio_raw, transcribe_audio_custom), it does not fully differentiate from all of them, leaving some ambiguity.

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?

It gives an explicit use case ('quick ad-hoc format without browsing presets') and directs agents to transcribe_with_preset for curated formatting. This is actionable, but it does not address when to use transcribe_audio, raw, or custom variants, so the routing guidance is incomplete.

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

Deploy Server

Other Tools