YouTube MCP

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation5/5
Each tool targets a distinct resource or operation: video info, channel playlists, channel videos, playlist videos, video comments, channel resolution, and keyword search. While list_youtube_channel_videos and search_youtube_channel_videos both deal with channel videos, one is for listing all uploads and the other for keyword search, making them clearly separable.
Naming Consistency4/5
Most tools follow a 'verb_youtube_noun' pattern (e.g., list_youtube_channel_playlists, list_youtube_video_comments). However, 'get_yt_video_info' uses the abbreviation 'yt' instead of 'youtube', breaking the pattern. This is a minor inconsistency.
Tool Count5/5
With 7 tools covering core read operations for YouTube data, the count feels well-scoped. Each tool earns its place, providing a focused but sufficient interface for common tasks like fetching video info, listing playlists/videos, retrieving comments, resolving channels, and searching.
Completeness4/5
The tool set covers the main read operations: video info, channel playlists, channel videos, playlist videos, video comments, channel resolution, and keyword search. Missing are direct playlist metadata retrieval and detailed channel statistics, but for a read-only interface these are minor gaps.
Average 4.3/5 across 7 of 7 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
- Last stable release on February 19, 2026
- 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 provided. Description lacks disclosure of behavioral traits such as read-only nature, authentication requirements, or rate limits. Only adds tip about input format.
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 redundancy. First sentence states purpose, second provides a helpful tip. Efficient and front-loaded.
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?
Output schema exists reducing need for return description. However, given lack of behavioral transparency and no annotations, the description minimally covers context for a tool of this complexity.
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 adds significant meaning by explaining the video_id parameter can be a raw ID or full URL, going beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch YouTube video information and transcript' with a specific verb and resource. Distinguished from sibling tools which focus on listing playlists or channel videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tip explicitly allows passing raw video ID or full URL, providing clear usage context. No explicit when-not or alternatives but usage is straightforward given sibling tool purposes.
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 provided, so description carries full burden. States 'public data' implying read-only. Mentions 'best-effort classification' for include_shorts/include_live. Returns include quotaEstimate, providing usage cost awareness. However, does not mention authentication requirements or rate limits, which would be helpful.
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?
Well-structured with separate sections for description, parameters, returns, and notes. Uses bullet points for clarity. Every sentence adds value. Front-loaded with purpose statement. No unnecessary text.
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 7 parameters, no annotations, and sibling tools, description covers most needed information. Explains returns (items, nextPageToken, quotaEstimate). But misses describing next_page_token parameter and does not reference sibling tools for context. Adequate but could be more 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?
Schema coverage is 0%, so description adds significant meaning. Explains playlist_id, page_token (pagination), max_items, include_shorts/include_live (default false, best-effort), and parts_level (basic/full). However, input schema also includes next_page_token parameter which is not described, causing potential confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'List videos in a playlist' which clearly states verb and resource. Adds 'public data' to clarify scope. Distinguishes from siblings like list_youtube_channel_videos (which lists videos from a channel) and list_youtube_channel_playlists (which lists playlists of a channel).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention when not to use it or reference sibling tools for comparison. The description only states what it does, leaving the agent to infer usage context.
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 full burden. It discloses API method, quota cost, pagination mechanism, max cap, and a common failure. This is comprehensive for a read-only list tool, though it could explicitly state read-only nature.
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 concise and well-structured with a main line, notes, pagination, returns, and common failure. Each section is short and to the point, with no unnecessary words.
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 7 parameters and no schema descriptions or annotations, the description covers purpose, behavior, outputs, and failure. Output schema exists, so detailed return fields are not needed. Missing some param details and usage guidelines, but overall adequate.
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 explains pagination tokens, max_threads cap, and order default, but does not describe video_id, text_format, or include_replies beyond implicit hints. The output description partially fills gaps but not completely.
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 'List comment threads for a YouTube video (public comments),' specifying the verb, resource, and context. This distinguishes it from sibling tools that focus on videos, playlists, or channels.
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 provides basic context (listing comments) and mentions a failure case (403 if disabled). However, it does not explicitly state when to use this tool versus alternatives or when not to use it. With no sibling comment tools, the need for guidance is lower, but still room for improvement.
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 full burden. It clearly states it only accesses public playlists, which is a key behavioral trait. The inclusion of quota estimates in the return also adds transparency. No contradictions.
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 with sections for parameters, returns, and notes. The first sentence front-loads the purpose. It is concise without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's scope (public playlists only), pagination, and return structure. Since an output schema exists, it is not required to detail every field. The mention of quota estimates adds useful context.
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 describes channel_ref's format by referencing resolve_youtube_channel and mentions page_token for pagination. However, next_page_token is present in the schema but not described.
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 lists public playlists for a channel, with a specific verb ('list') and resource ('playlists'). It distinguishes from siblings like list_youtube_channel_videos by focusing on playlists.
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 mentions the tool lists only public playlists and explicitly notes it does not list private playlists, providing a clear usage constraint. However, it does not direct the agent to alternative tools for private playlists or other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it uses the YouTube Search API, is quota-expensive (100 units per page), and results may be capped. Also explains pagination mechanism with page_token, adding value beyond no annotations.
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?
Well-structured with clear sections (purpose, when to use, important notes, pagination, returns). Each sentence adds value with no 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?
Provides sufficient context for most aspects: purpose, usage, pagination, and return values. However, lacks parameter explanations for non-obvious fields, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains pagination tokens but does not describe other parameters like order, max_videos, parts_level, etc., leaving gaps.
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 searches for videos within a channel by keyword, distinguishing it from sibling tools like list_youtube_channel_videos which enumerates the full playlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a 'When to use' section explicitly recommending this tool for keyword searches without enumerating the full uploads playlist, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It discloses public-only data, safe defaults, quota estimates, pagination, truncation, and safety notes (no file/network access). Behavior is transparent and complete.
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 with sections (default behavior, parameters, returns, notes). It is lengthy but every sentence adds value. Slightly verbose, but appropriate for complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and an output schema, the description is thorough. It covers all parameters, behavior, quotas, safety, and return structure. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter in detail: channel_ref formats, max_videos as hard limit, page_token alias, include_shorts/live defaults, parts_level options, order_strategy/order_by options and constraints. It also explains return fields.
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 'List videos for a channel (public data), with safe defaults.' The name and title align perfectly. It differentiates from siblings like list_youtube_playlist_videos by focusing on channel videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidance: default behavior, pagination, parameter explanations, and when to use different order strategies (e.g., 'Explicit opt-in only' for search_api). However, it does not explicitly contrast with sibling tools (e.g., when to use list_youtube_playlist_videos instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states safety notes: no destructive actions, no access to private channel data. It also details failure modes (missing API key, ambiguous input) and behavior of resolution modes. This fully informs the agent of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (What this tool does, Supported input formats, Parameters, Returns, Failure modes, Safety notes). It is comprehensive but not overly verbose. The main purpose is front-loaded. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema exists), the description is complete. It covers input formats, parameter behavior, return structure (structured JSON), failure modes, and safety. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description explains each parameter in detail: channel_ref formats, resolution_mode options (strict vs best_effort) with implications, and include_uploads_playlist boolean. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Resolve a YouTube channel reference into a concrete channelId.' It specifies the verb (resolve) and resource (YouTube channel reference to channelId). It also lists supported input formats, making the scope explicit. The tool is distinct from siblings like get_yt_video_info or list_youtube_channel_playlists, which handle different tasks.
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 explains that the tool converts user-facing channel identifiers into channelId, and optionally provides uploadsPlaylistId. It implies usage when you have a channel reference, but does not explicitly state when not to use it or mention alternatives, though the sibling tools suggest other cases. Clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![youtube_mcp MCP server](https://glama.ai/mcp/servers/glonorce/youtube_mcp/badges/score.svg)](https://glama.ai/mcp/servers/glonorce/youtube_mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/glonorce/youtube_mcp'

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