Which integrations are available for this server?

Provides tools for searching YouTube videos, retrieving video details and transcripts, accessing channel information and videos, and managing playlists through the YouTube Data API.

How do I use YouTube MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@YouTube MCP Server search for recent machine learning tutorials" 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

by danieldoalto

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

YouTube MCP Server

A Model Context Protocol (MCP) server implementation for YouTube, enabling AI language models to interact with YouTube content through a standardized interface.

Available Tools

The server currently exposes 10 MCP tools.

Tool	Description	Required Parameters	Optional Parameters
`videos_getVideo`	Get detailed information about a YouTube video	`videoId`	`parts`
`videos_searchVideos`	Search for videos on YouTube	`query`	`maxResults`, `order`, `publishedAfter`, `publishedBefore`, `channelId`, `uniqueChannels`, `channelMinSubscribers`, `channelMaxSubscribers`, `channelLastUploadAfter`, `channelLastUploadBefore`, `creatorOnly`, `sortBy`
`transcripts_getTranscript`	Get the transcript of a YouTube video	`videoId`	`language`
`channels_getChannel`	Get information about a YouTube channel	`channelId`	None
`channels_getChannels`	Get information about multiple YouTube channels	`channelIds`	`parts`, `includeLatestUpload`
`channels_searchChannels`	Search for YouTube channels by handle, name, or query	`query`	`maxResults`, `order`, `channelType`, `minSubscribers`, `maxSubscribers`, `lastUploadAfter`, `lastUploadBefore`, `creatorOnly`, `sortBy`
`channels_findCreators`	Find creator channels from video mentions with channel-size and activity filters	`query`	`maxResults`, `order`, `videoPublishedAfter`, `videoPublishedBefore`, `channelMinSubscribers`, `channelMaxSubscribers`, `channelLastUploadAfter`, `channelLastUploadBefore`, `creatorOnly`, `sortBy`, `sampleVideosPerChannel`
`channels_listVideos`	Get videos from a specific channel	`channelId`	`maxResults`
`playlists_getPlaylist`	Get information about a YouTube playlist	`playlistId`	None
`playlists_getPlaylistItems`	Get videos in a YouTube playlist	`playlistId`	`maxResults`

Tool Parameters

`videos_getVideo`

videoId (string): The YouTube video ID.
parts (string[], optional): Specific video resource parts to retrieve.

`videos_searchVideos`

query (string): Search query.
maxResults (number, optional): Maximum number of results to return.
order (string, optional): Result ordering such as relevance or date.
publishedAfter (string, optional): Only include videos published after this ISO 8601 date.
publishedBefore (string, optional): Only include videos published before this ISO 8601 date.
channelId (string, optional): Restrict results to a specific channel.
uniqueChannels (boolean, optional): Return only one video per unique channel.
channelMinSubscribers / channelMaxSubscribers (number, optional): Filter matched videos by the subscriber band of their channel.
channelLastUploadAfter / channelLastUploadBefore (string, optional): Filter matched videos by the latest upload activity of their channel.
creatorOnly (boolean, optional): Restrict results to channels heuristically classified as creators.
sortBy (string, optional): Supports relevance, subscribers_asc, subscribers_desc, indie_priority, and recent_activity.

`transcripts_getTranscript`

videoId (string): The YouTube video ID.
language (string, optional): Transcript language code. Falls back to YOUTUBE_TRANSCRIPT_LANG or en.

`channels_getChannel`

channelId (string): The YouTube channel ID.

Responses now include:

latestVideoPublishedAt
normalizedMetadata
- includes country, defaultLanguage, joinedAt, customUrl, emailsFound, contactLinks, and creator-vs-brand heuristic fields

`channels_getChannels`

channelIds (string[]): A list of YouTube channel IDs.
includeLatestUpload (boolean, optional): Whether to include latestVideoPublishedAt. Defaults to true.

`channels_searchChannels`

