webdata-tools-mcp

Get YouTube video transcripts

get_youtube_transcripts

Read-onlyIdempotent

Extract clean, timed YouTube transcripts plus metadata from videos, playlists, channels, or searches for summaries, RAG, research, and content repurposing.

Instructions

Full transcripts of YouTube videos, and of every video in a playlist, a channel (newest first) or a YouTube search, as clean text plus timed caption lines, with title, channel, publish date, length, views, description and keywords. Picks the caption language you prefer (a written transcript over an auto-generated one) and can translate (best effort). Use for summaries, RAG, research and content repurposing. Runs the Apify Actor tacps126/youtube-transcripts on your Apify account (about $0.0025 per transcript (videos without captions are free); spend per call is capped at $0.5).

Input Schema

Name	Required	Description
`videos`	No	Video links or ids, playlist links, channel @handles or channel links.
`searches`	No	YouTube searches whose top videos to read, e.g. ["rust async tutorial"].
`languages`	No	Caption languages in order of preference, e.g. ["en", "de"] (default en).
`max_items`	No	Maximum results to return (default 20, max 500). Cost scales with this.
`extra_input`	No	Advanced: extra Actor input fields, merged over the defaults.
`translate_to`	No	Language code to translate the captions into (best effort).
`include_segments`	No	Add every caption line with its start time. Off = plain text only.
`max_videos_per_source`	No	Videos taken from each playlist, channel or search.

Output Schema

Name	Required	Description
`tool`	Yes	Name of the tool that produced the result.
`count`	Yes	Number of records the Actor returned.
`items`	Yes	The records. Long text fields are shortened to 600 characters.
`shown`	Yes	Number of records included in `items` (can be lower than count when the result is long).
`truncated`	Yes	True when records were left out to keep the result short; ask for fewer items.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.14.0Nov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, open-world), and the description adds genuinely new behavior: the upstream Apify Actor, per-transcript pricing (~$0.0025), free videos without captions, and a $0.5 per-call spend cap. It also discloses caption-selection preference (written over auto-generated), best-effort translation, and newest-first channel ordering.

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?

Zero filler — every clause carries payload (sources, output shape, metadata, cost). The opening sentence is a dense multi-clause list that front-loads scope well but is long enough to be parsed in several passes.

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, so return values need no explanation. For an 8-parameter, nested, open-world scraping tool, the description supplies the cost model, source coverage, and language behavior an agent needs to call it safely and correctly.

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; the description earns more by explaining caption-selection logic that the schema only gestures at with "in order of preference" and by flagging that max_items drives cost. It does not clarify extra_input merging or translate_to semantics beyond what the schema 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?

States a specific verb+resource (fetch full transcripts of YouTube videos) and enumerates supported source types: single videos, playlists, channels (newest first), and searches. No sibling tool covers this domain, and the description makes the resource boundary unmistakable.

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?

"Use for summaries, RAG, research and content repurposing" gives clear situational context, and the cost note implicitly steers toward bounded use. It never states when NOT to use it or names an alternative, but the sibling set contains no overlapping transcript tool to route against.

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