Skip to main content
Glama
PPiai

youtube-mcp

by PPiai

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 .env

Variable

Default

Description

YOUTUBE_API_KEY

Required. YouTube Data API v3 key

MCP_TRANSPORT

streamable-http

streamable-http (remote service) or stdio (local)

HOST

0.0.0.0

Bind host (HTTP mode)

PORT

8000

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/

POST

MCP streamable-HTTP endpoint (JSON-RPC)

/health

GET

Health check — returns 200 {"status":"ok"}

MCP_TRANSPORT=streamable-http PORT=8000 youtube-mcp
# MCP endpoint: http://localhost:8000/mcp/
# Health:       http://localhost:8000/health

Note — trailing slash. The MCP endpoint is mounted at /mcp, so POST /mcp returns a 307 redirect to /mcp/. Always point clients at /mcp/ (with the trailing slash) to avoid clients that don't follow redirects on POST.

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: 60

Deploy (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-mcp

On 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

Search videos with filters

search_channels

Search channels

get_video_details

Get detailed video info

get_channel_details

Get detailed channel info

get_trending_videos

Get trending videos by region

get_video_categories

Get video categories

get_channel_videos

Get channel's recent videos

get_playlist_videos

Get playlist videos

search_playlists

Search playlists

get_video_comments

Get video comments

get_channel_by_handle

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/health

No automated test suite yet — pytest is wired up in the dev extra but there are no tests under a tests/ directory. Contributions welcome.

License

MIT

Available Tools

11 tools
get_channel_by_handleC

Get channel details by handle (@username)

ParametersJSON Schema
NameRequiredDescriptionDefault
handleYesYouTube handle (e.g., @MrBeast or MrBeast)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
channel_idsYesList of YouTube channel IDs

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
channel_idYesYouTube channel ID
max_resultsNoMaximum number of results (1-50)
orderNodate
published_afterNoISO 8601 datetime filter

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
playlist_idYesYouTube playlist ID
max_resultsNoMaximum number of results (1-50)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

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, 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_video_categoriesB

Get video categories for a region

ParametersJSON Schema
NameRequiredDescriptionDefault
region_codeYesISO 3166-1 alpha-2 country codeUS

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
video_idYesYouTube video ID
max_resultsNoMaximum number of results (1-100)
orderNorelevance

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

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, 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

ParametersJSON Schema
NameRequiredDescriptionDefault
video_idsYesList of YouTube video IDs

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description 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.

Purpose4/5

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.

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 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

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query
max_resultsNoMaximum number of results (1-50)
orderNorelevance

TDQS

C2.4/5.0
Behavior1/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query
max_resultsNoMaximum number of results (1-50)

TDQS

C2.8/5.0
Behavior1/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query
max_resultsNoMaximum number of results (1-50)
orderNorelevance
published_afterNoISO 8601 datetime (e.g., 2024-01-01T00:00:00Z)
published_beforeNoISO 8601 datetime
region_codeNoISO 3166-1 alpha-2 country code (e.g., US, BR)
video_durationNo
video_definitionNo
video_dimensionNo
video_licenseNo
video_typeNo
channel_idNoFilter by specific channel ID
topic_idNoFilter by Freebase topic ID

TDQS

C2.5/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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.

  1. 11 tool updatesv0.1.0
    • First observedget_channel_by_handle
    • First observedget_channel_details
    • First observedget_channel_videos
    • First observedget_playlist_videos
    • First observedget_trending_videos
    • First observedget_video_categories
    • First observedget_video_comments
    • First observedget_video_details
    • First observedsearch_channels
    • First observedsearch_playlists
    • First observedsearch_videos

TDQS

B3.2/5.0
Disambiguation4/5

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.

Naming Consistency5/5

All tools use consistent snake_case with a verb_noun pattern (get_*, search_*), making the naming predictable and easy to parse for an agent.

Tool Count5/5

11 tools is well-scoped for a YouTube data server, covering channels, playlists, videos, trending, comments, and search without unnecessary bloat.

Completeness4/5

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

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    An 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.
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Streamable HTTP MCP server for YouTube that enables video search, channel exploration, playlist browsing, and video detail retrieval via the YouTube Data API.
    12
    6
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    MCP 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

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