query (string): Channel search query or handle.
maxResults (number, optional): Maximum number of channels to return.
order (string, optional): Result ordering such as relevance.
channelType (string, optional): Restrict the search to a channel type.
minSubscribers / maxSubscribers (number, optional): Filter channels by subscriber band.
lastUploadAfter / lastUploadBefore (string, optional): Filter channels by latest upload activity.
creatorOnly (boolean, optional): Restrict results to channels heuristically classified as creators.
sortBy (string, optional): Supports relevance, subscribers_asc, subscribers_desc, indie_priority, and recent_activity.

`channels_findCreators`

query (string): Topic, game, or mention query to discover channels from matched videos.
videoPublishedAfter / videoPublishedBefore (string, optional): Recency filters for the matched videos.
channelMinSubscribers / channelMaxSubscribers (number, optional): Subscriber band filters for returned channels.
channelLastUploadAfter / channelLastUploadBefore (string, optional): Latest-upload activity filters for returned channels.
creatorOnly (boolean, optional): Restrict results to channels heuristically classified as creators.
sortBy (string, optional): Supports relevance, subscribers_asc, subscribers_desc, indie_priority, and recent_activity.
sampleVideosPerChannel (number, optional): How many matched videos to include per returned channel.

`channels_listVideos`

channelId (string): The YouTube channel ID.
maxResults (number, optional): Maximum number of videos to return.

`playlists_getPlaylist`

playlistId (string): The YouTube playlist ID.

`playlists_getPlaylistItems`

playlistId (string): The YouTube playlist ID.
maxResults (number, optional): Maximum number of playlist items to return.

Related MCP server: YouTube MCP Server

Installation

Quick Setup for Claude Desktop

Install the package:

npm install -g zubeid-youtube-mcp-server

Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "zubeid-youtube-mcp-server": {
      "command": "zubeid-youtube-mcp-server",
      "env": {
        "YOUTUBE_API_KEY": "your_primary_youtube_api_key",
        "YOUTUBE_API_KEY2": "your_secondary_youtube_api_key",
        "YOUTUBE_API_KEY3": "your_tertiary_youtube_api_key"
      }
    }
  }
}

Alternative: Using NPX (No Installation Required)

Add this to your Claude Desktop configuration:

{
  "mcpServers": {
    "youtube": {
      "command": "npx",
      "args": ["-y", "zubeid-youtube-mcp-server"],
      "env": {
        "YOUTUBE_API_KEY": "your_primary_youtube_api_key",
        "YOUTUBE_API_KEY2": "your_secondary_youtube_api_key",
        "YOUTUBE_API_KEY3": "your_tertiary_youtube_api_key"
      }
    }
  }
}

Installing via Smithery

To install YouTube MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @ZubeidHendricks/youtube --client claude

Configuration

Set the following environment variables:

YOUTUBE_API_KEY: Primary YouTube Data API key
YOUTUBE_API_KEY2: Secondary fallback API key
YOUTUBE_API_KEY3: Third fallback API key
YOUTUBE_TRANSCRIPT_LANG: Default language for transcripts (optional, defaults to 'en')

At least one of YOUTUBE_API_KEY, YOUTUBE_API_KEY2, or YOUTUBE_API_KEY3 must be set. When a request fails because a key has exhausted its quota, the server retries the same request with the next configured key.

Using with VS Code

For one-click installation, click one of the install buttons below:

Install with NPX in VS Code Install with NPX in VS Code Insiders

Manual Installation

If you prefer manual installation, first check the install buttons at the top of this section. Otherwise, follow these steps:

Add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open User Settings (JSON).

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "apiKey",
        "description": "YouTube API Key",
        "password": true
      }
    ],
    "servers": {
      "youtube": {
        "command": "npx",
        "args": ["-y", "zubeid-youtube-mcp-server"],
        "env": {
          "YOUTUBE_API_KEY": "${input:apiKey}"
        }
      }
    }
  }
}

Optionally, you can add it to a file called .vscode/mcp.json in your workspace:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "apiKey",
      "description": "YouTube API Key",
      "password": true
    }
  ],
  "servers": {
    "youtube": {
      "command": "npx",
      "args": ["-y", "zubeid-youtube-mcp-server"],
      "env": {
        "YOUTUBE_API_KEY": "${input:apiKey}"
      }
    }
  }
}

