YouTube MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. The tools cover different aspects of YouTube interaction: content generation (flashcards, quiz, summary), information retrieval (video info, channel details, search), and social features (comments, related videos, trending). Each tool name precisely indicates its unique function.
Naming Consistency4/5
The naming is mostly consistent with a verb_noun pattern (e.g., generate_video_flashcards, get_video_info, summarize_video), but there are minor deviations. Three tools append '_tool' (get_related_videos_tool, get_trending_videos_tool, get_video_comments_tool), which breaks the pattern slightly, though the core naming remains readable and predictable.
Tool Count5/5
With 9 tools, this is well-scoped for a YouTube-focused server. Each tool earns its place by covering distinct functionalities like content analysis, metadata retrieval, and social interactions. The count is neither too sparse nor bloated, fitting typical expectations for a domain-specific server.
Completeness4/5
The tool surface is largely complete for YouTube content interaction, covering key areas such as video summarization, quiz generation, metadata access, and social features. Minor gaps exist, like the inability to post comments or manage playlists, but these are not critical for core agent workflows and can be worked around.
Average 2.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates flashcards but doesn't describe how it processes video content (e.g., transcription, AI analysis), whether it requires internet access or specific permissions, potential rate limits, or error conditions. The description mentions a return format ('Formatted string') but lacks details on structure or pagination.
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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by an 'Args:' section listing parameters with defaults, and ends with a 'Returns:' note. Each sentence adds value, though the parameter explanations could be more detailed given the 0% schema coverage.
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 no annotations, 0% schema coverage, and no output schema, the description is moderately complete. It covers the tool's purpose and parameters but lacks behavioral context (e.g., processing method, limitations) and detailed output information. For a tool with four parameters and no structured documentation, it should provide more guidance on usage and results.
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 0%, so the description must compensate. It lists all four parameters with brief explanations, adding meaning beyond the schema's minimal titles. However, it doesn't elaborate on parameter interactions (e.g., how 'categories' and 'difficulty' filter results), valid values for 'categories' or 'difficulty', or the implications of defaults. The description partially compensates but leaves gaps.
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's purpose: 'Generate flash cards from a YouTube video's content.' This specifies the verb ('generate'), resource ('flash cards'), and source ('YouTube video's content'). It distinguishes from siblings like 'generate_video_quiz' by focusing on flashcards rather than quizzes, but doesn't explicitly contrast with other video processing tools like 'summarize_video'.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when flashcards are preferable to quizzes (from 'generate_video_quiz') or summaries (from 'summarize_video'), nor does it specify prerequisites like video accessibility or content type suitability. Usage context is implied but not articulated.
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 states the tool generates a quiz with 10 questions of various types, which adds some context beyond the basic purpose. However, it lacks details on permissions, rate limits, error handling, or whether it's a read-only or mutation operation (though 'generate' suggests creation, this isn't clarified). For a tool with zero annotation coverage, this is a significant gap.
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 appropriately sized and front-loaded, with the core purpose stated first. The 'Args' and 'Returns' sections add structure, though they could be more integrated. There's no wasted text, but the formatting is slightly verbose for such a simple tool.
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 complexity (simple generation with one parameter), no annotations, no output schema, and low schema coverage, the description is somewhat complete but has gaps. It covers the purpose and return format, but lacks behavioral details and parameter nuances. It's adequate as a minimum viable description but not fully comprehensive.
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 description adds minimal meaning beyond the input schema. It specifies that 'video_id' is a 'YouTube video ID,' which provides context not in the schema (which has 0% description coverage and only lists 'Video Id' as the title). However, with only one parameter, the baseline is 4, but the description doesn't fully compensate for the low schema coverage by explaining format or constraints (e.g., length, validation). Thus, it's scored slightly below baseline.
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's purpose: 'Generate a quiz based on the video content.' It specifies the verb ('generate') and resource ('quiz'), and distinguishes it from sibling tools like 'generate_video_flashcards' or 'summarize_video' by focusing on quiz creation. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_video_info' might also process video content), so it's not a perfect 5.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'generate_video_flashcards' or other video-related tools, nor does it specify prerequisites or exclusions. The context is implied (video-based quiz generation), but explicit usage instructions are absent.
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 action ('Get detailed information') without explaining what 'detailed information' includes, whether it requires authentication, rate limits, error conditions, or the response format. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first in a clear sentence. The 'Args' section is concise but could be integrated more smoothly. There's no wasted text, though it lacks structural polish for optimal readability.
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?
Given the complexity (a read operation with no annotations, 1 parameter, and no output schema), the description is incomplete. It doesn't explain what 'detailed information' entails, how to handle errors, or the return format. For a tool with zero annotation coverage and no output schema, more context is needed to guide the agent effectively.
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 description adds minimal semantics beyond the input schema. It specifies that 'channel_id' is a 'YouTube channel ID,' which clarifies the parameter's purpose but doesn't provide format examples or constraints. With 0% schema description coverage and 1 parameter, the baseline is 4, but the description only partially compensates by naming the parameter type without further detail.
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's purpose: 'Get detailed information about a YouTube channel.' It specifies the verb ('Get') and resource ('YouTube channel'), making the action explicit. However, it doesn't distinguish this from sibling tools like 'get_video_info' or 'get_videos,' which also retrieve YouTube data but focus on videos rather than channels.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools such as 'get_video_info' (for video details) or 'get_videos' (for listing videos), leaving the agent to infer usage based on the resource type (channel vs. video). No exclusions or prerequisites are stated.
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 mentions the action ('Get videos') and a default parameter, but fails to describe critical behaviors such as rate limits, authentication needs, error handling, or the format of returned data (e.g., list of video objects). This leaves significant gaps for an agent to understand how the tool operates.
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 appropriately sized and front-loaded, with the purpose stated first followed by parameter details in a clear 'Args' section. It avoids unnecessary information, but the parameter explanations could be slightly more detailed to improve clarity without adding waste.
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?
Given the complexity (a tool with 2 parameters, no annotations, and no output schema), the description is incomplete. It lacks information on behavioral traits, output format, and usage context relative to siblings. For a tool that retrieves data, this leaves the agent without sufficient guidance to use it effectively in varied scenarios.
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 0%, so the description must compensate. It adds meaning by explaining 'video_id' as a 'YouTube video ID' and 'max_results' with its default value and purpose. However, it does not provide details like valid formats for 'video_id' or constraints for 'max_results' (e.g., min/max values), which are needed for full compensation, resulting in a baseline score.
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's purpose with 'Get videos related to a specific video,' specifying the verb ('Get') and resource ('videos related to a specific video'). However, it does not explicitly differentiate from sibling tools like 'get_videos' or 'get_trending_videos_tool,' which might also retrieve videos but under different contexts, so it lacks sibling differentiation for a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It does not mention when to choose it over siblings like 'get_videos' (which might fetch general videos) or 'get_trending_videos_tool' (which might fetch trending content), nor does it specify any exclusions or prerequisites for usage.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't mention important behavioral aspects like authentication requirements, rate limits, pagination behavior, comment sorting order, whether it retrieves top-level comments only or includes replies, or what happens when max_results exceeds available comments.
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 appropriately concise with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient, though the 'Args:' section formatting could be slightly cleaner. Every sentence serves a purpose.
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?
For a tool with 2 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the return value looks like (comment structure, fields), doesn't mention error conditions, and provides minimal behavioral context despite the lack of structured metadata.
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 0%, so the description must compensate. It provides basic semantic meaning for both parameters ('YouTube video ID' and 'Maximum number of comments to return'), which adds value beyond the schema's bare titles. However, it doesn't explain format requirements for video_id or constraints on max_results (minimum/maximum values).
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's purpose with 'Get comments for a video' - a specific verb ('Get') and resource ('comments for a video'). It distinguishes from some siblings like 'get_video_info' (which gets metadata) or 'summarize_video' (which creates summaries), but doesn't explicitly differentiate from all comment-related tools (though none exist in the sibling list).
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 provides no guidance on when to use this tool versus alternatives. While the sibling list includes other video-related tools, there's no indication of when to choose this comment-fetching tool over others, nor any prerequisites or constraints for usage.
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 states the tool gets 'detailed information' but doesn't specify what that includes (e.g., metadata, statistics, duration), whether it's a read-only operation, potential rate limits, or error handling. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the main purpose stated first and args listed clearly. It avoids unnecessary fluff, but the args section could be more integrated into the flow rather than a separate block. Overall, it's efficient with minimal waste.
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?
Given the complexity (a read operation with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It doesn't explain what 'detailed information' entails, potential return values, or how it differs from siblings. For a tool in this context, more detail is needed to be fully helpful.
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 description adds minimal parameter semantics: it mentions 'video_id: YouTube video ID,' which clarifies the parameter's purpose beyond the schema's title 'Video Id.' However, with 0% schema description coverage and only one parameter, this provides basic context but doesn't fully compensate for the lack of schema details (e.g., format examples).
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's purpose as 'Get detailed information about a video,' which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'get_videos' (plural) or 'get_related_videos_tool,' which might have overlapping functionality. The purpose is clear but lacks sibling 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_videos' (which might list videos) and 'get_related_videos_tool' (which might fetch related content), there's no indication of context, prerequisites, or exclusions. Usage is implied only by the tool name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves videos for a search query but lacks details on behavioral traits such as authentication needs, rate limits, pagination, or what happens if no results are found. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose in the first sentence, followed by a structured 'Args' section. It avoids unnecessary details, though the formatting could be slightly more polished for clarity.
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?
Given the complexity of video retrieval, lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't explain return values, error handling, or how results are structured, leaving key contextual gaps for effective tool use.
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 description includes an 'Args' section that lists and briefly describes the two parameters ('search' and 'max_results'), adding meaning beyond the input schema which has 0% description coverage. However, it doesn't provide details like expected formats for 'search' or constraints for 'max_results', only partially compensating for the schema gap.
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's purpose with a specific verb ('Get') and resource ('videos'), and specifies it's for a search query. However, it doesn't differentiate from sibling tools like 'get_trending_videos_tool' or 'get_related_videos_tool' which might also retrieve videos under different conditions.
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 provides no guidance on when to use this tool versus alternatives like 'get_trending_videos_tool' or 'get_related_videos_tool'. It mentions a search query but doesn't specify contexts where this is preferred over other video retrieval tools, leaving usage unclear.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does without mentioning any behavioral traits such as rate limits, authentication requirements, pagination, or response format. This leaves significant gaps in understanding how the tool operates in practice.
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 front-loaded with the core purpose in the first sentence, followed by parameter details in a structured 'Args' section. It avoids unnecessary words, but the parameter explanations could be slightly more detailed without sacrificing conciseness, keeping it efficient overall.
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?
Given the complexity of fetching trending videos (which may involve API limits, regional variations, or data freshness), the description is incomplete. With no annotations, no output schema, and minimal behavioral context, it fails to provide enough information for reliable use. It should address aspects like response structure or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for both parameters: it explains that 'region_code' is a 'Two-letter ISO country code' and 'max_results' is the 'Maximum number of videos to return'. Since schema description coverage is 0%, this compensates well by providing essential context beyond the bare schema, though it could include examples or constraints for higher clarity.
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's purpose: 'Get trending videos for a region.' It specifies the verb ('Get') and resource ('trending videos'), making the function unambiguous. However, it doesn't distinguish this tool from sibling tools like 'get_videos' or 'get_related_videos_tool', which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_videos' or 'get_related_videos_tool', nor does it specify use cases or prerequisites. The only implied context is the need for trending videos, but this is insufficient for effective tool selection.
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. While 'Get a comprehensive summary' implies a read-only operation, it doesn't specify what 'comprehensive' includes (e.g., transcript analysis, key points, duration), whether there are rate limits, authentication requirements, or what the output format looks like. This leaves significant gaps for an agent to understand the tool's 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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence serves a purpose: the first states what the tool does, and the Args section provides necessary parameter details without redundancy. It's appropriately sized for a tool with two parameters.
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 moderate complexity (summarizing video content), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and parameters but lacks details about the summary format, potential limitations (e.g., video length constraints), or how it differs from sibling tools. This leaves the agent with incomplete context for optimal usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters in the Args section: 'video_id' is clearly identified as a YouTube video ID, and 'include_comments' is explained with its default value and purpose. This adds meaningful context beyond the bare schema, though it doesn't specify format details for the video_id.
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's purpose with a specific verb ('Get') and resource ('comprehensive summary of a YouTube video'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_video_info' or 'generate_video_flashcards', which might also provide video-related information in different formats.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_video_info' (likely providing raw metadata), 'generate_video_flashcards' (creating study aids), and 'get_video_comments_tool' (fetching comments), there's no indication of when a summary is preferred over these other options.
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-server MCP server](https://glama.ai/mcp/servers/temiedani/youtube-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/temiedani/youtube-mcp-server)

Score Badge

Copy to your README.md:

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

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/temiedani/youtube-mcp-server'

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