youtube-mcp
The YouTube MCP server provides a comprehensive interface to the YouTube Data API v3, enabling you to search, retrieve, and analyze YouTube content programmatically.
Search Videos – Search YouTube videos with advanced filters including sort order, duration, definition (HD/SD), license type, video type, region, channel, topic, and date range.
Search Channels – Find YouTube channels by keyword query.
Search Playlists – Search for playlists by keyword query.
Get Video Details – Retrieve comprehensive information (statistics, content details, topics, etc.) for one or more videos by ID.
Get Channel Details – Fetch detailed channel information including statistics, branding, and topics by ID.
Get Channel by Handle – Look up a YouTube channel using its @username/handle.
Get Trending Videos – Retrieve the most popular videos for a specific region, optionally filtered by category.
Get Video Categories – Browse available video categories for a given region.
Get Channel Videos – List recent uploads from a specific channel, with optional date filtering.
Get Playlist Videos – Retrieve videos from any YouTube playlist by playlist ID.
Get Video Comments – Fetch comments on a specific video, sortable by relevance or time.
Provides tools for searching videos, channels, playlists, getting trending content, video details, comments, and more via the YouTube Data API v3.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@youtube-mcpsearch for AI news from the last week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
YouTube MCP Server
Model Context Protocol (MCP) server for YouTube Data API v3. Provides tools for searching videos, channels, playlists, getting trending content, video details, comments, and more.
Features
Video Search - Search YouTube videos with advanced filters (duration, definition, region, date range, etc.)
Channel Search - Find channels by query
Video Details - Get comprehensive video information (statistics, content details, topics, etc.)
Channel Details - Get channel statistics, branding, topics, and more
Trending Videos - Get most popular videos by region and category
Video Categories - Browse available video categories
Channel Videos - Get recent uploads from a specific channel
Playlist Videos - Get videos from any playlist
Playlist Search - Search for playlists
Video Comments - Get comments on videos
Channel by Handle - Look up channels by @username
Related MCP server: YouTube MCP Server
Installation
git clone https://github.com/PPiai/youtube-mcp.git
cd youtube-mcp
pip install -e .Or with uv:
uv pip install -e .Configuration
Requires a YouTube Data API v3 key. Get one from Google Cloud Console.
Copy .env.example to .env and fill in your values:
cp .env.example .envVariable | Default | Description |
| — | Required. YouTube Data API v3 key |
|
|
|
|
| Bind host (HTTP mode) |
|
| Bind port (HTTP mode) |
Transports
This server supports two transports, selected by MCP_TRANSPORT:
Streamable HTTP (remote service — default)
Runs as a persistent HTTP service on a single port (default 8000).
Endpoint | Method | Purpose |
|
| MCP streamable-HTTP endpoint (JSON-RPC) |
|
| Health check — returns |
MCP_TRANSPORT=streamable-http PORT=8000 youtube-mcp
# MCP endpoint: http://localhost:8000/mcp/
# Health: http://localhost:8000/healthNote — trailing slash. The MCP endpoint is mounted at
/mcp, soPOST /mcpreturns a 307 redirect to/mcp/. Always point clients at/mcp/(with the trailing slash) to avoid clients that don't follow redirects onPOST.
Connecting an MCP client to the remote endpoint (e.g. mcp.json /
Claude Desktop style config):
{
"mcpServers": {
"youtube": {
"type": "streamable-http",
"url": "https://<your-domain>/mcp/"
}
}
}Quick test with curl:
# Health
curl https://<your-domain>/health
# Initialize (note: streamable-HTTP replies with an SSE stream)
curl -X POST https://<your-domain>/mcp/ \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}'
# Call a tool
curl -X POST https://<your-domain>/mcp/ \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"search_videos","arguments":{"query":"ai news","max_results":2}}}'⚠️ Security. The HTTP endpoint has no built-in authentication — anyone who can reach the URL can issue requests and consume your YouTube API quota. Put it behind an authenticating reverse proxy / network policy, or keep it on a private network. Do not expose it publicly without protection.
stdio (local)
Launched on-demand by a local client (e.g. via uvx):
mcp_servers:
youtube:
command: "uvx"
args: ["youtube-mcp"]
env:
YOUTUBE_API_KEY: "your_api_key_here"
MCP_TRANSPORT: "stdio"
timeout: 120
connect_timeout: 60Deploy (EasyPanel / Docker)
Build and run as a container:
docker build -t youtube-mcp .
docker run -p 8000:8000 -e YOUTUBE_API_KEY="your_api_key_here" youtube-mcpOn EasyPanel, set YOUTUBE_API_KEY as a service environment variable (not a
build-arg), expose port 8000, and point the MCP client to
https://<your-domain>/mcp.
Available Tools
Tool | Description |
| Search videos with filters |
| Search channels |
| Get detailed video info |
| Get detailed channel info |
| Get trending videos by region |
| Get video categories |
| Get channel's recent videos |
| Get playlist videos |
| Search playlists |
| Get video comments |
| Get channel by @handle |
Example Queries
"Search for videos about AI news from the last week"
"Get trending videos in Brazil (BR)"
"Find channels about programming tutorials"
"Get details for video dQw4w9WgXcQ"
"Get comments on a viral video"
"Find playlists about machine learning"
Development
# Install dev dependencies
pip install -e ".[dev]"
# Run the server locally over HTTP and smoke-test it
MCP_TRANSPORT=streamable-http youtube-mcp &
curl http://localhost:8000/healthNo automated test suite yet —
pytestis wired up in thedevextra but there are no tests under atests/directory. Contributions welcome.
License
MIT
Available Tools
11 toolsget_channel_by_handleC
Get channel details by handle (@username)
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | YouTube handle (e.g., @MrBeast or MrBeast) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose any behavioral traits such as authentication needs, rate limits, or data freshness. Only the basic operation is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, concise and front-loaded. It efficiently conveys the core purpose without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is too minimal. It does not explain the response structure or any constraints, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for the handle parameter. The tool description adds marginal value by noting the '@' prefix format, but overall does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves channel details using a handle format. However, it does not differentiate from the sibling tool 'get_channel_details', which likely serves a similar purpose but possibly by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_channel_details'. The description implies usage when a handle is available, but lacks explicit when-not conditions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_channel_detailsB
Get detailed information about specific channels
| Name | Required | Description | Default |
|---|---|---|---|
| channel_ids | Yes | List of YouTube channel IDs |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or what 'detailed information' entails. Agent must infer safety and behavior from schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste. However, it could be slightly more verbose to add context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description is insufficient. 'Detailed information' is vague; agent cannot anticipate return format or completeness. Missing context about output or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description 'List of YouTube channel IDs', so baseline is 3. The tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('specific channels'), effectively distinguishing it from siblings like get_channel_by_handle (by handle) and get_channel_videos (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_channel_by_handle). The description implies channel IDs are required but does not explicitly state prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_channel_videosB
Get recent videos from a specific channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | YouTube channel ID | |
| max_results | No | Maximum number of results (1-50) | |
| order | No | date | |
| published_after | No | ISO 8601 datetime filter |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only says 'Get recent videos' but omits whether it returns only public videos, pagination, rate limits, or that it's a read-only operation. Significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence with no wasted words, front-loaded with verb and resource. Could be slightly more informative for a 4-parameter tool, but remains concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 4 parameters, the description should include what the tool returns (e.g., list of video objects) and mention filtering defaults. It lacks critical context for full usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the description is not required to detail parameters. The description adds no extra meaning beyond the schema, meeting baseline level for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'recent videos from a specific channel', distinguishing it from sibling tools like search_videos or get_playlist_videos. The tool uniquely gets videos filtered by channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_videos with channel filter. Lacks explicit usage context or exclusions, which is problematic given 10 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_playlist_videosC
Get videos from a YouTube playlist
| Name | Required | Description | Default |
|---|---|---|---|
| playlist_id | Yes | YouTube playlist ID | |
| max_results | No | Maximum number of results (1-50) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It fails to mention pagination, return format, ordering, or any side effects. The brief description does not add value beyond naming the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point. It is front-loaded and efficient, though it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema), the description is incomplete. It does not explain what is returned (e.g., video details or just IDs) or the impact of the max_results parameter beyond what the schema states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with basic descriptions for both parameters (playlist_id and max_results). The tool description adds no additional meaning over the schema, achieving baseline adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get videos from a YouTube playlist' clearly states the action (get), resource (videos), and source (YouTube playlist). It is specific enough to differentiate from sibling tools like get_channel_videos or search_videos, though it does not explicitly mention the uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as when a specific playlist ID is known vs searching for playlists. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trending_videosB
Get trending/popular videos for a region
| Name | Required | Description | Default |
|---|---|---|---|
| region_code | Yes | ISO 3166-1 alpha-2 country code | US |
| category_id | No | Video category ID (optional) | |
| max_results | No | Maximum number of results (1-50) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states 'trending/popular videos' without clarifying how trends are determined, rate limits, output format, or any side effects. Lacks essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at six words, with no redundant information. However, it sacrifices useful detail for brevity, earning a slightly higher score for efficiency but not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should provide more context. It lacks information about return format, pagination, or other important aspects, making it incomplete for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond the schema, meeting the baseline but not exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves trending/popular videos for a region, using a specific verb and resource. It distinguishes from sibling tools like 'search_videos' or 'get_channel_videos' by specifying trending/popular content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'search_videos' or 'get_trending_videos' vs 'get_channel_videos'. No exclusions or prerequisites mentioned, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_video_categoriesB
Get video categories for a region
| Name | Required | Description | Default |
|---|---|---|---|
| region_code | Yes | ISO 3166-1 alpha-2 country code | US |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only says 'get', implying a read operation, but does not mention authentication, rate limits, or what the function returns. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the purpose. It is concise and front-loaded, but could be slightly improved by including a bit more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more completeness about what 'get' returns and any constraints. As it stands, it is too sparse for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (only one parameter region_code with description). The description adds no extra meaning beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get), the resource (video categories), and the scope (for a region). It distinguishes itself from sibling tools which focus on channels, videos, or playlists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that this tool is for listing categories, while search tools are for finding specific items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_video_commentsC
Get comments for a YouTube video
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | YouTube video ID | |
| max_results | No | Maximum number of results (1-100) | |
| order | No | relevance |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Get comments'. It fails to disclose behavioral traits like authentication requirements, rate limits, pagination, or whether comments are returned for all videos (public/private).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it sacrifices informational content. Every word is needed, but the sentence does not cover important aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify return format (e.g., list of comments, fields included). It does not. The tool complexity is moderate (3 params, pagination via max_results), and the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (video_id and max_results described in schema, but order has no description). The tool description adds no parameter information; for order, the agent must infer meaning from the enum values alone. This is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets comments for a YouTube video, which is a specific verb+resource combination. It distinguishes from siblings like get_video_details (which likely returns video metadata) and search_videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor are there prerequisites or exclusions. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_video_detailsC
Get detailed information about specific videos
| Name | Required | Description | Default |
|---|---|---|---|
| video_ids | Yes | List of YouTube video IDs |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Get detailed information', without specifying what 'detailed' entails, whether it includes statistics, thumbnails, etc. There is no mention of rate limits, authentication needs, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is front-loaded with the verb and resource. However, it could benefit from a brief note on output or usage without being verbose. The conciseness is good but not exceptional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is incomplete. It does not explain what 'detailed information' includes, such as metadata fields, or whether it handles missing IDs. An agent needs more context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's 'List of YouTube video IDs' for the 'video_ids' parameter. It does not clarify format, constraints, or behavior (e.g., max IDs).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about specific videos', providing a specific verb and resource. However, it does not differentiate from sibling tools like 'get_video_comments' or 'get_trending_videos', which could also provide video details. A score of 4 is appropriate as it is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'search_videos' or 'get_trending_videos'. There are no conditions, prerequisites, or exclusions mentioned, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_channelsC
Search for YouTube channels
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| max_results | No | Maximum number of results (1-50) | |
| order | No | relevance |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description omits behavioral details such as authentication requirements, rate limits, or pagination behavior. Simply stating 'search' is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is overly terse and lacks critical information for an agent to use effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not specify what the search returns (e.g., channel IDs, metadata). The agent is left uninformed about how to handle results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 parameters documented). The description adds no additional meaning beyond what is in the schema, failing to compensate for the undocumented 'order' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (search) and resource (YouTube channels), distinguishing it from sibling tools like search_videos and search_playlists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_channel_by_handle or get_channel_details. Missing context about appropriate queries or filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_playlistsC
Search for YouTube playlists
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| max_results | No | Maximum number of results (1-50) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description lacks any behavioral context beyond basic purpose. Does not disclose what the search returns, pagination, or any side effects. For a search tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but overly minimal. Could be restructured to include more value without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameters and no output schema, description is incomplete. Should at least hint at result format or filtering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two parameters, and description adds no additional meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Search' and resource 'YouTube playlists', distinguishing it from sibling tools like search_channels and search_videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_videos. No prerequisites, constraints, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_videosC
Search for YouTube videos with various filters
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| max_results | No | Maximum number of results (1-50) | |
| order | No | relevance | |
| published_after | No | ISO 8601 datetime (e.g., 2024-01-01T00:00:00Z) | |
| published_before | No | ISO 8601 datetime | |
| region_code | No | ISO 3166-1 alpha-2 country code (e.g., US, BR) | |
| video_duration | No | ||
| video_definition | No | ||
| video_dimension | No | ||
| video_license | No | ||
| video_type | No | ||
| channel_id | No | Filter by specific channel ID | |
| topic_id | No | Filter by Freebase topic ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavior like pagination, rate limits, authentication needs, or result limits beyond max_results. The description is silent about query behavior (e.g., partial matches, language).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is overly terse and fails to convey essential context. It earns its place but does not suffice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return structure, error handling, pagination, or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is ~62% (8/13 params have descriptions). The description adds no additional meaning beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'search' and resource 'YouTube videos', but is generic and fails to distinguish from sibling tools like search_channels or get_channel_videos. Adding filters is implied but not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as search_channels, get_channel_videos, or get_trending_videos. The sibling list shows multiple overlapping tools, but description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
11 tool updates
v0.1.0- First observed
get_channel_by_handle - First observed
get_channel_details - First observed
get_channel_videos - First observed
get_playlist_videos - First observed
get_trending_videos - First observed
get_video_categories - First observed
get_video_comments - First observed
get_video_details - First observed
search_channels - First observed
search_playlists - First observed
search_videos
TDQS
Most tools have distinct purposes, but 'get_channel_details' and 'get_channel_by_handle' overlap in retrieving channel info, differing only by input. Similarly, 'get_video_details' could be confused with results from 'search_videos', though descriptions help.
All tools use consistent snake_case with a verb_noun pattern (get_*, search_*), making the naming predictable and easy to parse for an agent.
11 tools is well-scoped for a YouTube data server, covering channels, playlists, videos, trending, comments, and search without unnecessary bloat.
The set covers major read operations for YouTube data, but misses some lifecycle actions like channel/playlist management, video updates, and comment posting. Gaps are minor for a focused retrieval server.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
YouTube MCP — wraps the YouTube Data API v3 (BYO API key)
An MCP server that gives any LLM or agent clean YouTube transcripts on demand: a single video, a whole channel, or a playlist, plus AI cleanup of auto-generated captions. API-key auth, credit-based, same backend as the public v1 API. Get a free API key with 25 free credits at youtubetranscriptdownload.com/account.
MCP server for Google Veo AI video generation
Hosted MCP for YouTube Studio: uploads, metadata, playlists, comments, analytics, captions.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn MCP server that enables interaction with the YouTube Data API, allowing users to search videos, get video and channel details, analyze trends, and fetch video transcripts.-
- AlicenseNot gradedqualityCmaintenanceStreamable HTTP MCP server for YouTube that enables video search, channel exploration, playlist browsing, and video detail retrieval via the YouTube Data API.126MIT
- FlicenseNot gradedqualityBmaintenanceMCP server for YouTube that provides tools to fetch video metadata and transcripts, enabling natural language queries about YouTube videos.2-
- FlicenseNot gradedqualityCmaintenanceMCP server for managing YouTube channels using Data API v3 and Analytics. Supports video upload, comments, playlists, and analytics via ~30 tools, with stateless OAuth authentication.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/PPiai/youtube-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server