YouTube MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action. Search tools are clearly differentiated by scope (global, channel, transcript), and the two transcript variants are separated by their purpose: raw captions versus cleaned/summarizable text.
Naming Consistency5/5
All tool names follow a consistent lowercase snake_case verb-first pattern, using clear verbs like get, search, calculate, parse, and extract. The naming is uniform and predictable across the entire set.
Tool Count5/5
15 tools is at the upper end of the ideal range but every tool contributes a meaningful YouTube workflow: search, metadata, transcripts, comments, channels, playlists, and engagement. The count feels deliberate and well-scoped rather than padded.
Completeness4/5
The set covers video discovery, metadata, transcript analysis, comments, and channel/playlist retrieval thoroughly. Minor gaps exist, such as no dedicated way to list a channel's playlists or fetch comment replies, but these are workaroundable and do not undermine the core read-only YouTube workflow.
Average 3.7/5 across 15 of 15 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it mostly restates the tool's purpose and the filters already present in the schema. It does not mention output shape, rate limits, authentication needs, or any side effects, so significant behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact, front-loaded sentence that states the verb, resource, and key filter dimensions with no filler. It is appropriately sized for a tool whose parameter details live in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is rich enough for calling the tool, but there is no output schema and the description gives no hint of what a successful search returns. It also undersells the schema by saying 'videos' while the type parameter supports channels and playlists, so additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter already has a clear description with defaults and duration thresholds. The tool description only lists filter categories that are already in the schema and adds no new semantic detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb (Search), resource (YouTube videos), and a distinctive filter set (upload date, duration, sort order, content type). It is clearly broader than search_within_channel or search_transcript, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling search tools like search_within_channel or search_transcript. An agent must infer from tool names that this is the general YouTube search, and no exclusions or alternative routing are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It mentions the returned fields but overstates the result set as 'all videos' while the schema caps requests at 50 with a default of 25, and it says nothing about pagination, auth, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the core action in the first and return details in the second. No filler, and a reasonable amount of information is packed into a compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does explain the main return values: playlist info and video titles, channels, and positions. However, it leaves out the bounded result behavior from max_results and any pagination or limit caveats, so an agent may misjudge the actual response size.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 url and max_results. The description adds no parameter-specific meaning such as accepted URL formats or the meaning of max_results, but it also does not need to compensate heavily because the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get videos) and resource (YouTube playlist), and it is inherently distinct from siblings like get_channel_videos or search_videos. However, claiming 'all videos' is somewhat misleading given the max_results parameter defaults to 25, so the stated scope is not fully accurate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving videos from a specific playlist, which gives the agent basic context. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, if it has quota or rate-limit implications, or what the result shape is. Only the verb 'Search' hints at non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with no filler, and the core scoping ('within a specific YouTube channel') is front-loaded. It sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should at least indicate what is returned and any behavioral constraints. It does neither, leaving the agent to infer output format and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: url, query, and max_results are each described. The description adds no parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search') and resource ('videos within a specific YouTube channel'). It clearly distinguishes from siblings like search_videos (global search) and get_channel_videos (no query).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when a search is scoped to a specific channel. However, it gives no explicit when-to-use/when-not-to-use guidance and names no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what metadata will be returned but does not state whether the operation is read-only, whether authentication is needed, how errors are handled, or any rate-limiting or data-freshness considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One focused sentence that front-loads the primary action and resource, then efficiently enumerates the metadata categories. Every phrase contributes value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-documented parameter and no output schema. The description compensates by listing expected return fields. It lacks behavioral caveats and usage guidance, but for a straightforward metadata retrieval tool it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'url' is already documented as 'YouTube video URL or video ID'. The description does not add further parameter-level detail, but with full schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get') with a clear resource ('detailed metadata for a YouTube video') and enumerates concrete fields (title, description, channel, duration, counts, tags, category, thumbnails). This clearly distinguishes it from sibling tools that fetch comments, transcripts, or trending videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, and no mention of exclusions or prerequisites. While the purpose implies use when video metadata is needed, it does not explicitly differentiate from related tools like get_channel_info or search_videos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It explains that the tool calculates rates from view count, but it does not define the formulas, disclose any rate limits or dependencies, mention what happens with missing/invalid data, or explicitly state whether this is a read-only computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the action ('Calculate') and then specifying the resource and outputs. Every phrase adds relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with full schema coverage, the description provides enough surface-level context to invoke it, but without an output schema it does not fully specify the return structure or how rates are defined. A complete definition would clarify the exact output shape and any edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter url as 'YouTube video URL or video ID', providing 100% coverage. The description adds no further parameter-level detail, so it stays at the baseline for well-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, resource, and output: 'Calculate engagement metrics for a YouTube video' and enumerates the exact metrics (like rate, comment rate, overall engagement rate). This clearly distinguishes it from sibling tools like get_video_metadata or get_video_comments, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a caller needs engagement rates, and the metrics list gives contextual clues. However, it does not explicitly state when this tool should be preferred over sibling tools, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full disclosure burden. It states the filtering behavior but says nothing about result format, pagination, sorting, rate limits, or safety. The verb 'get' implies read-only, but the description does not make any behavioral guarantees beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that delivers the action, resource, and the two key dimensions with zero filler. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 optional parameters, and the schema documents each parameter fully. But with no output schema and no annotations, the description does not explain what video data will be returned or how results are ordered, nor does it give usage context relative to siblings. It is minimally adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter has a helpful description including examples and defaults. The tool description only paraphrases 'region' and 'category' without adding new meaning, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get', names the resource 'trending/popular YouTube videos', and specifies the two filters 'by region and category'. This clearly distinguishes it from siblings like search_videos or get_channel_videos, which concern different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call it when you need currently trending videos filtered by region/category. However, it never explicitly mentions when not to use it or points to an alternative sibling tool, leaving the boundary with search_videos inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It conveys a read-style retrieval operation and mentions sorting by date or view count, but it does not explain return format, whether 'recent' maps to upload date, or how viewCount ordering behaves. Some behavioral context is present, but important gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler, and the primary action is front-loaded. The sorting behavior is stated secondarily and the text is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description and schema are adequate for basic invocation, but the absence of an output schema and the lack of explicit differentiation from similar video-listing tools leave gaps. An agent selecting among many channel- and video-related siblings would benefit from a note about what is returned or when to use this tool instead of others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters, including the url format, enum values, defaults, and bounds. The description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the operation ('Get recent videos') and the resource ('YouTube channel'), and mentions the sorting capabilities. This makes it easy to distinguish from get_trending_videos, which is not channel-scoped, and from search_within_channel, which is search-oriented rather than a recent-videos listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The channel-scoped phrasing implies when this tool is appropriate, but there is no explicit guidance about when to prefer it over siblings like get_trending_videos or search_within_channel. No exclusions, alternatives, or use-case conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the source ('description') and the return shape (chapter list with titles and start times), which is useful. However, it does not disclose behaviors around missing chapters, parsing failures, or rate limiting. There is no contradiction with any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that states the action, source, and output with no filler. Key information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool, the description gives the essential input and output information. It states that results come from the video description and returns chapter titles with start times. It could be more explicit about edge cases like missing chapters, but overall it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as the only parameter 'url' is documented with 'YouTube video URL or video ID'. The description does not add additional semantic detail beyond the schema, which is acceptable given complete schema coverage. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Extract'), identifies the exact resource ('chapter timestamps from a YouTube video's description'), and states the output ('structured chapter list with titles and start times'). This clearly distinguishes it from sibling tools like get_transcript or get_video_metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when chapter timestamps are needed from a video's description. However, it does not explicitly state exclusions or alternatives, such as using get_video_metadata or get_transcript for other types of video information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does state that the tool returns matching segments with timestamps and surrounding context, which is useful. However, it does not mention behavior on no matches, case sensitivity, language handling quirks, or any potential errors or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The action is front-loaded and the output detail is concise yet informative. Every word contributes to understanding what the tool does and what it returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter search tool with no output schema, the description gives sufficient return-value information. It lacks explicit edge-case behavior and alternative routing, but those are partially covered by other dimensions. An agent can reasonably understand how to invoke it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters. The description's phrase 'keyword or phrase' adds no new semantic detail beyond what the query parameter description already says. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('search') and resource ('a YouTube video's transcript'), and clarifies the output ('matching segments with timestamps and surrounding context'). This clearly differentiates it from sibling tools like get_transcript, which returns the full transcript, and search_videos, which searches across videos rather than within a single transcript.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description, but there is no explicit guidance on when to choose this tool over alternatives such as get_transcript, get_clean_transcript, or search_within_channel. No exclusions or 'when not to use' conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only operation ('Get') and specifies accepted input formats, but it doesn't disclose any error behavior, auth requirements, or edge cases. For a simple getter this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that announces the action, lists expected result fields, and clarifies accepted input variations. No filler or redundant clauses; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers both input formats and expected return fields. It doesn't describe error cases or optional behavior, but these are minor gaps given the tool's simplicity and the details provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema's parameter description is nearly identical to the tool description ('YouTube channel URL, @handle, or channel ID'). The description adds no meaningful semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('YouTube channel information') and enumerates the exact fields returned (title, description, counts, country, thumbnail). This makes it easy to distinguish from sibling tools like get_channel_videos or search_within_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose obvious: fetching channel-level metadata. It doesn't explicitly name alternatives or say when not to use it, but the context is clear enough to route an agent to this tool when channel info is needed rather than videos or comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses the cleaning behavior and the data source (SponsorBlock), but it does not mention limitations such as reliance on community-submitted segments, possible unavailability of cleaned segments, or behavior when captions are missing. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the core functionality and transformation, the second gives the intended use case. All content is relevant and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for an agent to call the tool correctly: it names the target resource and the optional language is fully documented in the schema. The main gap is not explicitly contrasting with get_transcript or describing return behavior, but this is a fairly simple tool with no output schema, so the level of completeness is above minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning about the url or lang parameters beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch'), a clear resource ('YouTube video transcript'), and enumerates exactly what is removed (sponsor reads, intros, outros, self-promotion, filler). This differentiates it from siblings like get_transcript or search_transcript, even though no sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Ideal for summarization' gives clear intended use context. However, it does not explicitly state when to use this instead of the likely raw-transcript sibling get_transcript, nor does it mention situations where this tool would be inappropriate, such as when SponsorBlock data is unavailable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it does disclose key behavior: it is a read-only fetch ('Fetch'), requires no API key, and returns both segmented and concatenated text. It does not cover edge cases like missing captions or rate limiting, but for a simple public fetch the essential behavioral traits are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first front-loads the core purpose and the second explains the return format. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, 2-parameter read tool without an output schema, the description is nearly complete: purpose, return shape, and auth model are all stated. The main missing context is explicit guidance on how it differs from close siblings such as get_clean_transcript, which is more a usage-guideline gap than a correctness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters ('YouTube video URL or video ID' and 'Language code for captions (default: "en")'). The description adds no extra parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('Fetch the full transcript/captions'), a concrete target ('YouTube video with timestamps'), and the exact output shape ('individual segments with timing and the full concatenated text'). This clearly distinguishes it from neighboring search_transcript and get_clean_transcript by signaling whole-transcript, timestamped content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies this is for retrieving an entire transcript rather than searching within one or getting a cleaned version, but it never explicitly states when to choose this tool over siblings like search_transcript or get_clean_transcript. There are no when-to-use or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully states that only top-level comments are returned and lists the output fields. However, it omits pagination behavior, potential rate limits, and how missing or disabled comments are handled, which are relevant for an agent planning repeated calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The primary action and resource are front-loaded, and the second sentence efficiently summarizes the return payload.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description is largely complete: it names the resource, the result fields, and the top-level scope. It would benefit from a mention of pagination or reply behavior, but the schema covers parameter constraints and the tool is straightforward enough that the missing items are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the input schema already has 100% description coverage for all three parameters, the baseline is 3. The tool description adds general context about returning top-level comments and fields, but it does not add new meaning to specific parameters such as 'order' or 'max_results' beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Fetch' and a clear resource: top-level comments from a YouTube video. It also enumerates the returned fields, making the tool's function immediately obvious and distinct from sibling tools that handle metadata, transcripts, or trending searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need top-level comments on a video. It does not explicitly exclude alternatives or give when-not-to-use guidance, but the scope is specific enough that an agent can infer appropriate usage without confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It transparently states the return components and the view-count requirement, which are useful behavioral constraints. It does not mention error behavior or rate limits, but for a read-only retrieval tool the description is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the action and output, then adds the operational constraint, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description conveys the key return elements and a critical prerequisite. It could specify the exact format of intensity scores or peak timestamps, but for a single-parameter data-retrieval tool this is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, url, is already fully described in the input schema as 'YouTube video URL or video ID'. The description adds no extra parameter-level detail, so the high schema coverage sets the baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieving the 'most replayed' heatmap data for a YouTube video. It also names the output components (intensity scores, top peaks, timestamps), which distinguishes it from sibling tools about comments, transcripts, metadata, or videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly scopes the tool to one video's heatmap data and includes a hard prerequisite ('Requires 50K+ views'). It does not explicitly name sibling alternatives or exclusion conditions, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It openly states what data is extracted and which URL shapes are supported. It does not mention invalid-input behavior or return shape, but as a side-effect-free parser, the disclosed scope is largely sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the action and extracted fields, the second lists supported input formats. Everything included earns its place; there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter parser with no output schema, the description covers the input requirements and the categories of output data. It could be more precise about the exact return object shape or behavior on invalid URLs, but an agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter described as 'Any YouTube URL or video ID', so the baseline is 3. The description goes further by listing concrete supported formats (watch, youtu.be, /shorts/, /embed/, /playlist, /channel/, /@handle, bare video IDs), which adds practical meaning beyond the schema value alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Parse') and a clear resource ('any YouTube URL format') followed by the exact extraction targets: video ID, channel ID, playlist ID, handle, and timestamp. It also enumerates supported format patterns, which unambiguously separates this parsing utility from all sibling tools that search or analyze video content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes its context clear: call this when you need to resolve any YouTube URL or bare ID into structured identifiers and a timestamp. It does not explicitly state when *not* to use it, but none of the sibling tools perform URL parsing, so the omission of alternatives is not a meaningful gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Youtube_mcp MCP server](https://glama.ai/mcp/servers/xnomi05-blip/Youtube_mcp/badges/card.svg)](https://glama.ai/mcp/servers/xnomi05-blip/Youtube_mcp)

Score Badge

Copy to your README.md:

[![Youtube_mcp MCP server](https://glama.ai/mcp/servers/xnomi05-blip/Youtube_mcp/badges/score.svg)](https://glama.ai/mcp/servers/xnomi05-blip/Youtube_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xnomi05-blip/Youtube_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server