YouTube MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Transcript-related tools (get_transcript, get_clean_transcript, search_transcript) have similar names and overlapping use cases, and search_videos/search_within_channel/get_channel_videos can be confused. However, their descriptions clarify the differences in most cases.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern like get_video_metadata, search_videos, and calculate_engagement. Minor deviations such as extract_chapters, parse_youtube_url, and search_within_channel break the pattern slightly but don't cause real confusion.
Tool Count4/5
15 tools is at the upper edge of a reasonable scope for a YouTube server. Each tool covers a distinct data access need, though a few overlap in function, making the set feel slightly heavier than necessary.
Completeness4/5
The server provides strong read-oriented coverage across videos, channels, playlists, transcripts, comments, and trends. Missing write operations like creating playlists or uploading videos are likely out of scope, so there are only minor gaps.
Average 3.7/5 across 15 of 15 tools scored.
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 is passing
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 provided, the description carries the full burden of behavioral disclosure. It does not state that this is a read-only operation, describe result shape or pagination, or mention any rate limits. It also loosely says 'videos' while the schema's type parameter permits channels and playlists, making the actual scope slightly misleading.
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, front-loaded sentence that names the main action and the key filter dimensions without wasted words. It is appropriately sized for a search tool.
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 schema is rich enough to carry parameter meaning, and the tool's expected search-result behavior is fairly intuitive. However, with no output schema and no annotations, a bit more context about result format, default behavior, or when not to use this tool would make it fully complete.
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 covers 100% of parameters, each with meaningful descriptions and enums, so the description need not repeat parameter details. The phrase 'upload date, duration, sort order, and content type' adds mild orientation but no semantics beyond what the schema already provides.
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 tool searches YouTube with a specific set of filters. It names the resource and the capabilities, but it does not distinguish itself from siblings like search_transcript or search_within_channel, and it says 'videos' while the schema allows channel and playlist types.
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 alternatives such as search_transcript, search_within_channel, or get_trending_videos. The description implies general YouTube search, but it does not state exclusions, prerequisites, or the conditions that would make a sibling tool more appropriate.
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 discloses nothing about authentication requirements, rate limits, pagination, result ordering, or whether the search covers titles, descriptions, or both. The description is a bare action statement with no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single nine-word sentence with zero wasted words and a front-loaded subject-verb-object structure. It is efficient, though the brevity comes at the cost of omitting behavioral and usage context.
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 and its parameters are fully documented in the schema, making the description minimally adequate. However, with no output schema and no annotations, the return format, result count behavior, and scope of what gets searched are all left undisclosed.
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%, with url, query, and max_results all documented in the input schema. The description adds no parameter-level meaning 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.
Purpose4/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: 'Search for videos within a specific YouTube channel.' The channel-scoping phrase is the key differentiator from the sibling search_videos, though it does not explicitly name or contrast that alternative.
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?
Usage context is only implied through the phrase 'within a specific YouTube channel,' which suggests this is for channel-scoped searches rather than global ones. There is no explicit guidance about when to choose this over search_videos, search_transcript, or other sibling tools.
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, the description carries the full burden; it usefully discloses that no API key is needed and that both timed segments and concatenated text are returned. It does not, however, cover failure modes (no captions available, unsupported language) or rate-limiting 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 sentences, with the key promise front-loaded and each clause adding new information (timestamps, dual return format, no auth). No 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?
For a simple 2-parameter read-only tool with complete schema coverage, the description covers the main return shape and the auth requirement. It falls slightly short only on error handling and usage context, which are not critical for invoking the tool correctly.
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?
Both parameters are already fully described in the schema, including the default for lang. The tool description adds no additional semantic detail, so it sits at the baseline for high schema coverage.
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?
States a clear verb ('Fetch') and resource ('full transcript/captions of a YouTube video'), and specifies the return payload (segments with timing plus concatenated text). It does not name a sibling, but the phrase 'with timestamps' hints at distinction from get_clean_transcript.
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?
Provides no explicit when-to-use or alternative guidance. The sibling set includes get_clean_transcript, but the description never tells an agent when to choose this over it, nor mentions fallbacks or preconditions.
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 behavioral burden. It clearly indicates a read-only lookup and lists accepted input formats, which is useful. However, it does not disclose error behavior, rate-limit or auth implications, or the exact shape/structure of the returned channel object.
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, front-loaded sentence that states the action, the key returned fields, and the accepted input forms. There is no filler or redundant restatement of the tool name.
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 this is nearly sufficient, but with no output schema and no annotations, the description should provide more context about the return format and possible failure modes. It lists fields but not how they are structured or what happens on invalid input.
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 'url' parameter is already described as 'YouTube channel URL, @handle, or channel ID'. The description repeats this exactly rather than adding new semantic detail, so it earns the baseline score for high schema coverage.
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?
Uses a specific verb ('Get') and resource ('YouTube channel information'), then enumerates the concrete fields returned: title, description, counts, country, and thumbnail. The accepted identifier formats (URL, @handle, ID) further clarify scope and distinguish it from transcript/comment/playlist sibling tools.
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 explicit guidance on when to use this tool versus alternatives like get_channel_videos or get_video_metadata, and no exclusion criteria. The use case is implied by the name and field list, but the description never states when an agent should pick this over another tool.
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. It discloses the core behavior (reading the video description and returning chapters) and the return shape, but it does not describe edge cases such as missing chapters, malformed timestamps, or whether any errors can occur.
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, efficient sentence with no filler. It front-loads the action and resource, then states the output shape. Every component 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 simple one-parameter extraction tool, the description is largely complete: it names the input, the source, and the return value. It lacks only minor context like behavior when the video description contains no chapters, but this is not a critical gap given the low complexity.
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%: the schema already documents the url parameter as 'YouTube video URL or video ID'. The tool description adds no further parameter-level detail, so the baseline score 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 uses a specific verb ('Extract') and resource ('chapter timestamps from a YouTube video's description'), and clarifies the output ('structured chapter list with titles and start times'). This clearly distinguishes it from sibling tools like get_transcript, get_video_metadata, and get_most_replayed, which target different data.
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?
The description implies the tool is for extracting chapter timestamps, but it provides no explicit guidance on when to choose it over related siblings such as get_video_metadata or get_most_replayed. There are no usage conditions, exclusions, or alternative routing cues.
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 behavioral burden. 'Get' implies a read-only operation and 'currently trending/popular' sets time relevance, but it does not disclose output shape, pagination behavior, or any rate-limit considerations. For a simple fetch tool this is acceptable but not richly 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 a single, front-loaded sentence with no filler. It names the action, resource, and scoping dimensions efficiently, and every word contributes to understanding.
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 tool with three optional, fully documented parameters and no output schema, the description is largely sufficient. It defines the purpose and scope, while the schema covers parameter semantics. It could be more complete with explicit usage guidance or expected return format, but those are not critical given the simple read operation.
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 adds minimal semantic value by linking 'region' and 'category' to the conceptual scope, but it does not explain max_results or the interaction between parameters. Baseline 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 clearly states a specific verb ('Get') and resource ('currently trending/popular YouTube videos'), and specifies the scoping dimensions ('by region and category'). It is distinguishable from sibling search and metadata tools via the 'trending/popular' qualifier, though it does not explicitly call out any sibling by name.
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 the agent needs trending or popular videos, and the phrase 'currently trending/popular' hints that this is not a general search tool. However, it provides no explicit guidance on when to prefer this over siblings like search_videos or get_channel_videos, and no exclusions 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?
The verb 'Get' conveys a read-only operation and the sorting behavior is mentioned, but no annotations exist to carry safety or side-effect information. The description does not address output shape, pagination, max_results behavior, authentication, or rate limits, leaving meaningful gaps.
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 concise sentences deliver the core purpose and key behavior with no filler. The description is front-loaded and every clause contributes meaningful 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?
The schema covers parameter semantics and the description gives a clear purpose, but the absence of annotations and output schema leaves return values, pagination, and selection versus sibling tools under-specified. It is adequate for simple invocation but not fully complete.
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 with defaults and constraints. The description only restates the sort-by date or view count option, adding no information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific operation 'Get recent videos from a YouTube channel' and identifies the resource clearly. The sort options further define its scope, making it distinguishable from siblings like get_channel_info (channel metadata) and search_videos (broad video search).
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 tool is for retrieving recent channel-level videos with sorting, but it does not explicitly say when to prefer it over alternatives like search_within_channel or search_videos. No exclusions or when-not-to-use guidance is 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?
With no annotations, the description carries the behavioral disclosure burden. It does reveal the output shape: "Returns playlist info and video list with titles, channels, and positions." However, it does not mention pagination, the max_results default, or the fact that "all videos" may be constrained by max_results.
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 tight sentences with no filler. It front-loads the core action in the first sentence and then efficiently lists the expected return contents in the second.
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 two-parameter tool, the description is largely sufficient: it names the resource, gives the required input by implication, and summarizes the return fields. It could be more complete by noting the max_results limit and default, but the schema already covers those details.
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 documents both parameters with 100% coverage, so the baseline is 3. The description does not add much parameter-specific meaning beyond the schema; it does not clarify how max_results relates to the claim of getting "all videos."
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 and resource: "Get all videos in a YouTube playlist with metadata." It clearly identifies the tool's target as playlist items, which distinguishes it from sibling tools focused on transcripts, channels, trending videos, or 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 intended use case is implied: use this tool when you need videos from a YouTube playlist. However, the description does not state when to prefer this over related siblings like get_channel_videos or search_videos, nor does it give any when-not-to-use guidance.
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 discloses the core behavior—searching a transcript and returning timestamped segments with context—but does not cover edge cases like missing transcripts, language fallback behavior, or case sensitivity. Still, the essential behavior is stated directly.
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 or redundant phrasing. It front-loads the core action and immediately states the output, making it easy for an agent to scan and understand.
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?
Given the simple parameter set and no output schema, the description provides enough context: it names the input focus (transcript search) and the output shape (matching segments with timestamps and context). It lacks explicit usage guidance but remains complete for a straightforward searchtool.
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 adds no extra detail about the parameters, such as URL formats, language code conventions, or query formatting. The baseline of 3 is appropriate because the schema handles the load.
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 states a specific verb ('Search') and resource ('YouTube video's transcript'), and defines the output as matching segments with timestamps and surrounding context. This makes it easy to distinguish from sibling tools like get_transcript, which returns full transcripts rather than search results.
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 tool is for locating keywords or phrases within a transcript, which is a clear use case. However, it does not explicitly mention when to prefer this over get_transcript or search_within_channel, nor does it provide any exclusions or alternative routing.
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, the description carries the behavioral disclosure burden. It states the calculation basis ('based on view count') and the metric types, which is helpful. However, it does not describe the return format, units, possible failure modes for invalid/private videos, or whether it fetches live data.
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 sentence, zero filler, and the essential output information is front-loaded immediately after the verb. The colon-separated metric list is compact and scannable.
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, read-only calculation tool, the description is almost complete: it names the input and the expected outputs. It lacks a precise return structure or unit specification (e.g., decimal vs. percentage), but this is a minor gap given 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%, so the schema already documents the single parameter as 'YouTube video URL or video ID'. The tool description adds conceptual context about view counts but does not meaningfully enrich the parameter semantics beyond the schema.
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 ('calculate') with a clear resource ('engagement metrics for a YouTube video') and enumerates the exact outputs: like rate, comment rate, and overall engagement rate. This clearly distinguishes it from all sibling tools, none of which focus on engagement calculations.
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 gives clear context: use this tool when engagement metrics for a YouTube video are needed. It does not explicitly name alternatives or exclusions, but among the sibling tools there is no competing engagement-calculator, so the intended use is unambiguous.
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, the description must carry the transparency burden. It does disclose that only top-level comments are returned and lists the returned fields, which is useful. However, it does not mention possible failure modes such as disabled comments, pagination behavior, or any API limits.
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 scope, and the second lists the return fields. Every word earns its place and the key behavior is 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?
For a simple three-parameter read tool, the description covers what it does, its scope, and the return shape. It does not describe error cases or pagination, but that is a minor gap given the low complexity and fully documented schema.
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 input schema already explains url, order, and max_results. The tool description does not add parameter-level details beyond that, matching the baseline expected when the schema is fully documented.
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 and resource: 'Fetch top-level comments from a YouTube video.' It clearly distinguishes this tool from the transcript, metadata, channel, and playlist siblings, and it names the exact returned fields so an agent knows what to expect.
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 context is clear: use this to get comments for a specific video, and no sibling tool appears to offer comments at all. There are no explicit exclusions or when-not-to-use instructions, but none are strongly needed given the unique resource.
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 behavioral burden. It explains that the tool returns metadata and lists what is included, which is useful, but it does not mention authentication requirements, rate limits, error behavior, or URL handling edge cases.
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, information-dense sentence that leads with the action and resource, then lists the returned metadata fields. There is no redundant or filler content.
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 one-parameter metadata lookup, the description covers the essential return-value information well, especially since no output schema exists. It could be more complete by noting possible failure modes, but nothing critical is missing for basic 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?
Schema coverage is 100% and the single parameter is already described as 'YouTube video URL or video ID'. The tool description adds no additional parameter-level meaning, so it stays at the baseline for high schema coverage.
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 ('metadata for a YouTube video'), and enumerates the concrete fields returned. This clearly distinguishes it from sibling tools focused on transcripts, comments, channels, or search.
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 use case clear: retrieve comprehensive video metadata. It does not explicitly name alternatives or when not to use it, but the detailed field list communicates the intended purpose well enough to route an agent appropriately.
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?
The description states the core behavior: parsing URLs and extracting identifiers plus timestamps. With no annotations present, it could go further by describing the return structure or behavior on invalid input, but it does not mislead and clearly conveys that the tool is a read-only parsing operation.
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 tight sentences: the first captures the operation and outputs, the second lists supported formats. Every element earns its place with no filler or redundancy.
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 pure parsing tool, the description covers accepted inputs and extracted outputs, and sibling differentiation is achieved. The lack of an output schema is partly mitigated by listing the exact fields returned, though exact property names and invalid-input behavior are left implicit.
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%—the single 'url' parameter is already described as 'Any YouTube URL or video ID.' The description adds useful format examples, but these are illustrative rather than essential, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb ('parse'), a specific resource ('YouTube URL'), and the exact extracted outputs (video ID, channel ID, playlist ID, handle, timestamp). The listed URL formats make it immediately distinguishable from sibling tools, which operate on transcripts, metadata, or channel data rather than URL parsing.
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?
Explicitly enumerates the accepted input formats (youtube.com/watch, youtu.be, /shorts/, /embed/, /playlist, /channel/, /@handle, and bare video IDs), telling an agent exactly when this tool applies. It does not name an alternative, but no sibling performs URL parsing, so the applicability is clear without exclusions.
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 full burden and does disclose the key behavioral trait: it removes specific content types using SponsorBlock data. It does not mention edge cases like missing SponsorBlock coverage or caption availability, but the core transformation is 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?
Two concise sentences with no filler. The action and cleanup are front-loaded, and the summarization use case is a useful one-line addition.
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 fetch tool with fully documented parameters, the description is largely complete. It could improve by stating what happens when SponsorBlock data is unavailable or by describing the return format explicitly, since there is no output schema.
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 fully describes both parameters (url and lang) with 100% coverage. The description adds no additional parameter-specific guidance, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Fetch'), a clear resource ('YouTube video transcript'), and a precise transformation ('sponsor reads, intros, outros, self-promotion, and filler removed using SponsorBlock data'). This clearly differentiates it from the sibling get_transcript, which presumably returns the raw transcript.
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' provides a clear intended use case, and the cleanup behavior implies it is for when a raw transcript is too noisy. However, it does not explicitly say when to use get_transcript instead or mention exclusions.
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 provided, the description carries the full burden of behavioral disclosure. It discloses the prerequisite (50K+ views) and the nature of the output (intensity scores and top peaks with timestamps), which is meaningful context beyond the schema. It does not detail exact output fields or error behavior, but coverage is solid for a read-only data retrieval tool.
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?
Three sentences with no filler; the purpose, output, and key constraint are all included and front-loaded. Every sentence 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 tool with no output schema, the description explains what data is returned (intensity scores, top peaks, timestamps) and the critical prerequisite. It could add more detail about the exact response shape, but the agent has enough to invoke and interpret the result correctly.
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 describes `url` as 'YouTube video URL or video ID' with 100% coverage. The description adds little beyond reinforcing that the tool operates on a YouTube video, so it does not materially improve parameter understanding.
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 ('most replayed heatmap data for a YouTube video') and explains what it returns. It is easily distinguishable from sibling tools like get_video_metadata or extract_chapters because it uniquely targets rewatch heatmap data.
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 states a key usage constraint: 'Requires 50K+ views.' This helps an agent decide whether the tool is applicable for a given video. It does not explicitly name alternative tools, but no sibling directly overlaps with this heatmap functionality.
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:

[![Cluade_Youtube_MCP MCP server](https://glama.ai/mcp/servers/NomiDevx/Cluade_Youtube_MCP/badges/card.svg)](https://glama.ai/mcp/servers/NomiDevx/Cluade_Youtube_MCP)

Score Badge

Copy to your README.md:

[![Cluade_Youtube_MCP MCP server](https://glama.ai/mcp/servers/NomiDevx/Cluade_Youtube_MCP/badges/score.svg)](https://glama.ai/mcp/servers/NomiDevx/Cluade_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/NomiDevx/Cluade_Youtube_MCP'

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