Skip to main content
Glama
pauliusdotpro

YouTube Audio & Transcript MCP Server

by pauliusdotpro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

YouTube transcript / captions

youtube_transcript
Read-onlyIdempotent

Extract existing captions from public YouTube videos or Shorts as text, JSON, Markdown, SRT, VTT, or LLM-ready chunks, with optional language and source selection.

Instructions

Get the transcript of a public YouTube video or Shorts from its existing captions (manual or auto-generated). Formats: 'text' (plain transcript, default), 'json' (metadata plus timestamped segments), 'llm' (ordered timestamped chunks for RAG/summaries), 'markdown' (readable with timestamps), 'srt' or 'vtt' (subtitle files). Optionally pick a language tag (e.g. en, es, pt-BR) and caption source. When language is omitted the API prefers manual English, then automatic English, then the first available track. Waits up to ~2 minutes; if still running, returns a jobId for get_job. Fails with TRANSCRIPT_NOT_AVAILABLE when the video has no matching captions (no speech-to-text fallback).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesYouTube video/Shorts URL or an 11-character video ID
formatNoOutput format. Default: text
sourceNoCaption source: preferred (default), manual (human captions only) or automatic (auto-generated only)
languageNoCaption language tag such as en, en-US, de, pt-BR. Omit for automatic selection.
maxCharsNoTruncate the returned transcript to this many characters. Default: 100000
chunkSizeNoTarget characters per chunk for the 'llm' format (500-12000, default 4000)
maxWaitSecondsNoHow long to wait for completion before returning a jobId. Default: 120

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial behavior beyond the safe-read annotations: the ~2 minute wait with jobId continuation, the TRANSCRIPT_NOT_AVAILABLE failure with no speech-to-text fallback, and the manual-English → auto-English → first-track selection order. These are exactly the operational traits an agent needs and are not in the structured fields.

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?

Front-loaded with purpose, then formats, language rules, timeout and error handling in a logical progression with no filler. Dense but every sentence carries information; slightly long without visual breaks keeps it from a 5.

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?

For a 7-parameter tool with no output schema, the description covers return shapes (formats and their contents), async completion via jobId, failure mode, and defaults. Combined with annotations that cover safety semantics, nothing material is missing.

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 the baseline is 3, but the description adds real meaning: it explains that 'llm' produces ordered timestamped chunks for RAG/summaries (the schema only names the enum), gives language tag examples, and clarifies chunkSize is only relevant to the 'llm' format.

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?

States a specific verb (get) plus resource (transcript), scoped to public YouTube videos/Shorts and existing captions (manual or auto-generated). Clearly distinct from youtube_to_audio (audio download) and tied to get_job via the async fallback, so an agent can route without opening schemas.

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?

Gives clear operating context: default language-preference order, format selection for different downstream uses, and explicit routing to get_job when a jobId is returned. It also implies a when-not ('no speech-to-text fallback'), but does not explicitly say which sibling to use when captions are unavailable.

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