Skip to main content
Glama
jindratilk

YouTube Research MCP

by jindratilk

Read YouTube videos

youtube_fetch
Read-onlyIdempotent

Read YouTube videos to get transcripts, time-ranged passages, chapters, comments, thumbnails, and real frames, or batch many videos in one call for research.

Instructions

Read YouTube videos: transcript (whole, a time range, a chapter, or only passages matching a query), real video frames, details, chapters, comments and thumbnail. Batch many videos in one call.

Best for: reading what was said after youtube_search, pulling the same slice from many videos (e.g. the first 30 s of each video to study hooks), quoting with exact timestamps. Returns: per video a header (title, channel, exact publish date, views, likes, duration) and the requested parts. Transcript lines carry [m:ss] stamps; links with ?t= jump to the moment. Per-video failures are reported inline, never dropped.

Tips:

  • Hooks / intros: start=0, end=30 (plus parts ["details","transcript","thumbnail","frames"] if the visual hook matters).

  • Frames are real decoded video frames (up to 1280 px): evenly spaced over start–end / the chapter / the whole video (frames=N), or at exact moments (frameAt). The first frames of a video take ~10–20 s (stream lookup); keep frame-heavy calls to a few videos.

  • Finding a topic inside long videos: pass query instead of reading whole transcripts.

  • Long transcript cut off? Call again with start = the second where it stopped.

Input Schema

NameRequiredDescriptionDefault
endNoRange end for transcript and frames: seconds or 'm:ss'.
partsNoAny of details, transcript, chapters, comments, thumbnail, frames. Default ["details","transcript"].
queryNoReturn only transcript passages matching these phrases (any language/synonyms), not the full text.
startNoRange start for transcript and frames: seconds or 'm:ss'.
framesNoWith part frames: how many frames, evenly spaced over the range (default 6, max 20 per video, 40 per call).
videosYes1–25 video URLs or IDs. A ?t= in a URL is used as start when start is not given.
chapterNoLimit transcript and frames to the chapter whose title contains this text.
frameAtNoWith part frames: exact moments instead of even spacing, e.g. [0, 3, '0:12'].
matchesNoMax passages per video in query mode (default 6, max 20).
frameWidthNoFrame width in px (default 640, max 1280). Wider = readable small text, more tokens.
timestampsNoparagraph (default): ~30 s blocks with [m:ss]; segment: every caption line; none: plain text.
commentsLimitNoTop comments per video (default 20, max 200).
maxCharactersNoTranscript characters per video (default 12000, max 60000).
transcriptLangsNoPreferred transcript languages in order, e.g. ['es','en']. Default: the video's original language.
descriptionCharsNoDescription characters in details (default 1500).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description goes further with latency (~10–20 s for the first frames, stream lookup) and partial-failure semantics ('per-video failures are reported inline, never dropped'). It also flags cost tradeoffs (frame width = more tokens, frame-heavy calls across a few videos) and truncation behavior, which the agent cannot infer from annotations.

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 and organized under Best for / Returns / Tips, with each tip carrying actionable content. Slightly verbose for the payoff, with a little redundancy (batching stated in the opening line and again in the multi-video tip), which keeps it short of 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 15-parameter tool with no output schema, the description supplies the return shape (per-video header with title, channel, publish date, views, likes, duration, plus [m:ss]-stamped transcript lines) and the failure/truncation model. An agent has everything needed to compose a correct call and interpret the result.

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 description coverage is 100%, so the baseline is 3; the description still adds interpretive value by explaining how start/end apply to both transcript and frames, the frames-vs-frameAt distinction, and the ?t= start fallback. It does not add meaning for the more peripheral knobs (commentsLimit, transcriptLangs, descriptionChars, matches) beyond what the schema already says.

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?

Specific verb+resource (read YouTube videos) with the full list of retrievable parts (transcript, frames, details, chapters, comments, thumbnail) and batching scope. The phrase 'after youtube_search' explicitly distinguishes it from the search sibling, so the 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 Guidelines5/5

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

Gives concrete when-to-use scenarios (post-search reading, same slice across many videos, quoting with timestamps) and decision rules for alternatives: use query instead of full transcripts for topic finding, and re-call with start=<stop second> when a transcript is cut off. This is close to a decision tree, not just a context hint.

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