Development

# Install dependencies
npm install

# Build
npm run build

# Start the server (requires at least one configured YouTube API key)
npm start

# Development mode with auto-rebuild
npm run dev

Docker

The included Docker image starts the server over HTTP by default.

Default transport: http
Default endpoint: http://localhost:8088/mcp
Readiness endpoint: http://localhost:8088/ready
Default mode: stateless

The Docker build copies .env into the runtime image and the server loads it automatically on startup. That means the container can run without passing API credentials at docker run time, as long as .env was present during docker build.

docker build -t youtube-mcp-server .
docker run --rm -p 8088:8088 youtube-mcp-server

The container defaults to:

MCP_TRANSPORT=http
MCP_HOST=0.0.0.0
MCP_PORT=8088
MCP_STATELESS=true

Contributing

See CONTRIBUTING.md for information about contributing to this repository.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

10 tools

channels_findCreatorsB

Find creator channels from video mentions with subscriber band and recent activity filters in one call

ParametersJSON Schema

Name	Required	Description
`order`	No	Search ordering such as relevance or date
`query`	Yes	Search query such as a game name or topic mention
`sortBy`	No	Optional ranking mode such as relevance, indie_priority, subscribers_asc, subscribers_desc, or recent_activity
`maxResults`	No	Maximum number of video matches to scan before channel enrichment
`creatorOnly`	No	Only include channels heuristically classified as creators
`videoPublishedAfter`	No	Only include matched videos published after this ISO 8601 date
`videoPublishedBefore`	No	Only include matched videos published before this ISO 8601 date
`channelMaxSubscribers`	No	Maximum subscriber count for returned creator channels
`channelMinSubscribers`	No	Minimum subscriber count for returned creator channels
`channelLastUploadAfter`	No	Only include channels whose latest upload is after this ISO 8601 date
`sampleVideosPerChannel`	No	How many matched video samples to include per returned channel
`channelLastUploadBefore`	No	Only include channels whose latest upload is before this ISO 8601 date

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It describes the filtering capabilities but does not state that the operation is read-only, what the output format is (e.g., list of channel objects), whether it has rate limits, or any side effects. This is a significant gap for a tool with 12 parameters.

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 covers the core purpose. It is front-loaded and efficient, but could be slightly more structured to separate the main action from filter details. No unnecessary words.

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 12 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the return type, pagination behavior, or how 'from video mentions' works algorithmically. The minimal description leaves many questions for the agent.

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 input schema already documents all 12 parameters. The description provides a high-level summary ('subscriber band and recent activity filters') but does not add additional meaning beyond what the schema offers. 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?

The description clearly states the tool finds creator channels from video mentions, with filters for subscriber count and activity. It uses a specific verb 'find' and resource 'creator channels', and the phrase 'from video mentions' distinguishes it from sibling tool channels_searchChannels which likely searches by name or other criteria.

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 implies usage through its specialized functionality, mentioning 'in one call' which suggests efficiency. However, it does not explicitly state when to use this tool versus alternatives like channels_searchChannels, nor does it give guidance on when not to use it. The context is clear but lacks explicit directions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

channels_getChannelC

Get information about a YouTube channel

ParametersJSON Schema

Name	Required	Description	Default
`channelId`	Yes	The YouTube channel ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description bears full responsibility for behavioral disclosure. It only states 'Get information' without specifying what information is returned, any required permissions, or side effects. This is insufficient for an agent to understand the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no redundancy. While it could be expanded to include more details, it is not overly verbose for a simple tool.

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 (1 param, no output schema, no annotations), the description is too sparse. It fails to clarify what 'information' is returned, how it differs from similar tools, or any usage constraints like authentication requirements.

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 one parameter with a description ('The YouTube channel ID'), achieving 100% schema description coverage. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Get information' and the resource 'a YouTube channel'. It distinguishes from siblings like channels_getChannels (plural) and channels_searchChannels by the singular focus, but does not explicitly contrast them.

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 channels_getChannels or channels_searchChannels. There is no mention of prerequisites, limitations, or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

