SubDownload is an MCP server that exposes YouTube as a data source, enabling AI agents to search, retrieve, transcribe, and manage YouTube content with a personal knowledge base.
Search YouTube: Perform keyword searches across all of YouTube
Fetch Video Metadata: Retrieve video details including title, channel, duration, view count, and publish date
Fetch Transcripts: Get full transcripts with timestamps for YouTube videos, supporting multiple languages
AI Transcription: Generate transcripts for videos lacking captions using AI-powered ASR, with a polling mechanism to check job status
Channel Management: Resolve channels by handle/URL/ID, list all channel videos (with pagination), get latest videos, and search within a specific channel
Playlist Management: List all videos contained within a YouTube playlist
Personal Knowledge Base: Save video summaries or transcripts with optional tags, browse saved items by search query or tags, and retrieve specific items by ID
Provides tools for searching YouTube, fetching video metadata and transcripts (including AI ASR for videos without captions), managing channels and playlists, and saving content to a personal knowledge base.
SubDownload exposes YouTube as an MCP-native data source. Connect once via OAuth and your AI agent gets tools to summarize videos, fetch full transcripts (including videos without captions, via AI ASR), search channels and playlists, and save everything into a per-user knowledge base for cross-session recall.
Hosted endpoint: https://api.subdownload.com/mcp
Homepage: https://subdownload.com?utm_source=gthb_awesome_9jqqed&utm_medium=code&utm_campaign=Awesome
Glama (connector): https://glama.ai/mcp/connectors/com.subdownload.api/sub-download
Glama (server): https://glama.ai/mcp/servers/SubDownload/subdownload-mcp
The recommended setup is to point your MCP client directly at the hosted endpoint above and authenticate via OAuth — see "Quick connect" below. This repo also ships a thin stdio proxy (Node + Docker) for environments that prefer a local subprocess.
OAuth 2.1 with Dynamic Client Registration (RFC 7591). No pre-shared client_id or client_secret — your MCP client registers itself on first connect.
Discovery (RFC 9728):
POST to /mcp without a token returns 401 plus a WWW-Authenticate header pointing to /.well-known/oauth-protected-resource
That document points to the authorization server (https://api.subdownload.com)
The MCP client follows the standard authorize → callback → token flow with PKCE
API-key alternative: every account at https://subdownload.com/account exposes a Bearer token for clients that don't support OAuth.
Related MCP server: YouTube Transcript MCP Server
Tool | What it does |
| Keyword search across YouTube |
| Video metadata (title, channel, duration, view count) |
| Full transcript with timestamps |
| Generate a transcript with AI ASR for videos that have no captions |
| Poll an in-progress AI transcription job |
| Look up a channel by handle, URL, or ID |
| List videos on a channel |
| Latest videos for a channel |
| Search within a single channel |
| List the contents of a playlist |
| Save a video summary or transcript to your personal knowledge base |
| Browse your saved knowledge base |
| Fetch a single saved item |
{
"mcpServers": {
"subdownload": {
"url": "https://api.subdownload.com/mcp"
}
}
}The first time you use it, the client triggers OAuth and you sign in with Google or LINUX DO. Free credits on signup — no card required.
{
"mcpServers": {
"subdownload": {
"url": "https://api.subdownload.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}Grab your API key from your account page.
For clients that prefer a subprocess transport, this repo ships a thin Node proxy that forwards tools/call to the hosted endpoint with your API key.
# Docker
docker build -t subdownload-mcp .
docker run --rm -i -e SUBDOWNLOAD_API_KEY=YOUR_API_KEY subdownload-mcp
# Or via Node directly
npm install
SUBDOWNLOAD_API_KEY=YOUR_API_KEY npm startClient config example:
{
"mcpServers": {
"subdownload": {
"command": "docker",
"args": ["run", "--rm", "-i", "-e", "SUBDOWNLOAD_API_KEY", "subdownload-mcp"],
"env": { "SUBDOWNLOAD_API_KEY": "YOUR_API_KEY" }
}
}
}Tool schemas are declared inline so introspection (initialize, tools/list) works without credentials; tools/call requires SUBDOWNLOAD_API_KEY.
Free credits on signup. Pro: 5,000 credits per month. See https://subdownload.com/pricing.
Email: contact@subdownload.com
Status: https://subdownload.com/status
MIT (applies to this documentation repository; the SubDownload service itself is hosted SaaS — see https://subdownload.com/terms).
Fetch the existing official transcript (subtitles/captions) of a YouTube video, with per-segment timestamps and language detected. Errors with NO_CAPTIONS if the video has no captions — fall back to transcribe_video in that case to generate one with AI ASR. This call is free.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | YouTube video ID (e.g. 'dQw4w9WgXcQ') or full YouTube URL. | |
| lang | No | ISO 639-1 language code to select among multilingual captions (e.g. 'en', 'zh', 'ja'). Omit for the video's default language. | |
| save | No | When true, also save the video to the user's Library in the same call. Bookmarks the meta row and flips has_asr when the transcript was produced by our ASR. Does NOT upload a summary — use save_to_library with kind='summary' or kind='both' for that. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds context about the error case (NO_CAPTIONS), return data (segments, timestamps, language), and that it's free, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with only 2-3 sentences, no redundancies, and front-loads the core purpose and fallback. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description outlines the expected return (segments, timestamps, language) and error behavior. It could be more detailed about the output structure, but is sufficient for a fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for video_id, lang, and save. The description does not add new meaning to parameters beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches existing official transcript with timestamps and language detection. It distinguishes from sibling transcribe_video by explicitly identifying it as a fallback when no captions exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit guidance: use this tool for existing captions, and fall back to transcribe_video if a NO_CAPTIONS error occurs. Also mentions the call is free, aiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch consolidated YouTube video metadata with numeric types — title, channel, duration, view count, publish date, thumbnail, description, captions availability. Does NOT include the transcript itself; call fetch_transcript or transcribe_video for that. Cheap, fast, free.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | 11-char YouTube video ID (e.g. 'dQw4w9WgXcQ') or full URL (watch, youtu.be, shorts, embed, live). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so agent knows it's a read-only operation. Description adds behavioral context: does NOT include transcript (preventing false expectations), and labels it 'cheap, fast, free' for cost/speed. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with the tool's main purpose and key return fields, then provides exclusion and efficiency notes. Perfectly sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter and no output schema, description fully covers what the tool returns, what it excludes, and its cost profile (cheap, fast, free). No gaps for an agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a clear description of the video_id parameter (accepts 11-char ID or full URL). Description does not add additional parameter meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches consolidated YouTube video metadata with specific fields listed (title, channel, duration, etc.). Distinguishes from sibling tools by explicitly stating it does not include transcript and redirects to fetch_transcript or transcribe_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (for metadata) and when not to (for transcript). Names alternative siblings fetch_transcript and transcribe_video. Also notes it's cheap, fast, and free, guiding usage expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll the status of an ASR task created by transcribe_video. Returns one of queued, downloading, transcribing, finalizing, done, or failed. When status is done, includes the full transcript with timestamps. Recommended polling interval: 3-5 seconds. Free — does not consume credits.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID returned by transcribe_video. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by listing all possible status values ('queued', 'downloading', 'transcribing', 'finalizing', 'done', 'failed'), explaining that a full transcript with timestamps is included when status is 'done', and recommending a polling interval. It does not mention rate limits or idempotency, but overall it provides good behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first states purpose, second lists statuses, third gives polling interval and cost. No fluff, front-loaded with the key action. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with one parameter and no output schema, the description covers status outcomes, behavior when done, and polling interval. It lacks error handling details (e.g., what happens with invalid task_id), but overall it is sufficiently complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter 'task_id' described as 'Task ID returned by transcribe_video.' The description does not add additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Poll the status of an ASR task created by transcribe_video.' It specifies the verb (poll), resource (ASR task), and links to the creating tool. This differentiates it from siblings like fetch_transcript (which retrieves final transcripts) and transcribe_video (which creates tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it is for polling status, recommends a polling interval of 3-5 seconds, and notes it is free (no credit consumption). It implicitly indicates when to use (after transcribe_video) but does not explicitly state when not to use or cite alternatives. The cost disclosure is an added benefit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recent videos from a YouTube channel — convenience wrapper over list_channel_videos with no pagination. Best for 'what did this creator publish recently?' style queries.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | @handle (e.g. '@mkbhd'), channel URL, or UC... channel ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; description adds no pagination and wrapper behavior but does not detail return limits or ordering. Adequate given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read-only tool with no output schema, the description covers purpose, usage, and behavioral context sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for the single parameter; description adds no additional meaning beyond schema. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb ('Get') and resource ('most recent videos from a YouTube channel'), clearly distinguishing it from sibling `list_channel_videos` by stating it's a convenience wrapper without pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'convenience wrapper over list_channel_videos with no pagination' and suggests a typical query style, implying when to use. Does not explicitly state when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a saved Library item with its transcript and AI summary inline (when available). Use after list_library to fetch the full content the user saved. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Library item id (returned by list_library or save_to_library). | |
| locale | No | Summary locale to fetch (e.g. 'en', 'zh'). Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description adds value by mentioning the inline transcript and AI summary. This goes beyond the annotation to specify what the read operation yields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and immediately followed by usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description explains the return content (transcript and summary) and usage context. It lacks error or permission details but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides 100% coverage with descriptions for both parameters (id, locale). The description adds no extra parameter info beyond the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a saved Library item, including its transcript and AI summary. It distinguishes from list_library by specifying it fetches full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after list_library to fetch the full content,' providing clear usage context. It does not list exclusions or alternatives, but the guidance is direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all videos from a YouTube channel ordered by publish date (newest first), with pagination. Returns up to 30 per page plus a continuation token if more results exist. For just the most recent handful, prefer get_channel_latest_videos for simplicity.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | @handle, channel URL, or UC... channel ID. Required for the first page; omit on subsequent pages and pass `continuation` instead. | |
| continuation | No | Pagination token from a previous response's `continuation` field. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: returns up to 30 per page, uses a continuation token for pagination, and orders by publish date newest first. This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the core action and key details (ordering, pagination, page size, alternative). Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions the response includes up to 30 items and a continuation token. It covers purpose, usage, pagination, and alternatives. Lacks explicit mention of returned fields (e.g., video IDs, titles), but for a simple list tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds usage guidance: when to omit 'channel' (on subsequent pages using continuation). This provides extra context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('all videos from a YouTube channel'), the ordering ('newest first'), and pagination. It explicitly differentiates from the sibling tool 'get_channel_latest_videos' by noting that tool is simpler for a few recent videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when not to use this tool ('for just the most recent handful, prefer get_channel_latest_videos') and implies when to use it (when you need all videos or pagination). This provides clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List videos the user has saved to their Library (transcripts + summaries). Supports substring search on title/author, favorites filter, and pagination. Returns recently saved items first. Scoped to the calling user's data only.
| Name | Required | Description | Default |
|---|---|---|---|
| favorite | No | When true, return only items the user has favorited. | |
| q | No | Substring match on title and author. | |
| limit | No | Max items per page (1-100, default 20). | |
| offset | No | Pagination offset (number of items to skip). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, indicating safe reading. The description adds behavioral details: returns recently saved items first, supports substring search and favorites filter. This complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states purpose and content type, second lists key features. It is front-loaded with the core action and avoids superfluous details, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains ordering (recently saved first) and scope, but does not detail the structure of returned items beyond mentioning transcripts and summaries. It is reasonably complete for a list tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description summarizes parameter behavior (substring search, favorites filter, pagination) but does not add significant new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states "List videos the user has saved to their Library" with specific verb (list) and resource (Library videos). It adds details like transcripts, summaries, and scoping, making it distinct from sibling tools such as list_channel_videos or search_youtube.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the scope ("Scoped to the calling user's data only") and lists supported features (substring search, favorites filter, pagination). It implicitly tells when to use this tool (for user's own library) but does not explicitly contrast with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List videos in a YouTube playlist in order, with pagination. Returns video metadata and position within the playlist. Works for any public or unlisted playlist exposed by its URL/ID.
| Name | Required | Description | Default |
|---|---|---|---|
| playlist | No | Playlist URL or ID (typically starts with 'PL', 'UU', 'LL', or 'FL'). Required for the first page. | |
| continuation | No | Pagination token from a previous response's `continuation` field. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description supplements annotations by disclosing pagination behavior, the order of returned videos, and that it works for public/unlisted playlists. This goes beyond the readOnlyHint and destructiveHint annotations, providing useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences each add unique value: listing operation, pagination, return info, and scope. No extraneous content. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers purpose, scope, and pagination adequately. It mentions returning 'video metadata and position' but is slightly vague on exact fields. Still sufficient for an AI to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover both parameters (playlist and continuation) with full detail. The tool description adds no new information about parameter semantics beyond 'pagination' context, which is already implied by the schema. With 100% schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists videos in a YouTube playlist in order with pagination, and specifies it returns video metadata and position. The verb 'list' and resource 'videos in a YouTube playlist' are explicit, and it distinguishes itself from siblings like search_youtube and list_channel_videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool: for any public or unlisted playlist identified by URL/ID. It implies that this is the relevant tool for playlist content, but does not explicitly discuss when not to use it or compare against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a YouTube @handle, channel URL, video URL, or raw channel ID into canonical channel info (channel ID, name, handle, subscriber count, video count, avatar). Call this first when you only have a handle or URL but need a channel ID for the other channel-scoped tools.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | @handle (e.g. '@MrBeast'), channel URL, video URL, or UC... channel ID. All common forms are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description doesn't need to restate safety. It adds value by detailing what the tool returns (channel ID, name, stats). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first explains functionality and output, second gives usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully covers purpose, output, and usage context. Minor omissions (e.g., error handling) are acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is fully described in the schema with examples. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves various input forms into canonical channel info, listing specific output fields. It distinguishes from sibling tools by focusing on resolution of handles/URLs to IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this first when you only have a handle or URL but need a channel ID for the other channel-scoped tools,' providing clear when-to-use and linking to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a video to the authenticated user's Library. Three modes via kind: 'asr' bookmarks the video and flips has_asr (use after a successful transcribe_video → fetch_transcript flow); 'summary' uploads a summary blob; 'both' does both at once. Idempotent: saving the same video twice updates the existing entry.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | YouTube video ID (11 chars). | |
| kind | Yes | 'asr' (bookmark + flip has_asr), 'summary' (upload summary text), or 'both'. | |
| title | No | Video title (for display in the user's Library list). | |
| author | No | Channel / author name. | |
| thumbnail | No | Thumbnail URL. | |
| video_url | No | Full YouTube URL. | |
| language | No | Video language code (ISO 639-1). | |
| text | No | Summary text. REQUIRED when kind='summary' or kind='both'. Plain text or markdown — use the `format` param to declare which. | |
| locale | No | Summary locale (e.g. 'en', 'zh'). Used with kind='summary' or kind='both'. | |
| format | No | Summary format: 'markdown' (default) or 'text'. Use 'markdown' if your text contains **bold**, bullets, headings, or code fences so the web UI renders it; use 'text' for plain prose. | |
| model | No | Optional model identifier, e.g. 'claude-opus-4'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, readOnlyHint=false), the description adds meaningful behavioral details: idempotent updates existing entry, effect of each mode (bookmarks, flips has_asr, uploads summary), and that 'text' is required for summary modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the main action, then elaborate modes and idempotency. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers modes, idempotency, and prerequisites for 'asr'. It lacks information about the response/return value (no output schema), but otherwise is adequate for a save operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides 100% coverage with descriptions. The description adds value by explaining the `kind` values and their usage, and clarifying that `text` is required for 'summary'/'both' and giving guidance on `format`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save a video to the authenticated user's Library' with specific verb and resource. It distinguishes three modes via `kind`, making the purpose distinct from sibling tools like fetch_transcript or list_library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode, e.g., 'asr' after a transcribe_video -> fetch_transcript flow, and mentions idempotent behavior. It does not explicitly exclude alternatives or state when not to use, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for specific videos within a single YouTube channel. Restricts results to the given channel. Use after resolve_channel if starting from a handle. Useful for 'find Karpathy's video about backpropagation' style queries.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | @handle, channel URL, or UC... channel ID. | |
| q | Yes | Search query (matched against video title and description within the channel). | |
| limit | No | Max results (1-50, default 30). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only behavior (readOnlyHint: true) and non-destructive nature. The description adds the behavioral detail of restricting results to a single channel, but does not provide further behavioral context (e.g., rate limits, pagination). Since annotations cover safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the purpose and usage context. Every sentence adds value: the first states what it does, the second gives a practical example and workflow hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 scalar parameters, no output schema) and rich annotations (readOnly, idempotent, openWorld), the description is sufficiently complete. It mentions a legitimate use case and integration with resolve_channel, which is helpful. Slightly more detail on return format or error conditions would elevate it further, but it's already strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (channel, q, limit) with clear descriptions, achieving 100% coverage. The description adds no additional meaning beyond summarizing the channel restriction, so it meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for specific videos within a single YouTube channel, using a specific verb ('Search') and resource ('videos within a single YouTube channel'). It distinguishes from sibling tools like search_youtube by emphasizing channel restriction and suggesting a use case (e.g., 'find Karpathy's video about backpropagation').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: 'Use after resolve_channel if starting from a handle' and 'Restricts results to the given channel,' which guides the agent on when to use it. While it doesn't explicitly state alternatives or when not to use, the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search YouTube globally for videos, channels, or playlists on any topic. Returns up to 50 results with metadata. Use this for topic-based discovery when the user has not specified a channel — for searching within a known channel use search_channel_videos instead.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query (same syntax as YouTube's search bar, e.g. 'rust async tutorial', 'lex fridman dario amodei'). | |
| type | No | Search type: 'video', 'channel', or 'playlist'. Default: 'video'. | |
| limit | No | Max results (1-50, default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds key behavioral detail (returns up to 50 results with metadata) beyond annotations which already indicate read-only and non-destructive nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: first states purpose and constraints, second gives usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations (readOnlyHint true, etc.) and thorough schema, the description is complete. It covers result limits, metadata, and differentiates from sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions; the tool description does not add significant new meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search YouTube globally' with specific resource types (videos, channels, playlists). Distinguishes from sibling search_channel_videos by noting global vs within-channel context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use (topic-based discovery without channel) and when to use alternative (search_channel_videos for within a known channel).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an asynchronous AI ASR (Whisper) transcription of a YouTube video. Returns immediately with a task_id and estimated_wait_seconds; the actual transcription runs in the background. Poll status with get_asr_task. Use this when fetch_transcript returned NO_CAPTIONS or when the video has no captions. Costs 5 credits, debited only on successful completion.
| Name | Required | Description | Default |
|---|---|---|---|
| video_url | Yes | YouTube URL (watch, youtu.be, shorts, or embed form). Full URL preferred. | |
| lang | No | Optional language hint (ISO 639-1, e.g. 'en', 'zh'). Omit to auto-detect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async behavior (returns immediately with task_id and estimated_wait_seconds), background processing, need to poll with get_asr_task, and cost of 5 credits debited on success. These go beyond annotations which only provide hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place. First sentence states action and nature, second sentence tells what returns and follow-up, third sentence gives condition and cost. No waste, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects: action, async nature, return values, next steps, usage condition, and cost. Missing some edge cases like error handling or timeouts, but overall sufficient for a tool with annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with detailed descriptions for both parameters. The tool description adds no new parameter meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Start an asynchronous AI ASR (Whisper) transcription of a YouTube video.' Specifies verb, resource, and async nature. Distinguishes from siblings like fetch_transcript and get_asr_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when fetch_transcript returned NO_CAPTIONS or when the video has no captions.' Provides context on when to use versus alternatives, and instructs to poll with get_asr_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.2fetch_transcript6 fields changedInput schema / properties / langAdded value: +{
+ "description": "ISO 639-1 language code to select among multilingual captions (e.g. 'en', 'zh', 'ja'). Omit for the video's default language.",
+ "type": "string"
+}Input schema / properties / languageRemoved value: -{
- "description": "Optional ISO 639-1 language code to select among multilingual captions (e.g., 'en', 'zh', 'es', 'ja'). If omitted, the video's primary caption track is returned.",
- "type": "string"
-}Input schema / properties / saveAdded value: +{
+ "description": "When true, also save the video to the user's Library in the same call. Bookmarks the meta row and flips has_asr when the transcript was produced by our ASR. Does NOT upload a summary — use save_to_library with kind='summary' or kind='both' for that.",
+ "type": "boolean"
+}Input schema / properties / video_idAdded value: +{
+ "description": "YouTube video ID (e.g. 'dQw4w9WgXcQ') or full YouTube URL.",
+ "minLength": 5,
+ "type": "string"
+}Input schema / properties / video_id_or_urlRemoved value: -{
- "description": "YouTube video ID or any URL form (watch / youtu.be / shorts).",
- "minLength": 5,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "video_id_or_url"
-]New value: +[
+ "video_id"
+]fetch_video_info3 fields changedInput schema / properties / video_idAdded value: +{
+ "description": "11-char YouTube video ID (e.g. 'dQw4w9WgXcQ') or full URL (watch, youtu.be, shorts, embed, live).",
+ "minLength": 5,
+ "type": "string"
+}Input schema / properties / video_id_or_urlRemoved value: -{
- "description": "YouTube video ID (e.g., 'dQw4w9WgXcQ') or any YouTube URL form (watch URL, youtu.be short link, or shorts URL). Both formats are accepted.",
- "minLength": 5,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "video_id_or_url"
-]New value: +[
+ "video_id"
+]get_asr_task1 field changedInput schema / properties / task_id / descriptionPrevious value: -"Task ID returned from a previous transcribe_video call."New value: +"Task ID returned by transcribe_video."get_channel_latest_videos4 fields changedInput schema / properties / channelAdded value: +{
+ "description": "@handle (e.g. '@mkbhd'), channel URL, or UC... channel ID.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / channel_idRemoved value: -{
- "description": "Canonical channel ID starting with 'UC'.",
- "pattern": "^UC[A-Za-z0-9_-]+$",
- "type": "string"
-}Input schema / properties / limitRemoved value: -{
- "description": "Max number of recent videos to return (default 10, max 50).",
- "maximum": 50,
- "minimum": 1,
- "type": "integer"
-}Input schema / requiredPrevious value: -[
- "channel_id"
-]New value: +[
+ "channel"
+]get_library_item4 fields changedInput schema / properties / idAdded value: +{
+ "description": "Library item id (returned by list_library or save_to_library).",
+ "type": "number"
+}Input schema / properties / item_idRemoved value: -{
- "description": "Library item ID (returned by list_library or save_to_library).",
- "minLength": 1,
- "type": "string"
-}Input schema / properties / localeAdded value: +{
+ "description": "Summary locale to fetch (e.g. 'en', 'zh'). Defaults to 'en'.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "item_id"
-]New value: +[
+ "id"
+]list_channel_videos5 fields changedInput schema / properties / channelAdded value: +{
+ "description": "@handle, channel URL, or UC... channel ID. Required for the first page; omit on subsequent pages and pass `continuation` instead.",
+ "type": "string"
+}Input schema / properties / channel_idRemoved value: -{
- "description": "Canonical channel ID starting with 'UC' (use resolve_channel if you only have a handle).",
- "pattern": "^UC[A-Za-z0-9_-]+$",
- "type": "string"
-}Input schema / properties / continuationAdded value: +{
+ "description": "Pagination token from a previous response's `continuation` field. Omit for the first page.",
+ "type": "string"
+}Input schema / properties / page_tokenRemoved value: -{
- "description": "Opaque pagination cursor from a previous response's `next_page_token`. Omit for the first page.",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "channel_id"
-]list_library7 fields changedInput schema / properties / favoriteAdded value: +{
+ "description": "When true, return only items the user has favorited.",
+ "type": "boolean"
+}Input schema / properties / limit / descriptionPrevious value: -"Max items to return (default 20, max 100)."New value: +"Max items per page (1-100, default 20)."Input schema / properties / limit / typePrevious value: -"integer"New value: +"number"Input schema / properties / offsetAdded value: +{
+ "description": "Pagination offset (number of items to skip).",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / qAdded value: +{
+ "description": "Substring match on title and author.",
+ "type": "string"
+}Input schema / properties / queryRemoved value: -{
- "description": "Optional free-text search; matched against item title, channel, and tags.",
- "type": "string"
-}Input schema / properties / tagRemoved value: -{
- "description": "Optional exact-match tag filter (single tag).",
- "type": "string"
-}list_playlist_videos4 fields changedInput schema / properties / continuationAdded value: +{
+ "description": "Pagination token from a previous response's `continuation` field. Omit for the first page.",
+ "type": "string"
+}Input schema / properties / playlistAdded value: +{
+ "description": "Playlist URL or ID (typically starts with 'PL', 'UU', 'LL', or 'FL'). Required for the first page.",
+ "type": "string"
+}Input schema / properties / playlist_idRemoved value: -{
- "description": "YouTube playlist ID (typically starts with 'PL', 'UU', 'LL', or 'FL').",
- "minLength": 2,
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "playlist_id"
-]resolve_channel3 fields changedInput schema / properties / identifierRemoved value: -{
- "description": "Channel identifier in any common form: handle (`@mkbhd`), vanity URL (`youtube.com/@mkbhd`), channel URL (`youtube.com/channel/UC...`), or raw channel ID (`UC...`).",
- "minLength": 1,
- "type": "string"
-}Input schema / properties / inputAdded value: +{
+ "description": "@handle (e.g. '@MrBeast'), channel URL, video URL, or UC... channel ID. All common forms are accepted.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "identifier"
-]New value: +[
+ "input"
+]save_to_library14 fields changedInput schema / properties / authorAdded value: +{
+ "description": "Channel / author name.",
+ "type": "string"
+}Input schema / properties / formatAdded value: +{
+ "description": "Summary format: 'markdown' (default) or 'text'. Use 'markdown' if your text contains **bold**, bullets, headings, or code fences so the web UI renders it; use 'text' for plain prose.",
+ "enum": [
+ "markdown",
+ "text"
+ ],
+ "type": "string"
+}Input schema / properties / kindAdded value: +{
+ "description": "'asr' (bookmark + flip has_asr), 'summary' (upload summary text), or 'both'.",
+ "enum": [
+ "asr",
+ "summary",
+ "both"
+ ],
+ "type": "string"
+}Input schema / properties / languageAdded value: +{
+ "description": "Video language code (ISO 639-1).",
+ "type": "string"
+}Input schema / properties / localeAdded value: +{
+ "description": "Summary locale (e.g. 'en', 'zh'). Used with kind='summary' or kind='both'.",
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional model identifier, e.g. 'claude-opus-4'.",
+ "type": "string"
+}Input schema / properties / tagsRemoved value: -{
- "description": "Optional tags for organizing the saved item (e.g., ['ai', 'paper-review']).",
- "items": {
- "minLength": 1,
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / textAdded value: +{
+ "description": "Summary text. REQUIRED when kind='summary' or kind='both'. Plain text or markdown — use the `format` param to declare which.",
+ "type": "string"
+}Input schema / properties / thumbnailAdded value: +{
+ "description": "Thumbnail URL.",
+ "type": "string"
+}Input schema / properties / titleAdded value: +{
+ "description": "Video title (for display in the user's Library list).",
+ "type": "string"
+}Input schema / properties / video_idAdded value: +{
+ "description": "YouTube video ID (11 chars).",
+ "minLength": 5,
+ "type": "string"
+}Input schema / properties / video_id_or_urlRemoved value: -{
- "description": "YouTube video ID or any URL form for the video being saved.",
- "minLength": 5,
- "type": "string"
-}Input schema / properties / video_urlAdded value: +{
+ "description": "Full YouTube URL.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "video_id_or_url"
-]New value: +[
+ "video_id",
+ "kind"
+]search_channel_videos6 fields changedInput schema / properties / channelAdded value: +{
+ "description": "@handle, channel URL, or UC... channel ID.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / channel_idRemoved value: -{
- "description": "Canonical channel ID starting with 'UC'.",
- "pattern": "^UC[A-Za-z0-9_-]+$",
- "type": "string"
-}Input schema / properties / limitAdded value: +{
+ "description": "Max results (1-50, default 30).",
+ "maximum": 50,
+ "minimum": 1,
+ "type": "number"
+}Input schema / properties / qAdded value: +{
+ "description": "Search query (matched against video title and description within the channel).",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / queryRemoved value: -{
- "description": "Search keywords (matched against video title and description within the channel).",
- "minLength": 1,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "channel_id",
- "query"
-]New value: +[
+ "channel",
+ "q"
+]search_youtube7 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (default 10, max 25)."New value: +"Max results (1-50, default 20)."Input schema / properties / limit / maximumPrevious value: -25New value: +50Input schema / properties / limit / typePrevious value: -"integer"New value: +"number"Input schema / properties / qAdded value: +{
+ "description": "Search query (same syntax as YouTube's search bar, e.g. 'rust async tutorial', 'lex fridman dario amodei').",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / queryRemoved value: -{
- "description": "Search keywords (e.g., 'rust async tutorial', 'lex fridman dario amodei'). Same syntax as YouTube's search bar.",
- "minLength": 1,
- "type": "string"
-}Input schema / properties / typeAdded value: +{
+ "description": "Search type: 'video', 'channel', or 'playlist'. Default: 'video'.",
+ "enum": [
+ "video",
+ "channel",
+ "playlist"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "query"
-]New value: +[
+ "q"
+]transcribe_video4 fields changedInput schema / properties / langAdded value: +{
+ "description": "Optional language hint (ISO 639-1, e.g. 'en', 'zh'). Omit to auto-detect.",
+ "type": "string"
+}Input schema / properties / video_id_or_urlRemoved value: -{
- "description": "YouTube video ID or any URL form. Caption-less videos benefit most from this tool.",
- "minLength": 5,
- "type": "string"
-}Input schema / properties / video_urlAdded value: +{
+ "description": "YouTube URL (watch, youtu.be, shorts, or embed form). Full URL preferred.",
+ "minLength": 5,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "video_id_or_url"
-]New value: +[
+ "video_url"
+]v0.1.1fetch_transcript3 fields changedInput schema / properties / language / descriptionPrevious value: -"Optional language code (default: video's primary)"New value: +"Optional ISO 639-1 language code to select among multilingual captions (e.g., 'en', 'zh', 'es', 'ja'). If omitted, the video's primary caption track is returned."Input schema / properties / video_id_or_url / descriptionAdded value: +"YouTube video ID or any URL form (watch / youtu.be / shorts)."Input schema / properties / video_id_or_url / minLengthAdded value: +5fetch_video_info2 fields changedInput schema / properties / video_id_or_url / descriptionPrevious value: -"YouTube video ID or full URL"New value: +"YouTube video ID (e.g., 'dQw4w9WgXcQ') or any YouTube URL form (watch URL, youtu.be short link, or shorts URL). Both formats are accepted."Input schema / properties / video_id_or_url / minLengthAdded value: +5get_asr_task2 fields changedInput schema / properties / task_id / descriptionAdded value: +"Task ID returned from a previous transcribe_video call."Input schema / properties / task_id / minLengthAdded value: +1get_channel_latest_videos5 fields changedInput schema / properties / channel_id / descriptionAdded value: +"Canonical channel ID starting with 'UC'."Input schema / properties / channel_id / patternAdded value: +"^UC[A-Za-z0-9_-]+$"Input schema / properties / limit / descriptionPrevious value: -"Max items (default 10)"New value: +"Max number of recent videos to return (default 10, max 50)."Input schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1get_library_item2 fields changedInput schema / properties / item_id / descriptionAdded value: +"Library item ID (returned by list_library or save_to_library)."Input schema / properties / item_id / minLengthAdded value: +1list_channel_videos3 fields changedInput schema / properties / channel_id / descriptionAdded value: +"Canonical channel ID starting with 'UC' (use resolve_channel if you only have a handle)."Input schema / properties / channel_id / patternAdded value: +"^UC[A-Za-z0-9_-]+$"Input schema / properties / page_token / descriptionAdded value: +"Opaque pagination cursor from a previous response's `next_page_token`. Omit for the first page."list_library5 fields changedInput schema / properties / limit / descriptionAdded value: +"Max items to return (default 20, max 100)."Input schema / properties / limit / maximumAdded value: +100Input schema / properties / limit / minimumAdded value: +1Input schema / properties / query / descriptionAdded value: +"Optional free-text search; matched against item title, channel, and tags."Input schema / properties / tag / descriptionAdded value: +"Optional exact-match tag filter (single tag)."list_playlist_videos2 fields changedInput schema / properties / playlist_id / descriptionAdded value: +"YouTube playlist ID (typically starts with 'PL', 'UU', 'LL', or 'FL')."Input schema / properties / playlist_id / minLengthAdded value: +2resolve_channel2 fields changedInput schema / properties / identifier / descriptionPrevious value: -"Channel handle (@name), URL, or ID"New value: +"Channel identifier in any common form: handle (`@mkbhd`), vanity URL (`youtube.com/@mkbhd`), channel URL (`youtube.com/channel/UC...`), or raw channel ID (`UC...`)."Input schema / properties / identifier / minLengthAdded value: +1save_to_library4 fields changedInput schema / properties / tags / descriptionAdded value: +"Optional tags for organizing the saved item (e.g., ['ai', 'paper-review'])."Input schema / properties / tags / items / minLengthAdded value: +1Input schema / properties / video_id_or_url / descriptionAdded value: +"YouTube video ID or any URL form for the video being saved."Input schema / properties / video_id_or_url / minLengthAdded value: +5search_channel_videos4 fields changedInput schema / properties / channel_id / descriptionAdded value: +"Canonical channel ID starting with 'UC'."Input schema / properties / channel_id / patternAdded value: +"^UC[A-Za-z0-9_-]+$"Input schema / properties / query / descriptionAdded value: +"Search keywords (matched against video title and description within the channel)."Input schema / properties / query / minLengthAdded value: +1search_youtube3 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Maximum number of results to return (default 10, max 25).",
+ "maximum": 25,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / query / descriptionPrevious value: -"Search query"New value: +"Search keywords (e.g., 'rust async tutorial', 'lex fridman dario amodei'). Same syntax as YouTube's search bar."Input schema / properties / query / minLengthAdded value: +1transcribe_video2 fields changedInput schema / properties / video_id_or_url / descriptionAdded value: +"YouTube video ID or any URL form. Caption-less videos benefit most from this tool."Input schema / properties / video_id_or_url / minLengthAdded value: +5v0.1.0fetch_transcriptfetch_video_infoget_asr_taskget_channel_latest_videosget_library_itemlist_channel_videoslist_librarylist_playlist_videosresolve_channelsave_to_librarysearch_channel_videossearch_youtubetranscribe_videoEach tool has a clear, distinct purpose: fetching transcripts vs. metadata, searching globally vs. within a channel, library management, etc. Overlapping tools like list_channel_videos and get_channel_latest_videos are differentiated by convenience vs. full pagination.
All tools follow a consistent verb_noun snake_case pattern (e.g., fetch_transcript, list_library, resolve_channel). No mixing of styles, making it easy to predict tool names.
13 tools is well-scoped for a YouTube transcript and library management server. Each tool covers a specific operation without unnecessary bloat or missing essential functionality.
The set covers core workflows: fetching transcripts, generating via ASR, searching, listing channels/playlists, and library management. A minor gap is the lack of an explicit delete tool for library items, but idempotent saves mitigate this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SubDownload exposes YouTube as an MCP-native data source. Connect via OAuth and your AI agent can summarize videos, fetch full transcripts (even for videos with no captions, via AI ASR), search across channels, and save everything into a private knowledge base. Works with Claude, ChatGPT, Cursor, and 40+ MCP clients. Free credits on signup, no card required.
An MCP server that gives any LLM or agent clean YouTube transcripts on demand: a single video, a whole channel, or a playlist, plus AI cleanup of auto-generated captions. API-key auth, credit-based, same backend as the public v1 API. Get a free API key with 25 free credits at youtubetranscriptdownload.com/account.
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents. No signup.
💯 The fastest YouTube transcript + YouTube search MCP for AI agents. Try for free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SubDownload/subdownload-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
