youtube

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools cover distinct resources and actions with minimal overlap. The only potentially confusing pair is get_transcript vs get_clean_transcript, but their descriptions clearly distinguish raw transcripts from cleaned ones.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern using get_, search_, parse_, extract_, and calculate_, making the action and target predictable across the entire set.
Tool Count5/5
15 tools is at the upper boundary of the well-scoped range, but each tool serves a distinct YouTube workflow including video, channel, playlist, transcript, comments, and engagement analysis. No tool feels redundant.
Completeness4/5
The set covers most read-only YouTube needs: search, metadata, channels, playlists, transcripts, comments, trends, and engagement calculations. Minor gaps exist, such as fetching comment replies, channel playlists, or transcript language options, but core workflows are supported.
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 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals nothing beyond the basic search action: no mention of result ordering, whether Shorts or live streams are included, error behavior for invalid URLs, rate limits, or pagination. The only trait inferable is read-only-ness, which is implicit in 'search' and not explicitly disclosed.
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?
The description is a single sentence with the verb front-loaded and zero wasted words. It is appropriately sized for the thin content it carries, though a slightly richer definition with usage routing would still have remained concise. Not a 5 because the brevity is partly a product of under-specification, not deliberate economy.
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?
There is no output schema and no annotations, so an agent has no information about the return shape, result composition (e.g., video IDs, titles, metadata), or relevance ordering. In a 15-tool suite with closely related siblings like search_videos, search_transcript, and get_channel_videos, the single-sentence description leaves too much to inference for a tool that must be selected among near-cousins.
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 (channel URL, @handle, or channel ID), query, and max_results (1-50, default 10). The description adds no parameter-level meaning, which is acceptable at the baseline given the full schema coverage. No compensation is needed.
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 (search) and a well-scoped resource (videos within a specific YouTube channel). The 'within a specific YouTube channel' qualifier distinguishes it from the general search_videos sibling, though it does not name the sibling explicitly. The purpose is unambiguous and an agent can understand what the tool does even without opening the schema.
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 scope qualifier 'within a specific YouTube channel' implies when this tool is appropriate: channel-scoped search rather than platform-wide search via search_videos. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of alternatives, and no exclusions. An agent must infer the selection logic from the sibling tool names.
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 behavioral burden. It discloses retrieval of recent videos and the two sort modes, and 'Get' implies a read operation. However, it does not clarify what 'recent' means, whether results are paginated, what data is returned, or any quota/rate-limit 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?
The description is two short, front-loaded clauses with no filler. It states the core purpose first and then adds the sorting capability efficiently.
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 the invocation details, but there is no output schema and no annotations, so the description needs to explain the return shape and the scope of 'recent videos.' These gaps are not fatal for a simple getter, but they leave an agent with ambiguity about output fields and the exact selection criteria.
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 mentions 'sorting by date or view count,' which mirrors the order enum, but it adds no additional meaning beyond the schema. The other parameters are already fully documented in the schema.
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 action and resource: 'Get recent videos from a YouTube channel.' It also lists the two sorting modes, which clarifies the operation. It is distinct from obvious siblings like get_channel_info, but it doesn't explicitly name alternatives to sharpen differentiation.
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 is provided about when to use this tool instead of search_videos, search_within_channel, get_playlist_items, or get_channel_info. The phrase 'from a YouTube channel' implies a listing use case, but no explicit context, exclusions, or alternative routing is given.
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 only states the search capability and filter categories; it does not mention what result fields are returned, whether pagination exists, or any API caveats. For a search tool with no output schema, this leaves meaningful behavioral ambiguity.
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 sentence with the core verb and resource front-loaded, followed by a compact enumeration of the filter dimensions. There is no filler or redundant restating of the tool name. Every word earns its place.
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 has six parameters, four enums, no output schema, and no annotations, yet the description only summarizes the filter categories. The input schema covers parameter semantics well, so the basic mechanics of calling the tool are documented, but the description omits search scope relative to siblings and the expected result payload. Additional context on what is returned and when this search is preferred over alternatives 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 all parameters already have descriptions, including enum values, defaults, and duration ranges. The description adds a helpful category-level summary ('upload date, duration, sort order, content type') but no new parameter-level meaning beyond the schema. Baseline 3 is appropriate because the schema carries the heavy lifting.
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 uses a specific verb ('Search'), names the resource ('YouTube'), and lists the key filter dimensions, making the tool's purpose immediately understandable. It does not explicitly distinguish from sibling search tools like search_within_channel or search_transcript, but the broad 'YouTube' scope and filter list provide most of the differentiation. The word 'videos' slightly understates the fact that type can be channel or playlist, but 'content type' hints at this broader scope.
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?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. The phrase 'Search YouTube' implies a general search across YouTube rather than channel-scoped or transcript-scoped search, and sibling tool names reinforce that inference, but the description itself does not state the boundary. This is implied usage guidance rather than explicit 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains what the tool returns (intensity scores and peaks with timestamps) and the view threshold, but doesn't disclose error behavior for videos below 50K views, rate limits, or whether the tool fails gracefully.
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?
Two sentences with the primary purpose front-loaded ahead of the output description and the view requirement. No redundant fluff, though the view requirement could arguably be integrated more tightly into the purpose statement.
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 covers the purpose, deliverable, and a key constraint (view count). Nothing critical is missing for an agent to call it correctly, though error handling for the view threshold is unexplained.
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% with a single 'url' parameter described as 'YouTube video URL or video ID'. The description adds no additional parameter-level detail, but the schema is sufficient on its own, so 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?
States a specific verb ('Get') and resource ('most replayed heatmap data for a YouTube video'), and describes the output (intensity scores, top peaks with timestamps). It's clear but doesn't explicitly differentiate from siblings like get_video_metadata or extract_chapters, though the concept is distinct enough.
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?
Provides a useful prerequisite ('Requires 50K+ views') that helps an agent know when the tool will succeed, but gives no guidance on when to choose this over alternatives or when not to use it. The context is implied rather than explicit.
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. The phrase 'Get all videos' conflicts with the max_results default of 25, and the description does not disclose pagination behavior, authentication needs, or rate limits. This is a meaningful gap for a tool that retrieves data from an external API.
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 and resource are front-loaded, and the second sentence efficiently lists the expected return contents.
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 names the return fields, which helps compensate for the absence of an output schema. However, it omits how max_results affects pagination and does not clarify that 'all' is not literal without additional requests. Overall it is adequate but incomplete.
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%: both url and max_results are already documented in the input schema. The description does not add parameter-specific 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (get) and resource (videos in a YouTube playlist), and it names the output fields (titles, channels, positions). It distinguishes the tool from sibling tools like get_transcript or get_channel_videos through the explicit 'YouTube playlist' scope, though it does not explicitly name an alternative.
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 intended use is clear: retrieve playlist contents with metadata. It does not explicitly state when not to use it or list alternative tools, but the domain context is strong enough that an agent can select it appropriately among the siblings.
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 bears the full burden of behavioral disclosure. It states that videos are 'currently trending/popular' (implying a dynamic list), but does not disclose any side effects, authentication requirements, rate limits, ordering guarantees, or whether results are refreshed. For a read-like operation it likely has no destructive effects, but that is not explicitly stated, and the description does not add significant behavioral context beyond the schema.
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 immediately states the core action and scope. There is no redundancy, fluff, or extraneous detail. Every word contributes to meaning, making it an efficient and well-structured description.
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?
Given the tool's simplicity (three optional parameters, no output schema), the description covers the basic action and scope but lacks several contextual details that an agent might need: how results are ordered (by popularity, views, etc.), whether results are region-dependent in a way that might surprise, or any limitations on region coverage. Without annotations, the description is adequate but not rich enough to fully inform correct usage in all cases, especially compared to sibling tools that could be mischosen.
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 provides 100% coverage, fully describing all three parameters (category_id, max_results, region_code) with types and example values. The tool description adds a passing reference to 'region and category', which aligns with two parameters, but does not introduce new meaning or clarify constraints beyond what the schema already documents. The baseline of 3 is appropriate since schema does the heavy lifting.
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 it fetches currently trending YouTube videos, scoped by region and category. It uses specific verbs and resource naming, and while it doesn't name a specific sibling alternative, the purpose is distinct from nearby tools like search_videos or get_video_metadata. The combination of 'trending/popular' and 'by region and category' precisely defines what it returns.
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 for retrieving trending videos, but it does not explicitly contrast with alternatives like search_videos (for general search) or get_video_metadata (for a single video). No guidance is given on when not to use this tool or which sibling to prefer in different scenarios. The implied context is there but not explicit.
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 burden of behavioral disclosure. It does add context by stating the source (video description) and the output fields, but it does not mention what happens when a video has no chapters, what timestamp format is returned, or that this is a read-only extraction.
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 focused sentence with no filler. The action and resource come first, followed by the output, making it easy to scan and understand 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?
For a one-parameter tool with no output schema, the description adequately explains what the tool does and what it returns. The main gaps are edge-case behavior and timestamp units, but these are minor for tool selection and 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?
The schema already fully documents the single url parameter with 100% coverage. The description adds no extra meaning about URL formats or examples, so it does not go 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?
The description states a specific verb and resource: extracting chapter timestamps from a YouTube video's description. It also names the return value: a structured chapter list with titles and start times. This clearly separates it from transcript, metadata, and other 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 is given for when to use this tool instead of siblings. The use case is implied by the name and description, but there are no alternative references, exclusions, or 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?
With no annotations provided, the description must carry the behavioral disclosure burden. It clarifies that metrics are based on view count, but does not specify the exact formulas, result format (percentages vs. ratios), or any edge cases. It implies a read-only calculation but does not confirm safety behavior explicitly.
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 structured sentence that front-loads the action and resource, names the computed metrics, and states the basis for calculation. There is no redundant or vague 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 one-parameter calculation tool, the description provides the essential context: what is computed and based on what. The only minor gap is the lack of explicit return-format details, but overall an agent has enough information to invoke it 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 schema already covers the only parameter with a clear description ('YouTube video URL or video ID'), and schema coverage is 100%. The tool description adds no additional parameter detail, which is acceptable under the high-coverage baseline but does not exceed it.
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 ('Calculate'), a clear resource ('a YouTube video'), and the concrete outputs (like rate, comment rate, overall engagement rate). This makes it immediately distinguishable from sibling tools such as get_video_metadata or get_video_comments.
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 about when to choose this tool over alternatives, no prerequisites, and no exclusion conditions. It is adequate but relies entirely on inference.
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 burden. It communicates that this is a read operation ('Get') and discloses the output fields plus accepted input forms. It does not address auth, errors, rate limits, or side effects, but for a simple metadata getter the stated behavior is reasonably complete.
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 redundancy: the first sentence says what data is returned, the second says how to identify the channel. This is appropriately sized 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?
For a single-parameter tool with no output schema, the description is complete: it lists the main output fields and all accepted input forms. An agent can construct the call and interpret the result without further documentation. The only minor absence is explicit handling of invalid URLs or non-existence, which is not essential for this scope.
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 already describes the parameter as 'YouTube channel URL, @handle, or channel ID'. The description repeats this same information without adding new semantics about format, validation, or examples, so it stays at the baseline for fully covered parameters.
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, 'Get YouTube channel information', and enumerates the returned fields. This clearly distinguishes it from siblings like get_video_metadata and get_channel_videos by indicating it is about channel-level profile data rather than video-level or listing operations.
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 this tool: whenever channel information such as title, subscriber counts, and thumbnails is needed. It does not explicitly mention alternatives or when not to use it, so an agent must infer the decision from the tool name and content among the many siblings.
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 clearly indicates a read operation ('Get') and lists the return fields, which is useful. However, it does not mention any potential side effects, authentication/rate limits, error conditions, or whether certain fields may be missing (e.g., for age-restricted videos). It does not contradict expectations, but leaves room for additional context.
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 states the primary purpose first and then lists the specific data fields. There is no extraneous wording, and the 'and more' keeps it open without padding.
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 metadata-retrieval tool with one parameter and no output schema, the description lists the returned fields comprehensively. It does not specify the response format (e.g., JSON structure) or error handling, but these are less critical given the straightforward nature of the operation. It could mention that it works for both URLs and IDs, but the schema already does that.
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 documents the single 'url' parameter (100% coverage), including the accepted format ('YouTube video URL or video ID'). The description adds no additional parameter-level detail, so it meets the baseline of 3 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') and a clear resource ('detailed metadata for a YouTube video'), then enumerates the exact fields (title, description, channel, duration, counts, tags, etc.). This distinguishes it from sibling tools that serve other purposes like transcripts (get_transcript) or comments (get_video_comments).
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 when metadata is needed, but does not explicitly state when to prefer this over alternatives, nor does it mention any exclusions or comparisons. Given the range of sibling tools, more explicit routing would help, but the verb and resource make the primary use case clear.
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, and it does disclose the key behavior: the transcript is cleaned by removing specific segment types using SponsorBlock data. However, it does not mention fallback behavior when SponsorBlock has no coverage, potential lossiness of segment removal, or failure modes, which an agent should know before relying on the output.
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 with zero filler: the core fetch-and-clean behavior is front-loaded, followed by a single high-value use-case hint. Every word earns its place.
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 transformation tool with no annotations and no output schema, the description explains the main operation and data source but omits caveats an agent would want: behavior when SponsorBlock has no data for the video, and whether the result preserves timestamps or is a plain text blob. Adequate for the summarization use case it advertises, 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%, with both url and lang already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, 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 verb ('Fetch'), resource ('YouTube video transcript'), and the defining transformation (removal of sponsor reads, intros, outros, self-promotion, and filler via SponsorBlock). This clearly distinguishes 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?
'Ideal for summarization' gives a clear, concrete context for when to choose this tool over alternatives. It stops short of explicit when-not-to-use guidance or naming get_transcript as the raw-transcript alternative, so it misses the top tier.
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 clearly states what the tool does and what it returns, including timestamps and surrounding context. It does not address edge cases like missing captions or no matches, but for a read-only search tool the core behavior 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?
The description is a single focused sentence that front-loads the action and resource, then states the return value. Every word contributes useful information, with 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, the schema covers all parameters, and the description explicitly states the return shape, which matters because there is no output schema. It could be slightly more complete by addressing what happens when no match is found or captions are unavailable, but an agent has enough to invoke it 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 documents all three parameters completely, including the default for 'lang'. The description adds no additional meaning about how the parameters behave, 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 uses a specific verb ('Search') and a clear resource ('a YouTube video's transcript'), and it states the output ('matching segments with timestamps and surrounding context'). This distinguishes it from siblings like get_transcript or get_clean_transcript, which retrieve whole transcripts rather than search within them.
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 this tool: when you need to find a keyword or phrase within a transcript. However, it does not explicitly contrast it with alternatives or state when not to use it, so the usage guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses return behavior (timed segments plus full text) and authentication requirements (no API key needed). It does not cover failure cases like missing captions or language fallback, but for a simple read operation this 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?
Two sentences, front-loaded with the main purpose, and every sentence provides useful information. There is no filler or repetition of schema details.
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 two documented parameters and no output schema, the description adequately describes the return value form and the tool's access requirements. It could add edge-case guidance, but nothing essential for normal invocation is missing.
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 both url and lang are already documented in the schema. The description adds general context but no parameter-specific meaning beyond what the schema provides, 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 uses a specific verb ('Fetch') and resource ('transcript/captions of a YouTube video'), and clarifies that the result includes timestamps, individual segments, and concatenated text. This clearly distinguishes it from siblings like get_clean_transcript or search_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 description gives clear context: this tool retrieves a full transcript, and explicitly notes no API key is needed. However, it does not state when to prefer alternatives like get_clean_transcript or search_transcript, so it stops short of full routing guidance.
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 burden of behavioral disclosure. 'Fetch' clearly signals a read-only, non-destructive operation, and the description further discloses the exact return fields (author, text, like count, reply count, publish date). It does not cover authentication, rate limits, or errors, but these are secondary for this simple read 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?
Two sentences with no filler or redundant content. The action and scope are front-loaded, and the return fields are listed concisely. Every sentence serves a clear purpose.
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 fully documented parameters and a returning output field list, the description covers the essential information an agent needs. It could note pagination or API-specific quirks, but given the simple scope and clear schema, the description is sufficiently 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 all three parameters (url, order, max_results) are already documented in the schema. The description adds no extra parameter-level detail, but it does not need to; the baseline of 3 applies because the schema does the heavy lifting.
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') with a clear resource ('top-level comments from a YouTube video'), and explicitly scopes to top-level comments, which distinguishes it from sibling video retrieval tools that return video metadata or search results. It is unambiguous and immediately tells an agent what the tool does.
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 intended usage is clear: use this tool when you need comments for a specific YouTube video. It does not explicitly name sibling tools or state exclusion conditions, but the description's focus on comments makes the usage context obvious enough among the likely alternatives.
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 so well: it discloses the input formats accepted and the fields extracted. It does not mention error handling for invalid or non-YouTube URLs, but for a parsing utility the given behavioral detail is substantial and not contradicted by any annotation.
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, information-dense sentences. The primary action and outputs are front-loaded, followed by a compact list of supported formats. No filler or repetition.
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 tool with no output schema, the description explains what to input and what will be returned. It leaves the timestamp unit unspecified and does not clarify whether all fields are always populated, but these are minor gaps for an extraction utility.
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 documents the only parameter ('Any YouTube URL or video ID') with 100% coverage. The description repeats the same concept without adding format or constraint details, 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 uses a specific verb ('parse') and resource ('YouTube URL'), and enumerates exactly what is extracted (video ID, channel ID, playlist ID, handle, timestamp). The supported URL formats are explicitly listed, which clearly distinguishes this utility from all sibling tools that deal with transcripts, metadata, 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 intended use obvious: when an agent has a YouTube URL or bare ID and needs structured identifiers. There are no explicit when-not-to-use statements or named alternatives, but no sibling tool performs this function, so the clear context is sufficient.
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-remote MCP server](https://glama.ai/mcp/servers/HassaanZakria/youtube-mcp-remote/badges/card.svg)](https://glama.ai/mcp/servers/HassaanZakria/youtube-mcp-remote)

Score Badge

Copy to your README.md:

[![youtube-mcp-remote MCP server](https://glama.ai/mcp/servers/HassaanZakria/youtube-mcp-remote/badges/score.svg)](https://glama.ai/mcp/servers/HassaanZakria/youtube-mcp-remote)

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/HassaanZakria/youtube-mcp-remote'

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