Skip to main content
Glama
danielrosehill

Gemini Transcription MCP

by danielrosehill
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

transcribe_with_preset

Transcribe spoken audio into text, then apply a user-selected preset to restyle it (e.g., formal, dejargonized) or restructure it into a document format (e.g., meeting minutes, blog outline).

Instructions

Transcribes audio and transforms the output using a curated preset. Presets are divided into two categories:

Styles (modify tone/voice): formal, informal, academic, business, journalistic, assertive, flamboyant, minimalist, dejargonizer, simplify, victorian, shakespearean, etc.

Formats (restructure into document type): blog_outline, business_email, meeting_minutes, note_to_self, to_do_list, tech_documentation, feature_request, bug_report, cover_letter, resume, newsletter, development_prompt, etc.

Use list_transcription_presets to browse all 200+ available presets with category filters.

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.
presetYesName of the preset to apply (e.g. "blog_outline", "business_email", "note_to_self", "formal_tone", "dejargonizer"). Use underscores or spaces.
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

B3.3/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 the full behavioral burden. It reveals the core transformation behavior and preset categories, but omits important operational details like return format, what happens when no output_dir is provided, failure modes, or any side effects.

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?

The description is well-structured and densely informative, with the core action front-loaded and preset categories clearly organized. The examples and pointer to list_transcription_presets all earn their place, though the example lists are slightly longer than strictly necessary.

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?

Given the tool's complexity (11 parameters, no annotations, no output schema), the description plus schema provide a mostly viable picture. The main gap is the absence of explicit output/return behavior and lack of guidance for choosing this over similar sibling tools, but the extensive schema descriptions compensate for much of the missing context.

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 input schema already provides 100% parameter coverage with detailed descriptions, giving a baseline of 3. The description adds extra meaning for the preset parameter by explaining the style/format taxonomy and providing concrete examples, which helps an agent select an appropriate preset.

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 states a specific action and resource: transcribes audio and applies a curated preset to transform the output. It adds a useful style/format taxonomy, but it does not explicitly distinguish itself from sibling tools like transcribe_audio_format or transcribe_audio_custom, so it falls just short of full differentiation.

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 this tool should be used when a preset-based transcription is desired, and it explicitly directs users to list_transcription_presets for preset discovery. However, it never states when not to use this tool or names alternatives such as transcribe_audio_raw or transcribe_audio_custom.

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