channels_getChannelsC

Get information about multiple YouTube channels

ParametersJSON Schema

Name	Required	Description
`parts`	No	Parts of the channel resource to retrieve
`channelIds`	Yes	A list of YouTube channel IDs
`includeLatestUpload`	No	Whether to include the latestVideoPublishedAt enrichment field

TDQS

C2.8/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 for behavioral disclosure. It only states the basic operation, omitting authentication needs, rate limits, return value structure, or any side effects. This is insufficient for an agent to use safely.

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 concise sentence, but it sacrifices completeness. It is front-loaded and to the point, but could afford a few more sentences to improve clarity without becoming 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 the tool has 3 parameters, no output schema, and no annotations, the description should provide more context about return values, usage limits, or parameter constraints. It is currently too brief to be fully helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. No extra context on parts, channel IDs format, or includeLatestUpload implications.

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 it retrieves information for multiple YouTube channels, distinguishing it from the sibling tool channels_getChannel which handles a single channel. However, it could be more specific about what 'information' encompasses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like channels_getChannel for single channels or channels_searchChannels for discovery. The agent receives no contextual help for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

channels_listVideosC

Get videos from a specific channel

ParametersJSON Schema

Name	Required	Description	Default
`channelId`	Yes	The YouTube channel ID
`maxResults`	No	Maximum number of results to return

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided and the description lacks behavioral details such as pagination, rate limits, or whether it returns all videos or only public.

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 is concise and front-loaded, but may be too brief given the lack of other details.

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?

Without output schema or annotations, the description should provide more context about what is returned or any default behaviors, but it does not.

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%, so parameters are fully described in schema. Description adds no additional meaning beyond what is already in 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 it gets videos from a specific channel, but does not differentiate from sibling tools like videos_searchVideos or channels_searchChannels.

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; no context on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

channels_searchChannelsC

Search for YouTube channels by handle, name, or query

ParametersJSON Schema

Name	Required	Description
`order`	No	Sort order for results, such as relevance
`query`	Yes	Channel search query or handle
`sortBy`	No	Optional ranking mode such as relevance, indie_priority, subscribers_asc, subscribers_desc, or recent_activity
`maxResults`	No	Maximum number of results to return
`channelType`	No	Restrict to channel type such as any or show
`creatorOnly`	No	Only include channels heuristically classified as creators
`maxSubscribers`	No	Maximum subscriber count for returned channels
`minSubscribers`	No	Minimum subscriber count for returned channels
`lastUploadAfter`	No	Only include channels whose latest upload is after this ISO 8601 date
`lastUploadBefore`	No	Only include channels whose latest upload is before this ISO 8601 date

TDQS

C2.9/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 'Search...', omitting behavioral traits like rate limits, authentication needs, result structure, or potential side effects. The agent gets no insight beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently communicates the tool's purpose. It is front-loaded with 'Search for YouTube channels' but could benefit from slightly more detail 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 the complexity of 10 parameters and no output schema or annotations, the description is insufficient. It does not explain what the tool returns or how to interpret results, leaving gaps for a search tool with many filters.

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 additional meaning beyond summarizing the schema; it does not clarify parameter usage or provide examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the resource 'YouTube channels' with methods 'by handle, name, or query'. However, it does not differentiate from sibling tools like channels_findCreators or channels_getChannel, which could lead to ambiguity.

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. There is no mention of context, prerequisites, or exclusions, leaving the agent without decision-making support.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

playlists_getPlaylistC

Get information about a YouTube playlist

ParametersJSON Schema

Name	Required	Description	Default
`playlistId`	Yes	The YouTube playlist ID

TDQS

C2.9/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 does not mention auth requirements, rate limits, error handling, or what happens if the playlist is private or deleted.

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 is efficient and front-loaded. It is appropriately sized for a simple tool, though slightly more detail would be justified.

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 low complexity (1 param, no output schema), the description is minimally adequate. However, it fails to specify what 'information' includes (e.g., metadata, statistics, thumbnails).

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 baseline is 3. Description adds no additional meaning beyond what the schema already provides for the single 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?

