Skip to main content
Glama

Transcribe audio or video

transcribe_media
Idempotent

Get the spoken words out of any audio or video in the user's account, timed and attributed to speakers.

WHAT IT TAKES. One media reference — an upload or a generation, in the exact shape list_media returns. Anything with a sound track qualifies: an uploaded video or podcast, a voice-over or music track generated here, a clip this studio rendered. Images are refused. Up to 60 minutes of media per file. Costs no credits.

HOW IT RUNS. The first call queues the transcription and returns ready:false — call get_transcription with the same media to poll, usually a few seconds for a short clip and longer for a long one. The result is stored against the file, so once it is ready every later call returns it instantly and for free.

WHAT COMES BACK. segments are timed lines in order, each with start_seconds, end_seconds, a diarization speaker label and its text; speakers lists the distinct labels; language is what the speech model detected; text is the whole thing as prose for reading.

USING IT TO ANALYSE A VIDEO. This is the words half. measure_video is the pictures half — measured shot boundaries and keyframe images for a video upload — and the two are meant to be read together: the bundle tells you when the cuts are and what is on screen, this tells you what is being said over them and by whom. Reach for this one alone whenever the file is audio, is a generation rather than an upload, is longer than the bundle accepts, or when you need to know who spoke.

The timings and speaker labels are measured, not guessed. Quote them; never round, shift or invent one. An empty transcript is a real answer — silent footage, an instrumental track — and not a reason to retry.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "media": "<media>"
    },
    "name": "transcribe_media"
  }
}

Input Schema

NameRequiredDescriptionDefault
mediaYesThe audio or video to transcribe — an upload or a generation, in the shape list_media returns.
retryNoRun a failed transcription again. A ready transcript is never replaced; a plain call polls.
chunk_max_secondsNoAlso cut the recording at its pauses into lines of at most this many seconds (15 for an avatar clip): `chunks` gives each line's start_seconds and duration_seconds for trim_audio.

Output Schema

NameRequiredDescriptionDefault
textYes
errorYes
readyYes
chunksYes
statusYes
messageYes
languageYes
media_idYes
segmentsYes
speakersYes
media_kindYes
media_typeYes
chunk_errorYes
instructionsYes
segment_countYes
duration_secondsYes
transcription_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / retry / description
      Previous value: -"Transcribe again, discarding what is stored. Only needed after a failed status; a plain call polls and never re-runs a settled transcript."New value: +"Run a failed transcription again. A ready transcript is never replaced; a plain call polls."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Discloses behavior the annotations cannot: the first call queues work and returns ready:false, polling goes through get_transcription, results are cached so later calls are instant and free, cost is zero credits, and there is a 60-minute per-file ceiling. It also warns that an empty transcript is a valid result and not a retry case. All of this is consistent with idempotentHint=true and destructiveHint=false.

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?

Well front-loaded with ALL-CAPS section headers that let an agent jump to cost, lifecycle, or return shape. Some sentences are expansive ('Anything with a sound track qualifies' with a three-item list), but nothing is redundant and the closing integrity warning about not rounding timings earns its place.

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

Completeness5/5

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

An output schema exists, yet the description still summarizes segments/speakers/language/text at a level that helps an agent plan. With the async lifecycle, cost, limits, and analysis pairing all covered, an agent has everything needed to call this correctly on the first attempt.

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?

Schema coverage is 100%, so retry and chunk_max_seconds are already documented and the baseline would be 3. The description adds meaning beyond the schema for the main parameter by stating the acceptance boundary — anything with a sound track, images refused, 60 minutes max, reference shaped exactly as list_media returns it — which the schema's anyOf cannot express.

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?

Opens with a specific verb+resource ('Get the spoken words out of any audio or video') and immediately scopes the input to the user's account. It explicitly distinguishes itself from the sibling that handles the same files (measure_video) and from the polling sibling get_transcription, so an agent can select it without reading either schema.

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

Usage Guidelines5/5

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

Gives explicit when-when-not guidance: pair with measure_video for video analysis, but 'reach for this one alone whenever the file is audio, is a generation rather than an upload, is longer than the bundle accepts, or when you need to know who spoke.' It also names get_transcription as the polling path and states images are refused.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources