Реализация сервера Model Context Protocol (MCP) для YouTube, позволяющая языковым моделям ИИ взаимодействовать с контентом YouTube через стандартизированный интерфейс.
Сайт: zubeidhendricks.github.io/youtube-mcp-server
Сервер в настоящее время предоставляет 10 инструментов MCP.
Инструмент | Описание | Обязательные параметры | Необязательные параметры |
| Получить подробную информацию о видео на YouTube |
|
|
| Искать видео на YouTube |
|
|
| Получить транскрипт видео на YouTube |
|
|
| Получить информацию о канале YouTube |
| Нет |
| Получить информацию о нескольких каналах YouTube |
|
|
| Искать каналы YouTube по handle, имени или запросу |
|
|
| Находить каналы создателей по упоминаниям в видео с фильтрами по размеру и активности канала |
|
|
| Получить видео с конкретного канала |
|
|
| Получить информацию о плейлисте YouTube |
| Нет |
| Получить видео в плейлисте YouTube |
|
|
videos_getVideovideoId (string): Идентификатор видео на YouTube.
parts (string[], необязательный): Конкретные части ресурса видео для получения.
videos_searchVideosquery (string): Поисковый запрос.
maxResults (number, необязательный): Максимальное количество результатов для возврата.
order (string, необязательный): Порядок результатов, например relevance или date.
publishedAfter (string, необязательный): Включать только видео, опубликованные после этой даты ISO 8601.
publishedBefore (string, необязательный): Включать только видео, опубликованные до этой даты ISO 8601.
channelId (string, необязательный): Ограничить результаты конкретным каналом.
uniqueChannels (boolean, необязательный): Возвращать только одно видео для каждого уникального канала.
channelMinSubscribers / channelMaxSubscribers (number, необязательный): Фильтровать подходящие видео по диапазону подписчиков их канала.
channelLastUploadAfter / channelLastUploadBefore (string, необязательный): Фильтровать подходящие видео по активности последних загрузок их канала.
creatorOnly (boolean, необязательный): Ограничить результаты каналами, эвристически классифицированными как создатели.
sortBy (string, необязательный): Поддерживает relevance, subscribers_asc, subscribers_desc, indie_priority и recent_activity.
transcripts_getTranscriptvideoId (string): Идентификатор видео на YouTube.
language (string, необязательный): Код языка транскрипта. При отсутствии используется YOUTUBE_TRANSCRIPT_LANG или en.
channels_getChannelchannelId (string): Идентификатор канала YouTube.
Ответы теперь включают:
latestVideoPublishedAt
normalizedMetadata
включает country, defaultLanguage, joinedAt, customUrl, emailsFound, contactLinks и эвристические поля, отличающие создателей от брендов
channels_getChannelschannelIds (string[]): Список идентификаторов каналов YouTube.
includeLatestUpload (boolean, необязательный): Включать ли latestVideoPublishedAt. По умолчанию — true.
channels_searchChannelsquery (string): Поисковый запрос по каналу или handle.
maxResults (number, необязательный): Максимальное количество каналов для возврата.
order (string, необязательный): Порядок результатов, например relevance.
channelType (string, необязательный): Ограничить поиск типом канала.
minSubscribers / maxSubscribers (number, необязательный): Фильтровать каналы по диапазону подписчиков.
lastUploadAfter / lastUploadBefore (string, необязательный): Фильтровать каналы по активности последних загрузок.
creatorOnly (boolean, необязательный): Ограничить результаты каналами, эвристически классифицированными как создатели.
sortBy (string, необязательный): Поддерживает relevance, subscribers_asc, subscribers_desc, indie_priority и recent_activity.
channels_findCreatorsquery (string): Запрос по теме, игре или упоминанию для поиска каналов по подходящим видео.
videoPublishedAfter / videoPublishedBefore (string, необязательный): Фильтры по давности публикации для подходящих видео.
channelMinSubscribers / channelMaxSubscribers (number, необязательный): Фильтры по диапазону подписчиков для возвращаемых каналов.
channelLastUploadAfter / channelLastUploadBefore (string, необязательный): Фильтры по активности последних загрузок для возвращаемых каналов.
creatorOnly (boolean, необязательный): Ограничить результаты каналами, эвристически классифицированными как создатели.
sortBy (string, необязательный): Поддерживает relevance, subscribers_asc, subscribers_desc, indie_priority и recent_activity.
sampleVideosPerChannel (number, необязательный): Сколько подходящих видео включать для каждого возвращаемого канала.
channels_listVideoschannelId (string): Идентификатор канала YouTube.
maxResults (number, необязательный): Максимальное количество видео для возврата.
playlists_getPlaylistplaylistId (string): Идентификатор плейлиста YouTube.
playlists_getPlaylistItemsplaylistId (string): Идентификатор плейлиста YouTube.
maxResults (number, необязательный): Максимальное количество элементов плейлиста для возврата.
Related MCP server: mcp-server-youtube
Установите пакет:
npm install -g zubeid-youtube-mcp-serverДобавьте в конфигурацию Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json в macOS или %APPDATA%\Claude\claude_desktop_config.json в 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"
}
}
}
}Добавьте это в конфигурацию Claude Desktop:
{
"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"
}
}
}
}Чтобы автоматически установить YouTube MCP Server для Claude Desktop через Smithery:
npx -y @smithery/cli install @ZubeidHendricks/youtube --client claudeЗадайте следующие переменные окружения:
YOUTUBE_API_KEY: основной ключ YouTube Data API
YOUTUBE_API_KEY2: дополнительный резервный ключ API
YOUTUBE_API_KEY3: третий резервный ключ API
YOUTUBE_TRANSCRIPT_LANG: язык транскриптов по умолчанию (необязательно, по умолчанию — 'en')
Должен быть задан хотя бы один из ключей YOUTUBE_API_KEY, YOUTUBE_API_KEY2 или YOUTUBE_API_KEY3. Если запрос завершается ошибкой из-за исчерпания квоты ключа, сервер повторяет тот же запрос со следующим настроенным ключом.
Для установки в один клик нажмите одну из кнопок установки ниже:
Если вы предпочитаете установку вручную, сначала посмотрите на кнопки установки в верхней части этого раздела. В противном случае выполните следующие шаги:
Добавьте следующий блок JSON в файл User Settings (JSON) в VS Code. Для этого нажмите Ctrl + Shift + P и введите 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}"
}
}
}
}
}При желании вы можете добавить его в файл .vscode/mcp.json в вашем рабочем пространстве:
{
"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}"
}
}
}
}# 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 по умолчанию запускает сервер через HTTP.
Транспорт по умолчанию: http
Конечная точка по умолчанию: http://localhost:8088/mcp
Конечная точка готовности: http://localhost:8088/ready
Режим по умолчанию: без состояния
Сборка Docker копирует .env в образ времени выполнения, и сервер автоматически загружает его при запуске. Это означает, что контейнер может работать без передачи учётных данных API во время docker run, если .env присутствовал во время docker build.
docker build -t youtube-mcp-server .
docker run --rm -p 8088:8088 youtube-mcp-serverКонтейнер по умолчанию использует:
MCP_TRANSPORT=http
MCP_HOST=0.0.0.0
MCP_PORT=8088
MCP_STATELESS=trueИнформацию о том, как внести вклад в этот репозиторий, см. в файле CONTRIBUTING.md.
Этот проект лицензирован по лицензии MIT — подробности см. в файле LICENSE.
Find creator channels from video mentions with subscriber band and recent activity filters in one call
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Get information about a YouTube channel
| Name | Required | Description | Default |
|---|---|---|---|
| channelId | Yes | The YouTube channel ID |
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.
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.
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.
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.
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.
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.
Get information about multiple YouTube channels
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Get videos from a specific channel
| Name | Required | Description | Default |
|---|---|---|---|
| channelId | Yes | The YouTube channel ID | |
| maxResults | No | Maximum number of results to return |
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.
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.
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.
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.
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.
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.
Search for YouTube channels by handle, name, or query
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Get information about a YouTube playlist
| Name | Required | Description | Default |
|---|---|---|---|
| playlistId | Yes | The YouTube playlist ID |
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.
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.
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.
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.
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.
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.
Get videos in a YouTube playlist
| Name | Required | Description | Default |
|---|---|---|---|
| maxResults | No | Maximum number of results to return | |
| playlistId | Yes | The YouTube playlist ID |
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.
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.
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.
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.
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.
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.
Get the transcript of a YouTube video
| Name | Required | Description | Default |
|---|---|---|---|
| videoId | Yes | The YouTube video ID | |
| language | No | Language code for the transcript |
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.
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.
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.
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.
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.
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.
Get detailed information about a YouTube video
| Name | Required | Description | Default |
|---|---|---|---|
| parts | No | Parts of the video to retrieve | |
| videoId | Yes | The YouTube video ID |
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.
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.
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.
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.
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.
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.
Search for videos on YouTube
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.2channels_findCreatorschannels_getChannelchannels_getChannelschannels_listVideoschannels_searchChannelsplaylists_getPlaylistplaylists_getPlaylistItemstranscripts_getTranscriptvideos_getVideovideos_searchVideosScored across 10 tools
Most tools have clearly distinct purposes: getVideo, searchVideos, getTranscript, getChannel, etc. However, channels_getChannels and channels_findCreators both retrieve multiple channels, which could cause confusion, though findCreators has specific filters. Overlap is limited and descriptions help differentiate.
All tool names follow a consistent pattern of resource_category + verb_noun (e.g., videos_getVideo, playlists_getPlaylistItems, channels_getChannel). The pattern is predictable and uniform across all tools.
With 10 tools, the set is well-scoped for YouTube interactions, covering core entities like videos, playlists, channels, and transcripts without excessive redundancy. Each tool appears to earn its place.
The surface covers key read operations for videos, playlists, channels, and transcripts. However, there is no tool for searching playlists or retrieving video comments, which could be considered gaps, but they are minor for most agent use cases.
Search YouTube videos, read transcripts and get public video information in your AI assistant.
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents.
YouTube search, whole channels, video stats, comments and full transcripts with timestamps.