Description uses specific verb 'Get' and resource 'YouTube playlist', making the main action and object clear. However, it does not distinguish from sibling tools like playlists_getPlaylistItems or videos_getVideo.

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 playlists_getPlaylistItems or channels_getChannels. No context on prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

playlists_getPlaylistItemsB

Get videos in a YouTube playlist

ParametersJSON Schema

Name	Required	Description	Default
`maxResults`	No	Maximum number of results to return
`playlistId`	Yes	The YouTube playlist ID

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, yet the description only states 'get' without disclosing behaviors like pagination, rate limits, authentication needs, or default parameter values.

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 lacks structure; no front-loading of key constraints or examples. Could be expanded slightly for clarity.

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?

For a simple read tool with 2 parameters and no output schema, the description is minimal. Missing details like required parameter implication (playlistId is required in schema but not stated in description) and default for maxResults. Adequate but not complete.

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 both maxResults and playlistId documented. The description adds no additional semantic meaning beyond the schema, so baseline 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?

The description 'Get videos in a YouTube playlist' clearly states the action (get), resource (videos), and context (playlist). It distinguishes from siblings like playlists_getPlaylist and videos_getVideo.

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 playlists_getPlaylist or videos_searchVideos. Lacks context for preferred use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

transcripts_getTranscriptC

Get the transcript of a YouTube video

ParametersJSON Schema

Name	Required	Description	Default
`videoId`	Yes	The YouTube video ID
`language`	No	Language code for the transcript

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden for behavioral disclosure. It does not mention authentication needs, rate limits, or behavior when a transcript is unavailable. This is insufficient for a tool that likely has hidden constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action, earning full marks for 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?

The description is too minimal for a tool with no output schema. It fails to explain the return format, pagination, or other contextual details that an agent would need to handle the response correctly.

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 parameters are already well-documented in the schema. The description adds no extra meaning beyond what the schema provides, placing it at the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'transcript of a YouTube video', distinguishing it from sibling tools that deal with channels, playlists, and videos. However, it lacks specificity about the transcript format or any limitations.

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. There are no other transcript tools among siblings, but explicit context about prerequisites or exclusions is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

videos_getVideoB

Get detailed information about a YouTube video

ParametersJSON Schema

