BulkTranscripts YouTube
Server Details
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents.
- Status
- Healthy
- Uptime
- 68.3% over 62 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
Scored across 10 tools
Most tools target distinct actions: single vs batch transcript fetch (get_transcript/get_transcripts), within-channel vs global search (search_channel/search_youtube), and bulk orchestration (start_bulk_extract/get_bulk_status/list_bulk_results) are all clearly separable. The main overlap is get_channel_videos vs get_latest_videos, which both return a channel's videos, though the descriptions clearly distinguish full paid listing from free newest-15 RSS monitoring.
All names are snake_case with a consistent verb_noun pattern: get_/list_/search_/start_ prefixes applied uniformly. No style mixing or vague verbs, so the surface reads predictably.
10 tools is well within the ideal 3-15 range and each maps to a distinct capability (discovery, single/batch/bulk extraction, job monitoring). No redundant or filler tools inflate the surface.
The core workflow—discover videos, fetch transcripts (single, batch, bulk), and monitor results—is fully covered with lifecycle status and pagination. Gaps remain: there is no tool to browse the account's saved transcript library (central to the free-repeat model) and no way to stop a running bulk job despite a 'stopped' status being referenced.
Available Tools
10 toolsget_bulk_statusCheck a bulk jobARead-onlyIdempotentInspect
Progress of a bulk extraction job: status (running, completed, stopped, failed), total, completed, failed, skipped (no captions), quota (not attempted for lack of credits), remaining, and check_again_in_seconds, the suggested wait before the next check (0 means the job is finished). Free.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run_id of the bulk job. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| phase | No | |
| quota | No | Videos not attempted because credits ran out. |
| total | No | |
| cached | No | |
| failed | No | |
| run_id | Yes | |
| source | Yes | |
| status | Yes | running, completed or stopped. |
| billing | Yes | |
| skipped | No | Videos without captions; never charged. |
| stopped | No | |
| completed | No | |
| remaining | No | |
| interrupted | No | |
| videos_found | No | Null until a large channel has been listed. |
| check_again_in_seconds | Yes | Do not poll sooner than this. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavior: the poll-again semantics with the 0-means-finished termination signal, the meaning of each status bucket (skipped = no captions, quota = out of credits), and the cost note 'Free.'
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?
One dense sentence, front-loaded with the resource, then the returned fields and the polling hint. No wasted words, and the 'Free' cost note is placed last where it is easy to scan.
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?
With an output schema present, enumerating return fields is somewhat redundant, but the operational detail that is NOT in the schema — the stop condition for polling and the credit-free cost — is included, so an agent has enough to call and loop this 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?
There is a single parameter (run_id) with 100% schema description coverage, so the schema already carries the parameter meaning. The description adds nothing about run_id syntax or where it comes from; baseline 3 applies when the schema does the heavy lifting.
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 names the specific resource ('bulk extraction job') and the exact information returned (progress status), so an agent can tell it apart from start_bulk_extract and list_bulk_results. It does not, however, explicitly contrast itself with those siblings.
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?
Usage is only implied through 'check_again_in_seconds, the suggested wait before the next check (0 means the job is finished)', which signals a polling pattern but never states when to call this versus list_bulk_results. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_channel_videosList a channel's videosARead-onlyIdempotentInspect
List the videos of a YouTube channel (id, title, duration, URL) without fetching transcripts. Accepts @handle, channel URL, or UC… channel id. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max videos to list, default 100. | |
| channel | Yes | Channel @handle, URL, or UC… id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| title | No | |
| billing | Yes | |
| channel | Yes | |
| results | Yes | |
| has_more | No | True when the listing stopped at `limit`. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real behavioral value on top: the lightweight no-transcript behavior and the 1-credit cost, which an agent needs for budgeting and tool choice.
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 with no filler: the action and return fields are front-loaded, and the transcript exclusion plus cost land in the second sentence. Nothing is redundant or padded.
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?
With an output schema present, return values need not be re-explained, and the description still summarizes them helpfully. Cost and the transcript exclusion round out what an agent needs to call this correctly; only explicit sibling routing is missing.
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%, so both 'channel' and 'limit' are fully documented in the schema. The description restates the accepted channel formats ('@handle, channel URL, or UC… channel id') but adds no syntax, default, or constraint beyond what the schema already provides; baseline 3 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?
States a specific verb and resource ('List the videos of a YouTube channel') and enumerates the returned fields (id, title, duration, URL), which lets an agent distinguish it from the transcript siblings. It stops short of naming the closest alternatives among siblings (get_latest_videos, get_playlist_videos), so differentiation is only partial.
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?
'Without fetching transcripts' and 'Costs 1 credit' imply usage against the heavier transcript tools, which is useful context. However there is no explicit when-to-use guidance versus get_latest_videos, get_playlist_videos, or search_channel, so the selector logic is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_latest_videosTrack new uploads (free)ARead-onlyIdempotentInspect
Get a channel's newest uploads (up to 15) with publish dates, from YouTube's RSS feed (or a lightweight listing when the feed is unavailable). Always free — no credit charged — so it is ideal for monitoring channels, daily recaps, and 'did they post this week?' checks. Accepts @handle, URL, or UC… id.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Channel @handle, URL, or UC… id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| source | No | feed, or listing when the RSS feed was unavailable (then `published` may be null). |
| channel | No | |
| results | Yes | |
| channel_id | No | |
| billing_note | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds valuable behavioral context: it is free (no credit charged), uses a specific data source (RSS feed) with a fallback (lightweight listing when feed unavailable), and caps results at 15. These details inform the agent about how the tool behaves at runtime, which the annotations do not provide.
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 compact and well-structured: the core action appears first, followed by the source and fallback, then pricing, then use cases, then accepted formats. Every sentence adds distinct value, and there is no filler.
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 single-parameter tool with an output schema, the description covers all necessary operational aspects: what it returns (uploads with publish dates), the limit, the data source and fallback, cost, and identifier formats. An agent has everything needed to invoke it appropriately without missing details.
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 schema description for 'channel' already explains 'Channel @handle, URL, or UC… id.' In the tool description, the same information is repeated ('Accepts @handle, URL, or UC… id.'). Since schema coverage is 100% and the description adds no new parameter-level detail, this stays at the baseline of 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?
The description states a specific verb ('get'), a specific resource ('a channel's newest uploads'), a limit ('up to 15'), and includes 'publish dates' – fully distinguishing it from siblings like search_channel or get_channel_videos. It is concrete and unambiguous about what the tool returns.
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?
It explicitly lists ideal use cases ('monitoring channels, daily recaps, and 'did they post this week?' checks'), giving clear context for when to call it. However, it does not mention when not to use it or alternatives, so it stops short of explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_playlist_videosList a playlist's videosARead-onlyIdempotentInspect
List every video in a YouTube playlist, in playlist order (courses and series keep their sequence). Accepts a playlist URL or bare playlist id (13, 18, 26 or 34 characters — all valid). Public and unlisted playlists only: YouTube reports a private playlist as nonexistent (error playlist_private) until its owner sets Visibility to Unlisted. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max videos to list, default 100. | |
| playlist | Yes | Playlist URL or id (the list= value). |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| title | No | |
| billing | Yes | |
| results | Yes | |
| has_more | No | True when the listing stopped at `limit`. |
| playlist | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description adds material context they cannot carry: a cost of 1 credit, the specific failure code playlist_private, and the visibility prerequisite that produces it. This is exactly the behavioral context that goes beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, all front-loaded: what it does, accepted input forms, visibility constraint with error code, then cost. Nothing is padding or redundant restatement of the title.
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?
With only 2 params, full schema coverage and an output schema, the description needs to supply access constraints, error semantics and cost — and it does all three. An agent can invoke this correctly and anticipate the private-playlist failure mode without further inference.
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%, so the baseline is 3, but the description adds genuine semantics the schema lacks: that 'playlist' accepts either a full URL or a bare id, and that valid id lengths are 13, 18, 26 or 34 characters. The 'limit' parameter is left to the schema, which documents it adequately.
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?
States a specific verb+resource ('List every video in a YouTube playlist') and pins the scope to a single playlist, which cleanly separates it from channel-wide siblings like get_channel_videos and get_latest_videos. The ordering guarantee further distinguishes its output from a generic search.
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?
Gives clear preconditions: public and unlisted playlists only, with an explanation of what happens for private ones (reported as nonexistent, error playlist_private). It does not name a sibling alternative or state when to prefer another tool, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcriptGet YouTube video transcriptAInspect
Fetch the full transcript of one YouTube video as clean text with metadata (title, channel, duration, upload date, language). Accepts a watch URL, youtu.be link, Shorts URL, or bare 11-character video id. Costs 1 credit the first time it is added to this account's library; repeat reads are free. Set include_segments to true only when per-line timestamps are needed (much larger output).
| Name | Required | Description | Default |
|---|---|---|---|
| fresh | No | Bypass the cache and re-extract (costs a credit). Default false. | |
| video | Yes | YouTube video URL or 11-character video id. | |
| language | No | Preferred caption language code, e.g. 'en' or 'de'. Defaults to 'en', falling back to whatever exists. | |
| include_segments | No | Include the timestamped segment list. Default false — the plain text is usually what you want. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| text | Yes | |
| title | Yes | |
| cached | No | True when served from this account's library (free). |
| source | No | manual_caption or auto_caption. |
| billing | Yes | |
| channel | Yes | |
| duration | No | |
| language | No | |
| segments | No | Only when include_segments is true. |
| video_id | Yes | |
| paragraphs | Yes | Silence-grouped paragraphs; best for reading and chunking. |
| word_count | No | |
| upload_date | No | |
| duration_text | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains the non-obvious economics that justify readOnlyHint=false: the first fetch costs 1 credit because the video is added to the account's library, while repeat reads are free. It also discloses that include_segments produces a much larger payload and that 'fresh' bypasses the cache. This adds real context beyond the annotations rather than contradicting them.
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, front-loaded with the core action, then accepted inputs, then cost and the segments caveat. Every sentence carries information the agent needs; no filler.
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?
An output schema exists, so return values need not be described, and the description still names the metadata fields returned. Input formats, credit cost, caching behavior, and the segments trade-off are all covered for a 4-parameter read tool.
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%, so the baseline is 3, but the description adds meaning beyond the schema: it enumerates accepted video input formats (watch URL, youtu.be, Shorts, bare 11-char id) and warns that include_segments substantially increases output size. The cost implications of a repeat fetch are also clarified.
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?
States a specific verb and resource ('Fetch the full transcript of one YouTube video as clean text') and scopes it to a single video, which cleanly separates it from the bulk sibling get_transcripts. The accepted input formats and the returned metadata are spelled out, so an agent knows exactly what it gets.
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?
Gives clear conditional guidance for include_segments ('only when per-line timestamps are needed') and implies single-video scope versus the plural get_transcripts sibling. It stops short of explicitly naming that sibling as the alternative for multi-video work, so it is context-rich but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcriptsGet many transcripts at onceAIdempotentInspect
Fetch transcripts for up to 20 videos in one call — pass an array of YouTube URLs or ids. Videos are fetched in parallel and the call returns within about 40 seconds; any video still being fetched at that point is listed in failed with code still_fetching, is not charged, and keeps fetching in the background, so a repeat call with those ids 15-30 seconds later returns them instantly. Each new library addition costs 1 credit; repeats from this account's library are free. Videos without captions are reported per-item and do not fail the batch. One call counts as one request against the rate limit however many videos it holds. If the balance runs out, completed items are returned with partial=true and an out_of_credits stopped block.
| Name | Required | Description | Default |
|---|---|---|---|
| videos | Yes | Up to 20 YouTube video URLs or ids. | |
| language | No | Preferred caption language code. Default 'en'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| failed | Yes | |
| billing | Yes | |
| partial | No | Present and true when credits ran out mid-batch. |
| stopped | No | |
| requested | Yes | |
| succeeded | Yes | |
| transcripts | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: ~40 second wall clock, per-item failures (still_fetching, no captions) that do not fail the batch, background continuation with free repeat retrieval, 1 credit per new library addition with repeats free, one request per call against the rate limit, and out_of_credits handling with partial=true. This is far richer than the structured 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?
Front-loaded with the purpose, then each subsequent sentence carries a distinct operational fact (timing, failure codes, cost, rate limit, credit exhaustion) with no filler or repetition.
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?
Although an output schema exists, the description still explains the failure-mode fields (failed, still_fetching, partial, out_of_credits) that matter for correct handling. For a 2-parameter batch tool with annotations and an output schema, nothing an agent needs to call or interpret it is missing.
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%, so both parameters are already documented; the description restates the array-of-URLs-or-ids input and the 20-item cap without adding syntax or format detail beyond the schema. Baseline 3 applies since the schema does the heavy lifting, though the free-repeat note adds minor meaning about id reuse.
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?
States a specific verb and resource with explicit scope: 'Fetch transcripts for up to 20 videos in one call.' The batching scope and the URL-or-id input form make it clearly distinct from the single-video sibling get_transcript.
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?
Clearly frames the batch context (multiple videos, one call, one rate-limit request) and gives concrete retry guidance: re-call with the still_fetching ids after 15-30 seconds. It never explicitly names get_transcript as the single-video alternative, so the routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_bulk_resultsList a bulk job's resultsARead-onlyIdempotentInspect
One page of per-video outcomes for a bulk job: video id, title, channel, duration, word count and status (ok, cached, or error with a code). Never includes transcript text; every ok or cached video is in the library and free to read again. next_cursor from one page continues to the next. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items per page, default 50. | |
| cursor | No | next_cursor from the previous page; omit for the first page. | |
| run_id | Yes | The run_id of the bulk job. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| items | Yes | |
| total | No | |
| run_id | Yes | |
| status | Yes | |
| next_cursor | Yes | Pass back as `cursor` for the next page; null on the last page. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not carry: no transcript text is returned, ok/cached results remain in the library, and the call is free.
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?
Four short sentences, front-loaded with what the page contains, followed by the exclusion, the library consequence, pagination, and cost. Every sentence carries distinct information and none is filler.
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?
With an output schema present, the description need not restate the return shape, yet it still covers pagination continuation, cost, and the important negative constraint (no transcript text). An agent has everything it needs to call and interpret the result.
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 all three parameters (run_id, limit, cursor) are already documented in the schema. The description restates cursor semantics ('next_cursor from one page continues to the next') without adding format or default detail, matching the baseline-3 case where the schema does the heavy lifting.
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 states a specific verb and resource ('one page of per-video outcomes for a bulk job') and enumerates the returned fields (video id, title, channel, duration, word count, status). It implicitly separates itself from get_bulk_status by focusing on per-video outcomes, but never names that sibling, so the differentiation is left to inference.
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?
Pagination guidance ('next_cursor from one page continues to the next') and a cost signal ('Free') are given, and the note that ok/cached videos are re-readable implies a follow-up path. However there is no explicit when-to-use statement relative to get_bulk_status or get_transcript, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_channelSearch inside a channelARead-onlyIdempotentInspect
Search within one channel's uploads to find its videos on a topic — great for researching what a creator has said about something without listing the whole archive. Accepts @handle, channel URL, or UC… id. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 10. | |
| query | Yes | Topic to search for within the channel. | |
| channel | Yes | Channel @handle, URL, or UC… id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| query | Yes | |
| billing | Yes | |
| channel | Yes | |
| results | Yes | |
| channel_title | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds the unique cost of 1 credit and clarifies accepted channel formats, which are useful operational facts beyond the schema. No contradiction with 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?
Two concise sentences with no filler. The purpose is front-loaded, followed by use case, accepted formats, and cost – each earning its place. Efficient and scannable.
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 read-only search tool with an output schema, the description covers purpose, use case, input formats, and cost. Nothing an agent needs to decide whether to call it or how to call it correctly is missing.
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 channel, query, and limit. The description repeats the channel format but adds no new semantic detail about query or limit, keeping it at 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?
States a specific verb ('Search') and resource ('one channel's uploads') with the intent of finding videos on a topic. The description explicitly distinguishes it from listing the whole archive, which separates it from get_channel_videos and positions it against the broader 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?
Gives a clear use case ('researching what a creator has said about something') and implies a channel-scoped alternative to global search. It does not explicitly name sibling tools or provide when-not-to-use guidance, but the 'without listing the whole archive' hint covers the main exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_youtubeSearch YouTubeARead-onlyIdempotentInspect
Search YouTube by keyword for videos, channels, or playlists (set type). Returns titles, ids, and URLs — useful for research, discovery, and finding videos to transcribe. Costs 1 credit per search.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | What to search for. Default video. | |
| limit | No | Max results, default 10. | |
| query | Yes | Search terms, e.g. 'claude code tutorial'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| count | Yes | |
| query | Yes | |
| billing | Yes | |
| results | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds useful behavioral context beyond those: it returns titles/ids/URLs and costs 1 credit per search, which helps an agent understand side effects and pricing.
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 cover the action, scope, output, use cases, and cost with no filler. The most important information is front-loaded and every clause 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 search tool with fully described parameters, safety annotations, and an output schema, this description is complete. An agent can decide when to use it, invoke it with the right parameters, and understand both behavior and cost.
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 query, type, and limit in detail. The description only lightly reinforces the type enum ('videos, channels, or playlists'), adding no substantial meaning 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 ('Search YouTube by keyword') and the resource scope ('videos, channels, or playlists (set type)'), which is specific and distinguishable from the 'get_*' sibling tools. It does not explicitly name sibling alternatives like search_channel, so it falls short of full 5 differentiation.
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 gives concrete use cases: 'research, discovery, and finding videos to transcribe.' This is clear context for when the tool is appropriate, though it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_bulk_extractStart a bulk extraction jobAInspect
Extract every transcript of a YouTube channel, playlist or video list in the background. Returns immediately with a run_id; the server discovers the videos (free), fetches each transcript into this account's library (1 credit per new transcript, cache hits and repeats free, failures never charged) and keeps going after this call returns. Transcripts it adds are free to read again from the library. Up to 1,000 videos per job, 2 jobs per account at a time; suited to anything larger than about 20 videos.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Channel (@handle or URL), playlist URL/id, or a single video URL. | |
| content | No | For channels: which tab to read. Default 'videos' (long-form uploads); 'shorts' or 'live' for those tabs. | |
| language | No | Preferred caption language code. Default 'en'. | |
| start_at | No | 1-based position to start from, newest first (default 1). For sources over 1,000 videos run blocks: start_at=1, then 1001, 2001…; the job status gives next_start_at when a block was full. | |
| max_videos | No | Cap on videos to process, default 100. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| phase | No | |
| quota | No | Videos not attempted because credits ran out. |
| total | No | |
| cached | No | |
| failed | No | |
| run_id | Yes | |
| source | Yes | |
| status | Yes | running, completed or stopped. |
| billing | Yes | |
| skipped | No | Videos without captions; never charged. |
| stopped | No | |
| completed | No | |
| remaining | No | |
| interrupted | No | |
| videos_found | No | Null until a large channel has been listed. |
| check_again_in_seconds | Yes | Do not poll sooner than this. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: returns immediately with a run_id, keeps working after the call returns, discovery is free while fetching costs 1 credit per new transcript with cache hits and failures free, plus quotas of 1,000 videos per job and 2 concurrent jobs. None of this is inferable from the annotation set, which only flags it as non-read-only and open-world.
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?
Front-loaded with the core action and the async/run_id behavior, and each subsequent clause adds distinct information (billing, quotas, sizing). It is a dense single paragraph rather than cleanly separated points, which costs a little readability.
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?
Output schema exists so return-shape detail is unnecessary, and the description still explains the asynchronous lifecycle, cost model and job limits an agent needs before firing the call. Nothing required to invoke it correctly is missing.
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%, so url, content, language, start_at and max_videos are all documented in the schema itself, including the block-splitting convention. The description restates the 1,000-video cap but adds no syntax or format detail beyond the schema, so the baseline of 3 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?
States a specific verb (extract) plus resource (every transcript of a YouTube channel, playlist or video list) with the added qualifier that it runs in the background. This clearly differentiates it from synchronous siblings like get_transcript and get_transcripts.
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?
"Suited to anything larger than about 20 videos" gives an explicit size-based criterion for when to prefer this over per-video extraction, and the pointer to job status for next_start_at hints at the follow-up sibling. It stops short of naming get_transcripts or get_bulk_status as alternatives by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
get_bulk_status1 field changed- changed
Input schema / properties / run_id / descriptionPrevious value: -"The run_id from start_bulk_extract."New value: +"The run_id of the bulk job."
- Changed
list_bulk_results1 field changed- changed
Input schema / properties / run_id / descriptionPrevious value: -"The run_id from start_bulk_extract."New value: +"The run_id of the bulk job."
- Changed
start_bulk_extract1 field changed- changed
Input schema / properties / start_at / descriptionPrevious value: -"1-based position to start from, newest first (default 1). For sources over 1,000 videos run blocks: start_at=1, then 1001, 2001…; get_bulk_status gives next_start_at when a block was full."New value: +"1-based position to start from, newest first (default 1). For sources over 1,000 videos run blocks: start_at=1, then 1001, 2001…; the job status gives next_start_at when a block was full."
1 tool update
- Changed
start_bulk_extract2 fields changed- added
Input schema / properties / contentAdded value: +{ + "description": "For channels: which tab to read. Default 'videos' (long-form uploads); 'shorts' or 'live' for those tabs.", + "enum": [ + "videos", + "shorts", + "live" + ], + "type": "string" +} - added
Input schema / properties / start_atAdded value: +{ + "description": "1-based position to start from, newest first (default 1). For sources over 1,000 videos run blocks: start_at=1, then 1001, 2001…; get_bulk_status gives next_start_at when a block was full.", + "minimum": 1, + "type": "integer" +}
1 tool update
- Changed
get_transcript1 field changed- changed
Input schema / properties / video / descriptionPrevious value: -"YouTube video URL or 11-character video id (TikTok video URLs also work)."New value: +"YouTube video URL or 11-character video id."
10 tool updates
- Changed
get_bulk_status1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "billing": { + "properties": { + "creditsCharged": { + "description": "Credits this call cost (0 on cache hits).", + "type": "integer" + }, + "enabled": { + "type": "boolean" + }, + "freeLimit": { + "type": "integer" + }, + "granted": { + "type": "integer" + }, + "kind": { + "description": "anon (free tier), license (paid) or admin.", + "type": "string" + }, + "remaining": { + "description": "Credits left on this account.", + "type": [ + "integer", + "null" + ] + }, + "unlimited": { + "type": "boolean" + }, + "used": { + "type": "integer" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + "cached": { + "type": "integer" + }, + "check_again_in_seconds": { + "description": "Do not poll sooner than this.", + "type": "integer" + }, + "completed": { + "type": "integer" + }, + "error": { + "type": [ + "string", + "null" + ] + }, + "failed": { + "type": "integer" + }, + "interrupted": { + "type": "integer" + }, + "phase": { + "type": "string" + }, + "quota": { + "description": "Videos not attempted because credits ran out.", + "type": "integer" + }, + "remaining": { + "type": "integer" + }, + "run_id": { + "type": "string" + }, + "skipped": { + "description": "Videos without captions; never charged.", + "type": "integer" + }, + "source": { + "properties": { + "title": { + "type": [ + "string", + "null" + ] + }, + "type": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": "string" + } + }, + "required": [ + "url" + ], + "type": "object" + }, + "status": { + "description": "running, completed or stopped.", + "type": "string" + }, + "stopped": { + "properties": { + "code": { + "type": "string" + }, + "message": { + "type": "string" + }, + "not_attempted": { + "type": "integer" + } + }, + "required": [ + "code" + ], + "type": "object" + }, + "total": { + "type": "integer" + }, + "videos_found": { + "description": "Null until a large channel has been listed.", + "type": [ + "integer", + "null" + ] + } + }, + "required": [ + "run_id", + "status", + "source", + "check_again_in_seconds", + "billing" + ], + "type": "object" +}
- Changed
get_channel_videos1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "billing": { + "properties": { + "creditsCharged": { + "description": "Credits this call cost (0 on cache hits).", + "type": "integer" + }, + "enabled": { + "type": "boolean" + }, + "freeLimit": { + "type": "integer" + }, + "granted": { + "type": "integer" + }, + "kind": { + "description": "anon (free tier), license (paid) or admin.", + "type": "string" + }, + "remaining": { + "description": "Credits left on this account.", + "type": [ + "integer", + "null" + ] + }, + "unlimited": { + "type": "boolean" + }, + "used": { + "type": "integer" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + "channel": { + "type": "string" + }, + "count": { + "type": "integer" + }, + "has_more": { + "description": "True when the listing stopped at `limit`.", + "type": "boolean" + }, + "results": { + "items": { + "properties": { + "channel": { + "type": [ + "string", + "null" + ] + }, + "channel_url": { + "type": [ + "string", + "null" + ] + }, + "duration": { + "type": [ + "number", + "null" + ] + }, + "id": { + "type": [ + "string", + "null" + ] + }, + "published": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "type": { + "enum": [ + "video", + "channel", + "playlist" + ], + "type": "string" + }, + "url": { + "type": [ + "string", + "null" + ] + }, + "view_count": { + "type": [ + "integer", + "null" + ] + } + }, + "required": [ + "id", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "title": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "channel", + "results", + "count", + "billing" + ], + "type": "object" +}
- Changed
get_latest_videos1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "billing_note": { + "type": "string" + }, + "channel": { + "type": [ + "string", + "null" + ] + }, + "channel_id": { + "type": [ + "string", + "null" + ] + }, + "count": { + "type": "integer" + }, + "results": { + "items": { + "properties": { + "channel": { + "type": [ + "string", + "null" + ] + }, + "channel_url": { + "type": [ + "string", + "null" + ] + }, + "duration": { + "type": [ + "number", + "null" + ] + }, + "id": { + "type": [ + "string", + "null" + ] + }, + "published": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "type": { + "enum": [ + "video", + "channel", + "playlist" + ], + "type": "string" + }, + "url": { + "type": [ + "string", + "null" + ] + }, + "view_count": { + "type": [ + "integer", + "null" + ] + } + }, + "required": [ + "id", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "source": { + "description": "feed, or listing when the RSS feed was unavailable (then `published` may be null).", + "type": "string" + } + }, + "required": [ + "results", + "count" + ], + "type": "object" +}
- Changed
get_playlist_videos1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "billing": { + "properties": { + "creditsCharged": { + "description": "Credits this call cost (0 on cache hits).", + "type": "integer" + }, + "enabled": { + "type": "boolean" + }, + "freeLimit": { + "type": "integer" + }, + "granted": { + "type": "integer" + }, + "kind": { + "description": "anon (free tier), license (paid) or admin.", + "type": "string" + }, + "remaining": { + "description": "Credits left on this account.", + "type": [ + "integer", + "null" + ] + }, + "unlimited": { + "type": "boolean" + }, + "used": { + "type": "integer" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + "count": { + "type": "integer" + }, + "has_more": { + "description": "True when the listing stopped at `limit`.", + "type": "boolean" + }, + "playlist": { + "type": "string" + }, + "results": { + "items": { + "properties": { + "channel": { + "type": [ + "string", + "null" + ] + }, + "channel_url": { + "type": [ + "string", + "null" + ] + }, + "duration": { + "type": [ + "number", + "null" + ] + }, + "id": { + "type": [ + "string", + "null" + ] + }, + "published": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "type": { + "enum": [ + "video", + "channel", + "playlist" + ], + "type": "string" + }, + "url": { + "type": [ + "string", + "null" + ] + }, + "view_count": { + "type": [ + "integer", + "null" + ] + } + }, + "required": [ + "id", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "title": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "playlist", + "results", + "count", + "billing" + ], + "type": "object" +}
- Changed
get_transcript1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "billing": { + "properties": { + "creditsCharged": { + "description": "Credits this call cost (0 on cache hits).", + "type": "integer" + }, + "enabled": { + "type": "boolean" + }, + "freeLimit": { + "type": "integer" + }, + "granted": { + "type": "integer" + }, + "kind": { + "description": "anon (free tier), license (paid) or admin.", + "type": "string" + }, + "remaining": { + "description": "Credits left on this account.", + "type": [ + "integer", + "null" + ] + }, + "unlimited": { + "type": "boolean" + }, + "used": { + "type": "integer" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + "cached": { + "description": "True when served from this account's library (free).", + "type": "boolean" + }, + "channel": { + "type": "string" + }, + "duration": { + "type": [ + "number", + "null" + ] + }, + "duration_text": { + "type": [ + "string", + "null" + ] + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "paragraphs": { + "description": "Silence-grouped paragraphs; best for reading and chunking.", + "items": { + "type": "string" + }, + "type": "array" + }, + "segments": { + "description": "Only when include_segments is true.", + "items": { + "properties": { + "duration": { + "type": "number" + }, + "start": { + "type": "number" + }, + "text": { + "type": "string" + } + }, + "required": [ + "text", + "start" + ], + "type": "object" + }, + "type": "array" + }, + "source": { + "description": "manual_caption or auto_caption.", + "type": [ + "string", + "null" + ] + }, + "text": { + "type": "string" + }, + "title": { + "type": "string" + }, + "upload_date": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": "string" + }, + "video_id": { + "type": "string" + }, + "word_count": { + "type": "integer" + } + }, + "required": [ + "video_id", + "url", + "title", + "channel", + "text", + "paragraphs", + "billing" + ], + "type": "object" +}
- Changed
get_transcripts1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "billing": { + "properties": { + "creditsCharged": { + "description": "Credits this call cost (0 on cache hits).", + "type": "integer" + }, + "enabled": { + "type": "boolean" + }, + "freeLimit": { + "type": "integer" + }, + "granted": { + "type": "integer" + }, + "kind": { + "description": "anon (free tier), license (paid) or admin.", + "type": "string" + }, + "remaining": { + "description": "Credits left on this account.", + "type": [ + "integer", + "null" + ] + }, + "unlimited": { + "type": "boolean" + }, + "used": { + "type": "integer" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + "failed": { + "items": { + "properties": { + "error": { + "properties": { + "code": { + "type": "string" + }, + "message": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "video": { + "type": "string" + } + }, + "required": [ + "video", + "error" + ], + "type": "object" + }, + "type": "array" + }, + "partial": { + "description": "Present and true when credits ran out mid-batch.", + "type": "boolean" + }, + "requested": { + "type": "integer" + }, + "stopped": { + "properties": { + "code": { + "type": "string" + }, + "message": { + "type": "string" + }, + "not_attempted": { + "type": "integer" + } + }, + "required": [ + "code" + ], + "type": "object" + }, + "succeeded": { + "type": "integer" + }, + "transcripts": { + "items": { + "properties": { + "billing": { + "properties": { + "creditsCharged": { + "description": "Credits this call cost (0 on cache hits).", + "type": "integer" + }, + "enabled": { + "type": "boolean" + }, + "freeLimit": { + "type": "integer" + }, + "granted": { + "type": "integer" + }, + "kind": { + "description": "anon (free tier), license (paid) or admin.", + "type": "string" + }, + "remaining": { + "description": "Credits left on this account.", + "type": [ + "integer", + "null" + ] + }, + "unlimited": { + "type": "boolean" + }, + "used": { + "type": "integer" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + "cached": { + "description": "True when served from this account's library (free).", + "type": "boolean" + }, + "channel": { + "type": "string" + }, + "duration": { + "type": [ + "number", + "null" + ] + }, + "duration_text": { + "type": [ + "string", + "null" + ] + }, + "language": { + "type": [ + "string", + "null" + ] + }, + "paragraphs": { + "description": "Silence-grouped paragraphs; best for reading and chunking.", + "items": { + "type": "string" + }, + "type": "array" + }, + "segments": { + "description": "Only when include_segments is true.", + "items": { + "properties": { + "duration": { + "type": "number" + }, + "start": { + "type": "number" + }, + "text": { + "type": "string" + } + }, + "required": [ + "text", + "start" + ], + "type": "object" + }, + "type": "array" + }, + "source": { + "description": "manual_caption or auto_caption.", + "type": [ + "string", + "null" + ] + }, + "text": { + "type": "string" + }, + "title": { + "type": "string" + }, + "upload_date": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": "string" + }, + "video_id": { + "type": "string" + }, + "word_count": { + "type": "integer" + } + }, + "required": [ + "video_id", + "url", + "title", + "channel", + "text", + "paragraphs" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "requested", + "succeeded", + "failed", + "transcripts", + "billing" + ], + "type": "object" +}
- Changed
list_bulk_results1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "items": { + "items": { + "properties": { + "channel": { + "type": [ + "string", + "null" + ] + }, + "duration": { + "type": [ + "number", + "null" + ] + }, + "error": { + "properties": { + "code": { + "type": "string" + }, + "message": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "position": { + "type": "integer" + }, + "status": { + "description": "ok, cached, error, skipped or quota.", + "type": "string" + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + }, + "video_id": { + "type": [ + "string", + "null" + ] + }, + "word_count": { + "type": [ + "integer", + "null" + ] + } + }, + "required": [ + "position", + "status" + ], + "type": "object" + }, + "type": "array" + }, + "next_cursor": { + "description": "Pass back as `cursor` for the next page; null on the last page.", + "type": [ + "integer", + "null" + ] + }, + "note": { + "type": "string" + }, + "run_id": { + "type": "string" + }, + "status": { + "type": "string" + }, + "total": { + "type": "integer" + } + }, + "required": [ + "run_id", + "status", + "items", + "next_cursor" + ], + "type": "object" +}
- Changed
search_channel1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "billing": { + "properties": { + "creditsCharged": { + "description": "Credits this call cost (0 on cache hits).", + "type": "integer" + }, + "enabled": { + "type": "boolean" + }, + "freeLimit": { + "type": "integer" + }, + "granted": { + "type": "integer" + }, + "kind": { + "description": "anon (free tier), license (paid) or admin.", + "type": "string" + }, + "remaining": { + "description": "Credits left on this account.", + "type": [ + "integer", + "null" + ] + }, + "unlimited": { + "type": "boolean" + }, + "used": { + "type": "integer" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + "channel": { + "type": "string" + }, + "channel_title": { + "type": [ + "string", + "null" + ] + }, + "count": { + "type": "integer" + }, + "query": { + "type": "string" + }, + "results": { + "items": { + "properties": { + "channel": { + "type": [ + "string", + "null" + ] + }, + "channel_url": { + "type": [ + "string", + "null" + ] + }, + "duration": { + "type": [ + "number", + "null" + ] + }, + "id": { + "type": [ + "string", + "null" + ] + }, + "published": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "type": { + "enum": [ + "video", + "channel", + "playlist" + ], + "type": "string" + }, + "url": { + "type": [ + "string", + "null" + ] + }, + "view_count": { + "type": [ + "integer", + "null" + ] + } + }, + "required": [ + "id", + "url" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "channel", + "query", + "results", + "count", + "billing" + ], + "type": "object" +}
- Changed
search_youtube1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "billing": { + "properties": { + "creditsCharged": { + "description": "Credits this call cost (0 on cache hits).", + "type": "integer" + }, + "enabled": { + "type": "boolean" + }, + "freeLimit": { + "type": "integer" + }, + "granted": { + "type": "integer" + }, + "kind": { + "description": "anon (free tier), license (paid) or admin.", + "type": "string" + }, + "remaining": { + "description": "Credits left on this account.", + "type": [ + "integer", + "null" + ] + }, + "unlimited": { + "type": "boolean" + }, + "used": { + "type": "integer" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + "count": { + "type": "integer" + }, + "query": { + "type": "string" + }, + "results": { + "items": { + "properties": { + "channel": { + "type": [ + "string", + "null" + ] + }, + "channel_url": { + "type": [ + "string", + "null" + ] + }, + "duration": { + "type": [ + "number", + "null" + ] + }, + "id": { + "type": [ + "string", + "null" + ] + }, + "published": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "type": { + "enum": [ + "video", + "channel", + "playlist" + ], + "type": "string" + }, + "url": { + "type": [ + "string", + "null" + ] + }, + "view_count": { + "type": [ + "integer", + "null" + ] + } + }, + "required": [ + "id", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "type": { + "enum": [ + "video", + "channel", + "playlist" + ], + "type": "string" + } + }, + "required": [ + "query", + "type", + "results", + "count", + "billing" + ], + "type": "object" +}
- Changed
start_bulk_extract1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "billing": { + "properties": { + "creditsCharged": { + "description": "Credits this call cost (0 on cache hits).", + "type": "integer" + }, + "enabled": { + "type": "boolean" + }, + "freeLimit": { + "type": "integer" + }, + "granted": { + "type": "integer" + }, + "kind": { + "description": "anon (free tier), license (paid) or admin.", + "type": "string" + }, + "remaining": { + "description": "Credits left on this account.", + "type": [ + "integer", + "null" + ] + }, + "unlimited": { + "type": "boolean" + }, + "used": { + "type": "integer" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + "cached": { + "type": "integer" + }, + "check_again_in_seconds": { + "description": "Do not poll sooner than this.", + "type": "integer" + }, + "completed": { + "type": "integer" + }, + "error": { + "type": [ + "string", + "null" + ] + }, + "failed": { + "type": "integer" + }, + "interrupted": { + "type": "integer" + }, + "phase": { + "type": "string" + }, + "quota": { + "description": "Videos not attempted because credits ran out.", + "type": "integer" + }, + "remaining": { + "type": "integer" + }, + "run_id": { + "type": "string" + }, + "skipped": { + "description": "Videos without captions; never charged.", + "type": "integer" + }, + "source": { + "properties": { + "title": { + "type": [ + "string", + "null" + ] + }, + "type": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": "string" + } + }, + "required": [ + "url" + ], + "type": "object" + }, + "status": { + "description": "running, completed or stopped.", + "type": "string" + }, + "stopped": { + "properties": { + "code": { + "type": "string" + }, + "message": { + "type": "string" + }, + "not_attempted": { + "type": "integer" + } + }, + "required": [ + "code" + ], + "type": "object" + }, + "total": { + "type": "integer" + }, + "videos_found": { + "description": "Null until a large channel has been listed.", + "type": [ + "integer", + "null" + ] + } + }, + "required": [ + "run_id", + "status", + "source", + "check_again_in_seconds", + "billing" + ], + "type": "object" +}
3 tool updates
- Added
get_bulk_status - Added
list_bulk_results - Added
start_bulk_extract
7 tool updates
- First observed
get_channel_videos - First observed
get_latest_videos - First observed
get_playlist_videos - First observed
get_transcript - First observed
get_transcripts - First observed
search_channel - First observed
search_youtube
Related MCP Connectors
YouTube data for AI agents: channels, videos, transcripts, comments, search. Video research.
YouTube transcripts, search, and channel and playlist listings for any AI app. Hosted.
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
YouTube transcripts, search, channels, playlists and bulk transcript jobs for AI agents. 14 tools.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides AI agents with token-optimized access to YouTube data, including video details, transcripts, channel statistics, trending videos, and search.498 npmMIT
- AlicenseAqualityCmaintenanceConnect AI assistants to YouTube: search, transcripts, metadata, and more.1920 npm6MIT

fetchworks-mcpofficial
AlicenseAqualityBmaintenanceEnables AI agents to retrieve YouTube transcripts from individual videos, channels, and search results, supporting multiple output formats such as plain text, SRT, and VTT.316 npmMIT- AlicenseNot gradedqualityAmaintenanceEnables AI clients to pull full transcripts from YouTube videos, search videos and channels, browse a channel's complete upload history, search within a single channel, and extract every video in a playlist through one hosted remote endpoint. It supports API-key or OAuth 2.1 sign-in with no local installation, returning metadata and paginated results with stable error codes.27MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.