YouTube MCP Server
YouTube MCP Server
Размещённый сервер Model Context Protocol (MCP), который даёт Claude, Cursor, Windsurf и любому другому MCP-клиенту четыре инструмента YouTube только для чтения. Поиск по YouTube, чтение данных видео и каналов, получение транскриптов — без проекта Google Cloud и без ключа YouTube Data API.
https://mcp.hasdata.com/api/mcp?apis=youtube
Содержание
Related MCP server: YouTube MCP Server
Что вам нужно
MCP-клиент, который поддерживает streamable HTTP с пользовательскими заголовками. Ключ API HasData из панели управления — создаётся бесплатно. Больше ничего. Это удалённый сервер. Не нужно устанавливать пакет, запускать контейнер или иметь учётную запись Google.
Быстрый старт
URL сервера одинаков для всех клиентов. Мы используем его напрямую в Claude Code и Claude Desktop. Остальные блоки следуют собственному документированному формату каждого клиента для удалённого сервера.
Поле | Значение |
URL |
|
Транспорт | HTTP, streamable |
Заголовок авторизации |
|
Клиенты с поддержкой OAuth могут добавить тот же URL как коннектор и войти, не помещая ключ в файл конфигурации.
claude mcp add --transport http youtube "https://mcp.hasdata.com/api/mcp?apis=youtube" \
--header "x-api-key: HASDATA_API_KEY"Настройки, затем Connectors, затем Add custom connector, затем вставьте https://mcp.hasdata.com/api/mcp?apis=youtube и войдите.
Для пути через файл конфигурации: Claude Desktop загружает только локальные (stdio) серверы, поэтому удалённый сервер доступен через мост mcp-remote, для которого нужен Node. Добавьте это в claude_desktop_config.json:
{
"mcpServers": {
"youtube": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.hasdata.com/api/mcp?apis=youtube",
"--header",
"x-api-key:HASDATA_API_KEY"
]
}
}
}Значение x-api-key: не содержит пробела после двоеточия. Claude Desktop передаёт аргумент без оболочки, и пробел разделяет заголовок.
~/.cursor/mcp.json для всех проектов или .cursor/mcp.json для одного:
{
"mcpServers": {
"youtube": {
"url": "https://mcp.hasdata.com/api/mcp?apis=youtube",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf называет поле serverUrl, а не url:
{
"mcpServers": {
"youtube": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=youtube",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}{
"mcpServers": {
"youtube": {
"url": "https://mcp.hasdata.com/api/mcp?apis=youtube",
"type": "streamableHttp",
"headers": { "x-api-key": "HASDATA_API_KEY" },
"disabled": false
}
}
}.vscode/mcp.json в рабочей области:
{
"servers": {
"youtube": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=youtube",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codex/config.toml:
[mcp_servers.youtube]
url = "https://mcp.hasdata.com/api/mcp?apis=youtube"
[mcp_servers.youtube.headers]
"x-api-key" = "HASDATA_API_KEY"~/.gemini/settings.json:
{
"mcpServers": {
"youtube": {
"httpUrl": "https://mcp.hasdata.com/api/mcp?apis=youtube",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}Примеры запросов
Запросы, а не код. Вставьте один — и агент сам выберет инструмент. Каждый помечен количеством вызовов, потому что в MCP модель решает, сколько вызовов делать, и каждый успешный вызов стоит 10 кредитов.
Найдите десять самых просматриваемых видео о Model Context Protocol за последний месяц, затем получите транскрипт самого популярного и приведите три утверждения, которые в нём делаются о вызове инструментов.
Два вызова, 20 кредитов.
Возьмите канал @GoogleDevelopers. Перечислите вкладки, которые он публикует, затем обобщите последние пять загрузок и скажите, какие темы повторяются.
Два вызова, 20 кредитов. Чтение вкладки, которую вы ещё не видели, требует второго вызова, потому что список вкладок приходит в первом ответе.
Возьмите этот id видео: dQw4w9WgXcQ. Получите его статистику, затем проверьте, какие из связанных видео с того же канала.
Один вызов, 10 кредитов. Связанные видео приходят в том же ответе.
Найдите на YouTube «web scraping tutorial», отсортированные по дате загрузки, только видео короче четырёх минут, и дайте названия глав каждого результата, где они есть.
Один вызов, 10 кредитов.
Получите немецкий транскрипт этого видео, если он существует, и скажите, на каких языках оно доступно.
Один вызов, 10 кредитов.
Поиск принимает собственные токены фильтров YouTube, и агент сужает выбор по длительности, дате загрузки и типу контента без постобработки. Транскрипты приходят вместе со списком доступных языковых дорожек, что позволяет агенту выбрать нужный без угадывания.
Пагинация стоит один вызов за каждый шаг. Исследовательский запрос, который ищет, листает дважды, а затем получает три транскрипта, — это шесть вызовов и 60 кредитов. Пробный период проходит дальше на узких вопросах, чем на открытых обходах.
Инструменты
Четыре инструмента, все только для чтения. Примеры ниже урезаны из реальных вызовов, и числа в них меняются по мере обновления YouTube. Читайте их как формы. Каждое имя инструмента ведёт на справочник конечной точки, где приведён полный список полей.
Примеры — это полезная нагрузка, а не весь ответ. Результат tools/call содержит один текстовый блок, и этот текст сам является JSON, содержащим url, status, text и json, с данными скрейпинга под json. Из сырого JSON-RPC ответа путь — result.content[0].text, затем разбор, затем .json. Чат-клиент разворачивает это за вас, а код, обращающийся к конечной точке напрямую, — нет.
Получить результаты поиска YouTube
hasdata_youtube_search_getYoutubeSearchResults
Ищет на YouTube и возвращает всю страницу результатов, разделённую по типу результата.
Параметр | Тип | Обязательный | Примечания |
| string | да | Свободный текстовый запрос, точно как ввёл бы пользователь |
| string |
| |
| string | Окно загрузки относительно текущего момента | |
| string | Корзина длительности, например | |
| string | Ограничение одним типом контента | |
| array | Флаги функций, комбинируемые | |
| string | Сырой токен | |
| string |
| |
| string | Двухбуквенные коды страны и языка, а также устройство |
Страница результатов разбита на videoResults, shortsResults, inlineShortsResults, playlistResults, channelResults и shelves, с платными размещениями в adsResults и sponsoredResults. Какие блоки появятся, зависит от запроса, и блок, которому нечего сообщить, отсутствует, а не пуст. Проверяйте наличие ключа перед итерацией. searchInformation содержит общее количество, а pagination.nextPageToken — это то, что вы передаёте обратно как paginationToken. Реклама никогда не смешивается с органическими массивами, хотя их две, и их нужно пропустить.
{
"positionOnPage": 1,
"videoId": "GuTcle5edjk",
"title": "you need to learn MCP RIGHT NOW!! (Model Context Protocol)",
"viewsOriginal": "1.6M views",
"views": 1653824,
"length": "38:40",
"publishedDate": "11 months ago",
"extensions": ["4K"],
"chapters": [
{ "title": "Intro", "time": "0:00" },
{ "title": "Problem: LLMs Suck at Accessing Code", "time": "0:40" }
],
"channel": { "name": "NetworkChuck", "verified": true }
}Здесь стоит упомянуть две вещи. views — это разобранное целое число рядом со строкой отображения 1.6M views и не требует парсера суффиксов. А chapters возвращаются внутри результатов поиска, а не только на самом видео, хотя только некоторые видео их содержат.
В справочнике конечной точки поиска перечислены все токены sp и filters__, которые принимает конечная точка.
Получить данные видео YouTube
hasdata_youtube_video_getYoutubeVideo
Одно видео по id.
Параметр | Тип | Обязательный | Примечания |
| string | да | 11-символьный id видео из |
| string | Двухбуквенные коды страны и языка, а также устройство |
Возвращает title, thumbnail, channel, publishedDate, lengthSeconds, category, isFamilySafe и isUnlisted, а также массивы relatedVideos, endScreenVideos, keywords, captions, music и socialLinks. description — это объект, содержащий полный текст в content и массив links, где каждая ссылка и хэштег содержат startIndex, length, text и url. Поле text содержит ссылку в том виде, как её написал автор, а url — обёртку перенаправления YouTube, что важно, если вы извлекаете спонсорские или партнёрские ссылки из описаний.
Читайте разобранное поле по имени для каждого инструмента, прежде чем копировать пример ниже. Результаты поиска и каналов помещают разобранное число в
views, а строку отображения вviewsOriginal. Этот ответ инвертирует это, оставляя строку вviews, а число вextractedViews, и та же инверсия применяется кlikesиsubscribers. Если ошибиться,item.views > 100000будет сравнивать строку здесь, никогда не вызывая исключения.
{
"title": "Rick Astley - Never Gonna Give You Up (Official Video) (4K Remaster)",
"views": "1,806,075,152 views",
"extractedViews": 1806075152,
"likes": "19M",
"extractedLikes": 19344370,
"publishedDate": "Oct 24, 2009",
"lengthSeconds": 214,
"category": "Music",
"channel": { "name": "Rick Astley", "subscribers": "4.53M subscribers", "extractedSubscribers": 4530000 }
}Получить данные канала YouTube
hasdata_youtube_channel_getYoutubeChannel
Канал по id или хэндлу, по одной вкладке за раз.
Параметр | Тип | Обязательный | Примечания |
| string | да | Канонический идентификатор |
| string | По умолчанию | |
| string | Токен из предыдущего ответа | |
| string | Двухбуквенные коды страны и языка, а также устройство |
На вкладке по умолчанию возвращаются channelInfo, featuredVideo и sections. Остальные вкладки возвращают собственную структуру. channelInfo содержит handle, аватар, баннер, описание, ключевые слова канала и его rssUrl — этого достаточно, чтобы продолжать следить за каналом без опроса.
Массив
availableTabsв примере ниже содержит отображаемые подписи, и это не те значения, которые принимаетtab.Home,Live,CoursesиSearchне соответствуют ни одному значению параметра, а остальные нужно привести к нижнему регистру. Агент, который читает список и обходит каждый элемент, споткнётся уже на первом.
{
"channelInfo": {
"channelId": "UC_x5XG1OV2P6uZZ5FSM9Ttw",
"name": "Google for Developers",
"handle": "@GoogleDevelopers",
"rssUrl": "https://www.youtube.com/feeds/videos.xml?channel_id=UC_x5XG1OV2P6uZZ5FSM9Ttw",
"isFamilySafe": true,
"availableTabs": ["Home", "Videos", "Shorts", "Live", "Courses", "Playlists", "Posts", "Search"]
}
}Получить транскрипт видео YouTube
hasdata_youtube_transcript_getYoutubeTranscript
Синхронизированный по времени транскрипт видео.
Параметр | Тип | Обязательный | Примечания |
| string | да | 11-символьный идентификатор видео |
| string | Код BCP-47 нужной дорожки | |
| string | Установите |
Проверяйте
selectedв ответе, прежде чем доверять языку. ЗапросlanguageCode, которого нет в видео, не приводит ни к ошибке, ни к пустому ответу — он тихо переключается на дорожку по умолчанию. Каждая запись в списке содержитlanguageNameиlanguageCode, и один язык может встречаться дважды: один раз созданный человеком и один раз сtypeравнымasr.
{
"transcript": [
{ "startMs": 320, "endMs": 18800, "snippet": "[Music]", "startTimeText": "0:00" },
{ "startMs": 18800, "endMs": 21800, "snippet": "We're no strangers to", "startTimeText": "0:18" }
],
"availableTranscripts": [
{ "languageName": "English", "languageCode": "en" },
{ "languageName": "English", "languageCode": "en", "type": "asr", "selected": true },
{ "languageName": "German (Germany)", "languageCode": "de-DE" },
{ "languageName": "Japanese", "languageCode": "ja" }
]
}Ошибки и пути отказа
Ваш клиент почти никогда не видит HTTP-код ошибки от вызова инструмента. Слой MCP отвечает 200 и помещает сбой внутрь результата, с isError равным true и причиной в виде текста. Агент читает сообщение там, где вы могли бы ожидать строку статуса.
Неверный ключ проявляется как вывод инструмента, а не как неудачное подключение. tools/list принимает любой непустой ключ и возвращает все четыре инструмента, поэтому клиент завершает рукопожатие и показывает зелёный индикатор. Первый вызов инструмента затем возвращается с isError: true и текстом HasData API error: 401 Unauthorized. Следите за этой строкой, потому что ничто ранее в потоке не сообщает о проблеме.
Отсутствующий ключ — единственная настоящая HTTP-ошибка. Авторизация выполняется перед любым инструментом, и само подключение завершается с ошибкой 401. Заголовки CORS присутствуют, и браузерный клиент читает статус, а не непрозрачный сетевой сбой.
Аргумент, нарушающий схему инструмента, отклоняется до того, как станет скрейпингом. Сервер отвечает с isError: true и текстом MCP error -32602: Input validation error, указывая offending-поле. Ничего не загружается и ничего не списывается. Сообщение называет поле, но не допустимые значения, поэтому таблицы параметров выше — справочник.
Вызов, который успешен и ничего не находит, — это случай, на котором спотыкаются. Он приходит как обычный результат с requestMetadata.status равным ok, а ключ данных просто отсутствует. Ничто в теле не говорит о том, что результат пуст. Проверяйте нужное поле, а не наличие ошибки.
Идентификатор, отклонённый платформой, возвращает 400 с requestMetadata.status равным error. Несуществующий handle канала — обычный способ это увидеть.
Результаты с данными также содержат requestMetadata.id, который стоит указывать в обращении в поддержку.
Цены, бесплатный тариф и лимиты
Каждый инструмент YouTube стоит 10 кредитов за успешный вызов. Размер ответа не меняет цену. Полная страница результатов поиска стоит столько же, сколько страница с одним видео.
Бесплатная пробная версия — 1 000 кредитов на 30 дней без карты, то есть 100 вызовов YouTube. После этого активный аккаунт продолжает получать 100 кредитов ежедневно, когда его баланс опускается ниже 100, так что агент с низким объёмом работает на бесплатном тарифе бессрочно.
Платные тарифы начинаются с 49 долларов в месяц за 200 000 кредитов, то есть 20 000 вызовов. Цена за единицу снижается с объёмом: от 2,45 доллара за 1 000 вызовов на начальном тарифе до 0,99 доллара на Business, 0,83 доллара на Growth и 0,75 доллара на самых крупных тарифах с высоким объёмом.
Ваш тариф также задаёт параллельность. Бесплатная пробная версия допускает 1 запрос одновременно, Startup — 15, Business — 30, Growth — 50, а тарифы с высоким объёмом — от 200 до 1 500. Обрабатывайте переполнение защитно во всём, что работает без присмотра, потому что агент, который разворачивает веер запросов, упрётся в потолок раньше вас.
Запрос, вернувшийся с кодом, отличным от 200, не тарифицируется. Успешный вызов, который ничего не нашёл, — это всё равно вызов.
Выбор инструментов
Параметр запроса apis определяет, какие инструменты видит ваш агент. Меньше инструментов — меньше контекста, потраченного на определения инструментов, и меньше шансов, что модель потянется не к тому.
?apis=youtube the four tools in this repo
?apis=youtube,google_serp add Google search
?apis=youtube,tiktok,instagram a social research bundleПараметр принимает имена провайдеров, такие как youtube, и отдельные имена API, такие как google_maps_search. Опечатанные имена игнорируются. Если все имена неверны, запрос завершается ошибкой 400, и в теле перечислены и то, что не распознано, и все допустимые значения. Уберите параметр — и та же конечная точка откроет все 57 инструментов HasData.
Сравнение
Против официального YouTube Data API v3:
YouTube Data API v3 | Этот сервер | |
Настройка | Проект Google Cloud и ключ API | Один ключ и один URL |
Лимит поиска | «стандартная квота в 100 вызовов | Кредиты вашего тарифа, 10 за вызов |
Транскрипты чужих видео |
| Да, со списком языков |
Главы в результатах поиска | Нет | Да |
Просмотры и лайки в результатах поиска | Отсутствуют, а повторный вызов | Отображаемая строка и целое число в одном ответе |
Стоимость | Бесплатно в пределах дневной квоты | Платно после пробного периода, 10 кредитов за вызов |
Запись и приватные данные | Загрузки, плейлисты, комментарии и собственная аналитика через OAuth | Только чтение, только публичные данные |
Последние две строки важны. Если дневной квоты хватает на ваш объём и вы владеете каналом, к которому обращаетесь, официальный API — более дешёвый ответ, и стоит выбрать его.
Большинство других MCP-серверов YouTube работают только с транскриптами. Этот также ищет, читает видео с их показателями вовлечённости и обходит вкладки каналов, так что агент проводит целый исследовательский проход без второго сервера.
Чего этот сервер не делает. Никаких комментариев, управления каналом, загрузок, аналитики, приватных данных. Он читает то, что видит посетитель без входа в аккаунт.
FAQ
Существует ли официальный MCP-сервер YouTube?
Google его не публикует. У YouTube нет собственного MCP-сервера. Любой вариант создан кем-то другим — либо вокруг YouTube Data API v3, либо вокруг публичных страниц. Этот поддерживается HasData и читает публичные страницы, поэтому ему не нужны учётные данные Google.
Что такое MCP-сервер YouTube?
Сервер, который предоставляет данные YouTube как инструменты, которые может вызывать ИИ-клиент. Клиент отправляет вызов инструмента по Model Context Protocol, сервер загружает данные и возвращает структурированный JSON, а модель работает с результатом и никогда не видит страницу HTML. Этот сервер предоставляет четыре инструмента и работает удалённо. Клиент подключается к URL и не запускает локальный процесс.
Нужен ли мне ключ YouTube API или проект Google Cloud?
Нет. Единственное учётное данное — ваш ключ HasData. Не нужно создавать проект Google Cloud, заполнять форму квоты или проходить экран согласия OAuth, потому что инструменты читают публичные страницы YouTube, а не YouTube Data API.
Нужно ли мне что-то хостить или запускать?
Нет. Это удалённый MCP-сервер на streamable HTTP. Нечего устанавливать, не нужно держать контейнер тёплым, не нужно перезапускать процесс.
Данные живые или кэшированные?
Живые. Каждый вызов загружает страницу в момент запроса и несёт собственный requestMetadata.id. Два одинаковых вызова — это две отдельные загрузки, а не воспроизведение сохранённой копии. Счётчики вроде просмотров и лайков отслеживают страницу, поэтому они движутся вместе с ней.
Что произойдёт, когда YouTube изменит свой макет?
С вашей стороны ничего. Мы отслеживаем изменения и сохраняем стабильной схему ответа, так что имена полей и типы остаются на месте. Поле без значения отсутствует в элементе, а не присутствует со значением null. Читайте необязательные поля со значением по умолчанию.
Можно ли использовать это вместе с другими API HasData?
Да. Параметр apis принимает список, и ?apis=youtube,google_serp даёт вашему агенту четыре инструмента YouTube плюс поиск Google. Уберите параметр — и получите всё.
Можно ли получить транскрипт для любого видео?
Только если у видео он есть, а availableTranscripts сообщает, что существует, прежде чем вы спросите.
Можно ли войти через OAuth вместо вставки ключа?
Да, в клиентах, которые это поддерживают. Claude Desktop и Cursor могут добавить конечную точку как коннектор и войти. Агенты и скрипты без присмотра используют заголовок x-api-key.
Соответствие требованиям и персональные данные
HasData обращается только к общедоступным данным. Условия платформы могут ограничивать автоматический доступ, и вы несёте ответственность за собственное соблюдение требований. Если собираемые вами данные включают личную информацию, убедитесь, что у вас есть законное основание для этого в соответствии с GDPR, CCPA или эквивалентными правилами вашей юрисдикции.
Ссылки HasData
Страница продукта и конструктор запросов | |
Документация сервера | |
Все 57 инструментов в одном сервере | |
Пошаговые руководства для клиентов | |
Всё остальное, что мы парсим | |
Тарифы и стоимость кредитов | |
Ключи и использование |
Разработка
Этот репозиторий содержит конфигурацию и документацию для удалённого сервера. Здесь нет этапа сборки и нечего контейнеризировать.
Тесты в test/ проверяют контракт инструментов — ту часть, которая может сломаться без коммита здесь. Они проверяют, что ?apis=youtube возвращает ровно четыре инструмента, что каждый инструмент по-прежнему объявляет свой обязательный параметр, что ни одно имя не изменилось и что используемый ключ действительно принимается. Последняя проверка реально вызывает инструмент и стоит 10 кредитов — это цена канарейки, которая может упасть по правильной причине.
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm testТот же набор тестов запускается в CI при каждом пуше и раз в неделю по расписанию, потому что список инструментов вышестоящего сервиса может измениться без изменений в этом репозитории. Сбой означает, что список инструментов сдвинулся, ключ перестал работать или конечная точка была недоступна, и сообщение проверки указывает, что именно.
Вклад в проект
Исправления в таблицах инструментов и примерах ответов — самый полезный вклад, потому что именно эти части расходятся. Укажите выполненный вызов и полученный ответ. Запросы на включение из форков запускают набор тестов без ключа, а живые проверки пропускаются, а не становятся красными.
Лицензия
MIT. См. LICENSE.
Available Tools
4 toolshasdata_youtube_channel_getYoutubeChannelyoutube_channel: GET /AInspect
Get YouTube Channel Data
Fetches a YouTube channel by its ID (UC…) or handle (@name) and returns structured data for any channel tab — featured/Home, videos, shorts, streams, playlists, posts, podcasts, releases, store, about. Returns channel identity (title, description, avatar, banner, country, join date), subscriber and total-view counts, social links, and the items on the requested tab (videos with views and publish date, playlists, posts, podcasts, etc.). Use to monitor competitor channels, build creator/brand directories, track posting cadence and growth signals, or feed videoId into the YouTube Video / Transcript endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| tab | No | Channel tab to scrape. Each tab returns a different content shape: - `featured` (default) — channel Home page (channel trailer + curated rows) - `videos` — uploaded long-form videos - `shorts` — Shorts feed - `streams` — past and upcoming live streams - `playlists` — created and saved playlists - `posts` / `community` — community posts - `podcasts` — podcast episodes - `releases` — music releases - `about` — channel description, links, stats - `store` — channel merch | |
| channelId | Yes | YouTube channel identifier — either the canonical channel ID (`UC…`, 24 chars) or the public handle starting with `@` (e.g. `@PewDiePie`). Legacy `/c/<custom>` and `/user/<name>` URL slugs are also accepted. | |
| deviceType | No | Device type for the request. | |
| paginationToken | No | Token returned in the previous response to fetch the next page of results. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well: it states what is fetched, which tabs are supported, what channel-level fields are returned, and how results can be reused. It does not mention rate limits, authentication, or explicit read-only status, but the verb 'Fetches' and the GET-style title make the operation's nature clear.
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 dense but well-organized: it starts with the core fetch behavior, then explains output fields, then lists concrete use cases. Every sentence adds value; only minor redundancy exists between the description's tab list and the schema's tab enum.
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 tool with no output schema and no annotations, the description provides a solid mental model of inputs, outputs, tabs, and downstream use. It could go deeper on pagination/response structure, but the schema already covers paginationToken, and the description sufficiently explains what an agent can expect from the result.
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 schema already documents every parameter. The description reinforces channelId's accepted formats and explains the meaning of tab-level output, but it does not add significant meaning beyond the schema for gl, hl, deviceType, or paginationToken. 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 opens with a specific verb ('Fetches a YouTube channel by its ID or handle') and clearly distinguishes the tool from YouTube search, video, and transcript siblings by focusing on channel-level data and per-tab content. It names concrete output types, making the tool's purpose unmistakable.
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 gives clear application contexts ('monitor competitor channels, build creator/brand directories, track posting cadence and growth signals') and even routes downstream usage to the YouTube Video/Transcript endpoints. It does not explicitly list when not to use this tool versus search or video endpoints, but the use cases are concrete enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hasdata_youtube_search_getYoutubeSearchResultsyoutube_search: GET /AInspect
Get YouTube Search Results
Searches YouTube for a query and returns the full results page split into videoResults (videoId, title, views, length, publish date, chapters, channel info, extensions like 4K/CC), channelResults (channelId, handle, subscribers, verified flag), shortsResults / inlineShortsResults, themed shelves (e.g. 'People also watched', 'Latest from '), adsResults and sponsoredResults (advertiser, landing URL, position), plus searchInformation.totalResults. Each block preserves its positionOnPage so the original layout is reconstructable. Use for competitor and topic monitoring, brand-mention tracking, ad-placement intelligence, creator discovery, trend research, or to feed videoId / channelId into the YouTube Video, Channel, or Transcript endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Free-text search query, exactly as a user would type it into the YouTube search box. | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| sp | No | Raw YouTube `sp` filter token, copied verbatim from a YouTube search URL (e.g. `EgIQAQ%253D%253D`). When provided, it overrides `sortBy`, `date`, `videoType`, `length`, and `filters[]`. Use only if you need a YouTube-side filter that this API does not expose as a structured parameter. | |
| date | No | Limit results to videos uploaded within this time window relative to now. | |
| length | No | Filter by video duration bucket: - `under4` — under 4 minutes - `between420` — 4 to 20 minutes - `plus20` — over 20 minutes | |
| sortBy | No | Sort order applied to the results page. `relevance` (default) — best match for the query; `date` — newest first; `views` — most viewed first; `rating` — highest rated first; `popularity` — trending/most popular. | |
| filters__ | No | Feature flags to require on results. Multiple values are combined with AND (every flag must apply). - `hd` — HD quality - `k4` — 4K quality - `hdr` — HDR - `subtitles` — has subtitles/closed captions - `cc` — Creative Commons license - `d3` — 3D video - `d360` — 360° video - `vr180` — VR180 video - `live` — currently live - `bought` — purchased/paid content - `location` — has a geographic location tag | |
| videoType | No | Restrict results to a single YouTube content type — regular videos, Shorts, channels, playlists, or movies. | |
| deviceType | No | Device type for the request. | |
| paginationToken | No | Token returned in the previous response to fetch the next page. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description makes clear this is a read-oriented search operation that returns a results page, but no annotations are present and it does not explicitly mention authentication, rate limits, error behavior, or confirm there are no side effects. The read-only nature is implied rather than fully disclosed.
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 dense but every clause earns its place: the first sentence front-loads the purpose and output structure, and the second sentence explains real-world use cases and relationships to sibling tools. There is no redundant filler or repeated schema content.
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 there is no output schema, the description thoroughly covers the response shape (videoResults, channelResults, shortsResults, shelves, adsResults, sponsoredResults, positionOnPage) and gives downstream usage context. Pagination is also covered indirectly through the paginationToken parameter, making the tool self-contained enough for an 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?
The input schema already provides 100% descriptive coverage of all 11 parameters, including enums and the sp override behavior. The description itself adds no parameter-level meaning beyond that, so it sits at the baseline for a fully documented 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 opens with 'Searches YouTube for a query' and precisely identifies the resource and action, and it enumerates the distinct result sections returned. This makes the tool's purpose unmistakable and distinguishes it from the channel, video, and transcript sibling tools.
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?
It explicitly lists concrete use cases (competitor monitoring, brand tracking, ad-placement intelligence, creator discovery, trend research) and tells agents to feed returned videoId/channelId into the Video, Channel, or Transcript endpoints. This provides clear guidance on when to use the search tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hasdata_youtube_transcript_getYoutubeTranscriptyoutube_transcript: GET /AInspect
Get YouTube Video Transcript
Returns the timed transcript (subtitles) of a YouTube video by its 11-character videoId. languageCode selects the track (e.g. en, de-DE, pt-BR); type=asr requests the auto-generated speech-recognition track. Each segment in transcript[] carries startMs, endMs, snippet, and a formatted startTimeText. The response also includes availableTranscripts[] listing every track on the video (language name + code, type: asr for auto-generated, selected: true for the one returned) so callers can discover what else is available. Use to feed a video's spoken content into RAG/LLM pipelines, generate summaries or chapter outlines, build searchable archives, run translation or accessibility workflows, or analyze talking points across a creator's catalog (pair with the YouTube Channel endpoint to enumerate videos, then fetch transcripts).
| Name | Required | Description | Default |
|---|---|---|---|
| v | Yes | 11-character YouTube video ID — the value of the `v=` query parameter in a watch URL (e.g. `dQw4w9WgXcQ` for `https://www.youtube.com/watch?v=dQw4w9WgXcQ`). | |
| type | No | Set to `asr` to fetch the YouTube auto-generated (speech-recognition) track. Omit to fetch the human-authored track for `languageCode` when one exists. | |
| languageCode | No | BCP-47 / YouTube language code of the transcript track to return (e.g. `en`, `de`, `en-US`, `pt-BR`). Must match a track that the video actually has. When omitted, the video's default language track is returned. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by explaining the response shape: transcript segments with startMs/endMs/snippet/startTimeText, plus availableTranscripts[] with language/type/selected info. It does not cover error cases such as missing tracks or invalid video IDs, but the behavioral context is strong.
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 well-structured and front-loaded, leading with the core purpose before expanding into response details and use cases. Every sentence adds meaningful context, with no filler or repetition.
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?
Despite having no output schema, the description thoroughly explains the return value structure and available track discovery. Combined with the complete parameter schema, an agent has enough information to select and invoke this tool correctly for transcript-related tasks.
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 schema already describes all three parameters with 100% coverage, so the baseline is 3. The description reinforces languageCode and type=asr semantics but adds little beyond what the schema already states; the v parameter is already fully documented 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 returns the timed transcript (subtitles) of a YouTube video by 11-character videoId. This is a specific verb+resource that is naturally distinct from the sibling channel/search/video endpoints.
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?
It provides concrete use cases such as RAG/LLM pipelines, summaries, archives, translation, and accessibility workflows. It also suggests pairing with the YouTube Channel endpoint to enumerate videos, but it does not explicitly contrast with the search or video siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hasdata_youtube_video_getYoutubeVideoyoutube_video: GET /AInspect
Get YouTube Video Data
Fetches a single YouTube video by its 11-character videoId. Returns title, thumbnail, raw + normalized views and likes, lengthSeconds, publish date, category, keywords/tags, isFamilySafe / isUnlisted flags, the uploading channel (id, handle, subscribers, avatar), the full description with parsed links and hashtags, available captions tracks (with kind: asr for auto-generated), Content-ID music matches (song/artist/album), creator socialLinks, and the relatedVideos, endScreenVideos, and relatedShorts rails. Use to enrich a video URL with metadata, monitor view/like growth, extract music or sponsor/affiliate links, gather features for recommender or RAG pipelines, or detect caption tracks before calling the YouTube Transcript endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| v | Yes | 11-character YouTube video ID — the value of the `v=` query parameter in a watch URL (e.g. `dQw4w9WgXcQ` for `https://www.youtube.com/watch?v=dQw4w9WgXcQ`). | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| deviceType | No | Device type for the request. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only fetch and provides rich output semantics: raw + normalized views/likes, safety/unlisted flags, captions with kind:asr, Content-ID music matches, social links, and related rails. It omits error handling, auth, and rate limits, but for a GET-style data tool the described behavior is substantially transparent.
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 long but information-dense: it front-loads the core purpose, then systematically lists return fields and use cases without filler. It could be structured into shorter sentences, but every clause adds relevant information for a tool with a rich payload.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description compensates well by enumerating the full return surface and tying usage to the transcript sibling. Minor gaps remain around error cases and access requirements, but an agent has enough to invoke the tool correctly for typical metadata enrichment tasks.
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%, and all four parameters (v, gl, hl, deviceType) are already documented with types, examples, and allowed values. The description only repeats the videoId concept and does not add 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 states a specific verb ('Fetches') and resource ('a single YouTube video by its 11-character videoId') and enumerates the returned fields in detail. It is clearly distinct from the sibling channel/search/transcript tools because it is scoped to video metadata.
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 lists concrete use cases: enriching video URLs, monitoring view/like growth, extracting music or affiliate links, building recommender/RAG features, and detecting caption tracks before calling the YouTube Transcript endpoint. It does not explicitly state when not to use the tool, but the context is clear enough for an agent to select it.
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.
4 tool updates
v1.0.0- First observed
hasdata_youtube_channel_getYoutubeChannel - First observed
hasdata_youtube_search_getYoutubeSearchResults - First observed
hasdata_youtube_transcript_getYoutubeTranscript - First observed
hasdata_youtube_video_getYoutubeVideo
TDQS
Scored across 4 tools
Each tool targets a clearly distinct resource: channel data, search results, transcripts, and video metadata. There is no overlap in purpose—the channel tool returns channel/playlist info, search returns result blocks, transcript returns timed subtitles, and video returns single-video metadata. An agent would have no trouble selecting the right tool for a given task.
All four tools follow the identical `hasdata_youtube_<domain>_getYoutube<Domain>` pattern (e.g., `hasdata_youtube_channel_getYoutubeChannel`). The naming is fully consistent in structure, verb, and case, making it predictable and easy to remember.
The server exposes exactly four tools, which is well-scoped for a YouTube data retrieval purpose. It covers the core read operations—channel lookup, search, transcript, and video details—without unnecessary bloat. Each tool earns its place, and the count is neither too thin nor excessive.
The tool set covers the primary read-only workflows for YouTube: fetching channel data (including playlists and posts), searching, retrieving video metadata, and getting transcripts. Minor gaps exist, such as a dedicated method for channel video lists (though the channel tool can fetch the videos tab) or comments, but the core lifecycle for data retrieval is well covered. Agents can achieve most tasks without dead ends.
Maintenance
Related MCP Connectors
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
YouTube transcripts, search, and channel and playlist listings for any AI app. Hosted.
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents.
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.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceA 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.40MIT
- AlicenseBqualityAmaintenanceA 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.12420 npm26MIT
- AlicenseNot gradedqualityDmaintenanceA 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.13MIT
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server providing comprehensive read-only access to YouTube data, including video search, transcripts, and channel forensics. It features 16 specialized tools designed for content analysis and metadata retrieval in LLM applications.2-