Skip to main content
Glama

Get Channel Transcripts

get_channel_transcripts
Read-only

Get transcripts for a YouTube channel's most recent videos (newest first) as timestamped markdown, one section per video. Use for research across a creator's recent output; for one known video use get_transcript. Read-only; requires an API key. Charges 1 credit per video that returns a transcript, including repeat calls; videos without captions are skipped free. A 10-video call typically costs up to 10 credits, so start with a small limit. Rate limit: 5 requests per 10 seconds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesYouTube channel URL or handle (e.g. https://www.youtube.com/@lexfridman or @lexfridman)
limitNoNumber of most-recent videos to fetch, 1-50 (default 10). Upper bound on the credit charge for this call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
failedYesVideos skipped without charge (no captions)
channelYesChannel name
succeededYesVideos that returned a transcript (each charged 1 credit)
creditsUsedYesCredits charged for this call
totalVideosYesVideos attempted in this call
transcriptsYesAll transcripts as timestamped markdown, one section per video, divider-separated
creditsRemainingYesAccount balance after this call

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds substantial non-obvious behaviors: per-video credit charges, repeat calls charged, videos without captions skipped free, API key requirement, and a rate limit of 5 requests per 10 seconds. This goes well beyond the annotation's minimal safety info.

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 front-loaded with the core purpose, then usage, then cost and rate-limit details. Each of the three sentences carries distinct, necessary information without redundancy or fluff.

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?

The description covers the purpose, output format, usage context, cost model, API key requirement, rate limit, and free skips. With an output schema present, return values are handled structurally, so this leaves no major gaps for an agent to misuse the tool.

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% for both parameters (url and limit), so the schema already documents their basic meaning. The description adds extra semantics for limit: it acts as an upper bound on credit charge and gives typical cost examples ('A 10-video call typically costs up to 10 credits'), which helps agents select an appropriate value.

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?

Description states a specific verb and resource: 'Get transcripts for a YouTube channel's most recent videos (newest first) as timestamped markdown, one section per video.' It also distinguishes from sibling tools by noting that for a single known video, get_transcript should be used.

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?

Explicitly provides when to use: 'Use for research across a creator's recent output; for one known video use get_transcript.' This names an alternative and gives clear context, fulfilling the guidelines requirement.

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.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool targets a distinct resource/action: a single video, a channel's recent videos, a playlist's videos, and cleaning a transcript. The descriptions explicitly cross-reference when to use which, eliminating ambiguity.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern: get_transcript, get_channel_transcripts, get_playlist_transcripts, polish_transcript. Singular/plural use logically matches the number of videos handled.

Tool Count5/5

Four tools is an appropriate, focused size for a transcript downloader. Each tool serves a clear purpose without redundancy or bloat.

Completeness5/5

The tool set covers the primary workflows: fetching a single transcript, fetching multiple transcripts from a channel or playlist, and polishing auto-generated captions. The read-only nature makes this surface complete for its stated domain.

Resources