YouTube MCP Server

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool has a clearly distinct purpose: get_channel_info, get_channel_videos, get_comments, get_transcript, get_video_info, search_channel_transcripts, search_transcript, and search_videos. There is no overlap in functionality—tools target specific resources (channel, video, comments, transcripts) and actions (get, search), making misselection unlikely.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case: get_channel_info, get_channel_videos, get_comments, get_transcript, get_video_info, search_channel_transcripts, search_transcript, search_videos. The naming is predictable and readable throughout.
Tool Count5/5
With 8 tools, the count is well-scoped for a YouTube server, covering core functionalities like retrieving channel/video info, comments, transcripts, and searching. Each tool earns its place without being overwhelming or insufficient.
Completeness4/5
The toolset covers key YouTube operations: retrieving info (channel, video, comments, transcripts) and searching (videos, transcripts, channel transcripts). Minor gaps include no update/delete actions (e.g., posting comments or managing playlists), but these are less critical for a read/search-focused server, and agents can work around this.
Average 3.4/5 across 8 of 8 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
This repository is licensed under MIT License.
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 states the action ('Get comments') but doesn't disclose key traits like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what the output looks like (though an output schema exists). For a tool with no annotations, this is a significant gap in transparency, as it leaves the agent guessing about operational constraints.
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, starting with the core purpose followed by parameter details. It uses two sentences efficiently, with no wasted words. The structure is logical, but it could be slightly improved by integrating usage context or behavioral notes, keeping it concise while adding value.
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 (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It covers the purpose and parameters but lacks behavioral transparency and usage guidelines. The presence of an output schema means the description doesn't need to explain return values, but it should still address when to use the tool and operational aspects. This results in a baseline completeness with clear gaps.
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 context beyond the input schema, which has 0% description coverage. It explains that 'video_url' is a 'YouTube video URL' and 'limit' is the 'Maximum number of comments' with default and max values. This compensates well for the low schema coverage, providing clear semantics for both parameters. However, it doesn't detail format specifics (e.g., URL structure), so it doesn't achieve a perfect 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: 'Get comments from a YouTube video.' It specifies the verb ('Get') and resource ('comments from a YouTube video'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_video_info' or 'get_transcript', which could also involve video-related data retrieval, so it doesn't reach a score of 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 sibling tools like 'get_video_info' (which might include comments) or 'search_transcript' (which could involve comment-like text). There's no context on prerequisites, such as needing a valid video URL, beyond what's implied in the parameters. This lack of explicit usage instructions limits its effectiveness for an AI agent.
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 this is a read operation ('Get'), but doesn't mention authentication requirements, rate limits, error conditions, or what happens with invalid URLs. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
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 with two sentences: one stating the purpose and returned data, another explaining the parameter. It's front-loaded with the core functionality. The Args section is clear but could be integrated more smoothly. There's minimal waste, though the example URL format adds helpful specificity.
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 has an output schema (which handles return values), no annotations, and a simple single-parameter input, the description is moderately complete. It covers the basic purpose and parameter meaning but lacks behavioral context (auth, errors, limits) and usage guidance relative to siblings. For a read-only tool with output schema, it meets minimum viability but has clear gaps.
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 schema has no descriptions for parameters), the description provides essential semantic context for the single parameter. It explains that video_url should be a YouTube video URL and gives an example format. This compensates well for the schema's lack of documentation, though it could specify URL validation rules or accepted URL patterns more precisely.
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 ('YouTube video'), listing the types of information returned (title, description, stats, tags, chapters). It distinguishes from siblings like get_channel_info or get_transcript by focusing on video metadata rather than channel data or transcript content. However, it doesn't explicitly contrast with search_videos, which might also return video information.
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 get_video_info over search_videos for finding video details, or how it differs from get_channel_videos which might also provide video information in a list format. There are no prerequisites, exclusions, or context for usage relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions default values and limits (20 default, 100 max), which is helpful, but doesn't address important behavioral aspects like whether this requires authentication, rate limits, pagination behavior, error conditions, or what format the returned videos will have (though output schema exists).
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 perfectly structured and concise. The first sentence states the core purpose, followed by a clean 'Args:' section that documents each parameter efficiently with examples and constraints. Every sentence earns its place with no wasted words.
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 has 3 parameters, no annotations, but does have an output schema, the description is moderately complete. It thoroughly documents all input parameters (compensating for 0% schema coverage) and the core functionality. However, for a data retrieval tool with siblings, it lacks usage context and some behavioral details that would help an agent use it effectively.
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 must compensate for all parameter documentation. It successfully explains all three parameters: 'channel' (accepts URL or @handle with example), 'limit' (default and maximum values), and 'sort' (two valid values with explanations). This provides clear semantic meaning beyond the bare 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 clearly states the action ('Get videos') and resource ('from a YouTube channel'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_video_info' or 'search_videos', which also deal with YouTube video retrieval in different contexts.
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' (for specific video details), 'search_videos' (for broader searches), and 'get_channel_info' (for channel metadata), there's no indication of when this channel-specific video listing tool is most 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 mentions nothing about rate limits, authentication needs, error handling, or what the output contains (though an output schema exists). For a tool with zero annotation coverage, this is a significant gap in transparency, as it doesn't describe any operational traits beyond the basic action.
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 highly concise and well-structured: a clear purpose statement followed by specific parameter details in a formatted 'Args:' section. Every sentence earns its place by providing essential information without redundancy, and it's front-loaded with the core functionality. No wasted words or unnecessary elaboration.
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 tool's low complexity (one parameter) and the presence of an output schema, the description is reasonably complete. It covers the purpose and parameter semantics adequately. However, it lacks behavioral context (e.g., rate limits, errors), which would be beneficial even with an output schema. For a simple lookup tool, this is mostly sufficient but not fully comprehensive.
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 valuable semantics beyond the input schema, which has 0% coverage. It clarifies that the 'channel' parameter accepts a 'Channel URL or @handle' and provides examples ('@mkbhd' or 'https://youtube.com/@mkbhd'), which the schema alone does not specify. With only one parameter, this effectively compensates for the low schema coverage, making the parameter usage clear.
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 verb ('Get information') and resource ('about a YouTube channel'), making the purpose immediately understandable. It distinguishes this from siblings like 'get_channel_videos' or 'get_video_info' by focusing on channel metadata rather than videos or transcripts. However, it doesn't specify what information is retrieved (e.g., subscriber count, description, uploads), keeping it from 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?
No guidance is provided on when to use this tool versus alternatives. While the name implies it's for channel data, there's no explicit comparison to siblings like 'search_channel_transcripts' or 'get_channel_videos' to clarify use cases. The description only states what it does, not when it's appropriate, leaving the agent to infer usage from context.
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 mentions the return format (matching passages with timestamps and direct links) which is helpful, but doesn't cover important aspects like authentication requirements, rate limits, error conditions, or whether this is a read-only operation. The description adds some value but leaves significant 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?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence earns its place - the first sentence states what the tool does, the second describes the return format, and the Args section provides necessary parameter context without 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?
Given that an output schema exists (so return values are documented elsewhere), the description provides adequate context for a search tool. It covers the core functionality and parameters well. The main gap is the lack of usage guidance relative to sibling tools, but for a tool with output schema and clear parameter documentation, this is reasonably complete.
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 all three parameters in the Args section. It clarifies that video_url is a YouTube URL, query is text to search for, and language has a default of 'en'. This adds meaningful context beyond the bare 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 clearly states the tool searches for content within a video's transcript, specifying the resource (transcript) and verb (search). It distinguishes from siblings like get_transcript (which retrieves full transcripts) and search_channel_transcripts (which searches across multiple videos), but doesn't explicitly mention these distinctions in the description itself.
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_transcript or search_channel_transcripts. It mentions what the tool does but offers no context about appropriate use cases, prerequisites, or exclusions.
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 default and maximum for the 'limit' parameter, which adds some context beyond the input schema. However, it lacks critical behavioral details such as whether this is a read-only operation, how results are sorted, if authentication is required, or any rate limits. For a search tool with no annotations, this leaves significant 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?
The description is highly concise and well-structured. It starts with a clear purpose statement, followed by a bullet-point-like format for parameters with essential details. Every sentence earns its place, with no redundant information, 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?
Given the tool's moderate complexity (2 parameters), lack of annotations, and presence of an output schema, the description is reasonably complete. It covers the purpose and parameter semantics adequately. Since an output schema exists, the description doesn't need to explain return values. However, it could improve by adding more behavioral context (e.g., sorting, authentication) to fully compensate for the missing annotations.
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 beyond the input schema, which has 0% schema description coverage. It explains that 'query' is a search query with an example ('how to price a SaaS'), and 'limit' has a default of 10 and maximum of 30. This compensates well for the lack of schema descriptions, providing clear usage context for both parameters.
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: 'Search YouTube for videos.' This is a specific verb ('Search') and resource ('YouTube videos'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_channel_transcripts' or 'search_transcript', which also search YouTube content but with different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'search_channel_transcripts' (for searching within a specific channel's transcripts) or 'search_transcript' (for searching video transcripts), leaving the agent to infer usage context. The only implicit guidance is the tool name and description, which is insufficient for clear differentiation.
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 mentions language fallback behavior, which is useful, but lacks details on permissions, rate limits, error handling, or output format. For a tool with no annotations, this leaves significant behavioral 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?
The description is front-loaded with the core purpose, followed by clear parameter explanations in a structured format. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 tool's moderate complexity (2 parameters, no annotations, but has output schema), the description covers the basic purpose and parameters well. The output schema likely handles return values, so the description doesn't need to explain those. However, it lacks usage guidelines and some behavioral details, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the purpose of both parameters (video_url for the YouTube video, language for preferred language with default 'en' and fallback behavior), adding meaningful context beyond the bare schema. However, it does not specify format constraints for video_url or valid language codes.
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 the specific action ('Get the full transcript') and resource ('YouTube video'), distinguishing it from siblings like get_video_info or search_transcript. It specifies the inclusion of timestamps, which is a key feature not implied by the tool name alone.
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 on when to use this tool versus alternatives like search_transcript or search_channel_transcripts. The description does not mention prerequisites, exclusions, or contextual factors that would help an agent choose between these sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It mentions 'power feature' and default/max values, but does not disclose rate limits, authentication requirements, error conditions, or what the search returns (though output schema exists). For a search tool with no annotations, this leaves significant gaps in understanding operational constraints.
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 a well-organized Args section. Every sentence adds value: the first establishes scope, the second emphasizes utility, and the parameter explanations are necessary given 0% schema coverage. No wasted words 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?
Given 4 parameters with 0% schema coverage and an output schema (which handles return values), the description does well by explaining all parameters. However, as a search tool with no annotations, it should ideally mention performance expectations (e.g., search time) or limitations (e.g., transcript availability). The output schema reduces the need for return value explanation, but behavioral context remains light.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It successfully explains all 4 parameters: channel (with URL/handle examples), query (text to search), language (preferred code with default), and max_videos (recent videos with default and max). This adds substantial meaning beyond the bare schema, though it could provide more detail on language code formats or channel input validation.
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 the specific action ('search for specific content'), resource ('across all videos of a YouTube channel'), and scope ('across all transcripts'), distinguishing it from siblings like search_transcript (single video) or search_videos (metadata). The phrase 'power feature: find what a creator said about any topic' further clarifies the unique value proposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('search for specific content across all videos'), but does not explicitly state when not to use it or name alternatives. Sibling tools like search_transcript (single video) and search_videos (metadata) are implied alternatives, but not directly referenced in the description.
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/Anarcyst/youtube-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Anarcyst/youtube-mcp-server)

Score Badge

Copy to your README.md:

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

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