Name	Required	Description	Default
`parts`	No	Parts of the video to retrieve
`videoId`	Yes	The YouTube video ID

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior, but it only says 'Get detailed information' without mentioning that this is a read-only operation, the source API (YouTube Data API v3), or any limitations such as quota costs or required authentication.

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 is concise and front-loaded, but it sacrifices completeness for 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 two parameters and no output schema or annotations, the description is incomplete. It fails to explain the 'parts' parameter, expected output structure, or any preconditions, leaving an AI agent underinformed.

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 both parameters described, so the description adds no extra meaning. However, the schema descriptions are vague (e.g., 'Parts of the video to retrieve'), and the tool description does not clarify possible values for 'parts', missing an opportunity to add value.

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 'Get detailed information about a YouTube video' uses a specific verb ('Get') and resource ('YouTube video'), clearly distinguishing it from sibling tools like videos_searchVideos (which searches) and channels_getChannel (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 is provided on when to use this tool versus alternatives such as videos_searchVideos or channels_getChannel. The description omits context like 'use for fetching a specific video by ID'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

videos_searchVideosC

Search for videos on YouTube

ParametersJSON Schema

Name	Required	Description
`order`	No	Sort order for results, such as relevance or date
`query`	Yes	Search query
`sortBy`	No	Optional ranking mode such as relevance, indie_priority, subscribers_asc, subscribers_desc, or recent_activity
`channelId`	No	Restrict results to a specific channel ID
`maxResults`	No	Maximum number of results to return
`creatorOnly`	No	Only include channels heuristically classified as creators
`publishedAfter`	No	Only include videos published after this ISO 8601 date
`uniqueChannels`	No	Return only one matched video per unique channel
`publishedBefore`	No	Only include videos published before this ISO 8601 date
`channelMaxSubscribers`	No	Maximum subscriber count for the matched video channel
`channelMinSubscribers`	No	Minimum subscriber count for the matched video channel
`channelLastUploadAfter`	No	Only include videos whose channel latest upload is after this ISO 8601 date
`channelLastUploadBefore`	No	Only include videos whose channel latest upload is before this ISO 8601 date

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description must disclose behavioral traits. It only says 'Search for videos,' omitting any details about rate limits, pagination, return format, or side effects. This is insufficient for an agent to anticipate behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is too brief for a tool with 13 parameters. While concise, it is under-specified and does not earn its place; it should include more context.

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's complexity (13 parameters, no output schema), the description lacks completeness. It does not explain return values, default behaviors, or interaction effects between parameters, leaving the agent underinformed.

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% description coverage, so the schema itself documents each parameter. The tool description adds no additional meaning beyond the schema, making the baseline score of 3 appropriate.

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 a specific verb ('Search') and resource ('videos on YouTube'), making the tool's purpose immediately understandable. However, it lacks any differentiation from potential sibling tools (none provided) and is somewhat generic.

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, when not to use it, or any alternatives. With no sibling tools mentioned, the description could at least imply typical search scenarios, but it does not.

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.

10 tool updatesv1.0.0Jul 9, 2026
- First observedchannels_findCreators
- First observedchannels_getChannel
- First observedchannels_getChannels
- First observedchannels_listVideos
- First observedchannels_searchChannels
- First observedplaylists_getPlaylist
- First observedplaylists_getPlaylistItems
- First observedtranscripts_getTranscript
- First observedvideos_getVideo
- First observedvideos_searchVideos

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Scored 2026-07-09 18:25 across 10 tools

Disambiguation5/5

Each tool targets a distinct resource and action: channels (find creators, get single/multiple, list videos, search), playlists (get info, get items), transcripts (get transcript), videos (get single, search). No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow a consistent 'resource_action' pattern in snake_case (e.g., channels_searchChannels, transcripts_getTranscript). No mixed conventions or vague verbs.

Tool Count5/5

10 tools is well-scoped for a YouTube data server. Each tool serves a clear purpose, covering channels, playlists, videos, and transcripts without being excessive or too minimal.

Completeness4/5

Core read/search/list operations are covered for channels, playlists, videos, and transcripts. Minor gaps exist (e.g., no playlist search, no single video by ID with transcript combined), but the set is functional for common YouTube data retrieval tasks.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
YouTube Transcript Downloader A
com.youtubetranscriptdownload
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.
Entertainment & Media Research & Data Web Scraping
42
BulkTranscripts YouTube AOAuth
co.bulktranscripts
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents. No signup.
Entertainment & Media Search
1
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

YouTube Translate MCP
Entertainment & Media Language Translation Text Summarization
brianshin22
A
license
A
quality
D
maintenance
A Model Context Protocol server that enables access to YouTube video content through transcripts, translations, summaries, and subtitle generation in various languages.
Updated a year ago (2025-03-17 04:34 UTC)
5
5
MIT
YouTube MCP Server
Entertainment & Media RAG Systems Web Scraping
IA-Programming
A
license
Not graded
quality
F
maintenance
A Model Context Protocol server that enables searching YouTube videos, retrieving and storing transcripts, and performing semantic search over video content without using the official YouTube API.
Updated a year ago (2025-03-26 04:41 UTC)
34
MIT
YouTube MCP Server
Entertainment & Media Search Content Management Systems
coyaSONG
A
license
B
quality
A
maintenance
A server that enables interaction with YouTube data through the Model Context Protocol, allowing users to search videos, retrieve detailed information about videos/channels, and fetch comments.
Updated 7 days ago (2026-09-03 11:26 UTC)
12
136
19
MIT
YouTube MCP Server
Search Multimedia Processing Entertainment & Media
dannySubsense
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI assistants to access YouTube data in real-time, with capabilities for searching videos, analyzing channels, retrieving video details, and extracting transcripts.
Updated a year ago (2025-07-06 18:51 UTC)
13
MIT