A
licenseNot graded
qualityF
maintenanceA 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.
43
MIT
YouTube MCP Server
by HasData
YouTube MCP サーバー
Claude、Cursor、Windsurf、その他あらゆるMCPクライアントに4つの読み取り専用YouTubeツールを提供するホスト型Model Context Protocol（MCP）サーバーです。YouTubeの検索、動画・チャンネルデータの読み取り、トランスクリプトの取得が可能で、Google CloudプロジェクトもYouTube Data APIキーも不要です。
https://mcp.hasdata.com/api/mcp?apis=youtube
目次
Related MCP server: YouTube MCP Server
必要なもの
カスタムヘッダー付きのstreamable HTTPに対応したMCPクライアント。ダッシュボードから無料で作成できるHasData APIキー。これだけです。これはリモートサーバーです。インストールするパッケージも、実行するコンテナも、フローの中に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はフィールド名をurlではなくserverUrlと呼びます:
{
"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に関する動画で最も視聴された10本を見つけて、その中でトップの動画のトランスクリプトを取得し、ツール呼び出しについて述べている3つの主張を教えてください。
2回の呼び出し、20クレジット。
@GoogleDevelopers チャンネルを調べてください。公開しているタブを一覧し、直近5件のアップロードを要約して、繰り返し登場するトピックを教えてください。
2回の呼び出し、20クレジット。タブ一覧は最初のレスポンス内に含まれるため、未確認のタブを読むには2回目の呼び出しが必要です。
この動画ID、dQw4w9WgXcQ を調べてください。統計情報を取得し、関連動画のうち同じチャンネルから投稿されたものを確認してください。
1回の呼び出し、10クレジット。関連動画は同じレスポンスに含まれます。
YouTubeで「web scraping tutorial」をアップロード日順で検索し、4分未満の動画のみに絞り、各結果にチャプターがあればそのタイトルを教えてください。
1回の呼び出し、10クレジット。
この動画のドイツ語トランスクリプトが存在すれば取得し、利用可能な言語を教えてください。
1回の呼び出し、10クレジット。
検索はYouTube独自のフィルタートークンを受け付けるため、エージェントは後処理なしで再生時間、アップロード日、コンテンツタイプで絞り込めます。トランスクリプトは利用可能な言語トラックの一覧とともに返されるため、エージェントは推測せずに言語を選べます。
ページングは1回につき1呼び出し分のコストがかかります。検索して2回ページングし、3本のトランスクリプトを取得する調査プロンプトは、6回の呼び出しで60クレジットです。試用枠は、無制限のクロールよりも絞り込んだ質問の方が長く使えます。
ツール
4つのツール、すべて読み取り専用です。以下のサンプルは実際の呼び出しから抜粋したもので、数値はYouTubeの更新に応じて変わります。形として読んでください。各ツール名はエンドポイントリファレンスにリンクしており、完全なフィールド一覧が記載されています。
サンプルはペイロードであり、レスポンス全体ではありません。tools/callの結果には1つのテキストブロックが含まれ、そのテキスト自体がurl、status、text、jsonを持つJSONで、スクレイピングされたデータはjsonの下にあります。生のJSON-RPCレスポンスからのパスはresult.content[0].textをパースしてから.jsonです。チャットクライアントはこれを自動的に展開しますが、エンドポイントに直接通信するコードでは自分で行う必要があります。
YouTube検索結果の取得
hasdata_youtube_search_getYoutubeSearchResults
YouTubeを検索し、結果タイプごとに分割された結果ページ全体を返します。
パラメータ | 型 | 必須 | 備考 |
| string | はい | ユーザーが入力するのとまったく同じ自由文クエリ |
| string | デフォルトは | |
| string | 現在からのアップロード期間 | |
| string | 再生時間のバケット。例: | |
| string | 1つのコンテンツタイプに制限 | |
| array | 機能フラグ。組み合わせ可能 | |
| string | 検索URLからコピーした生のYouTube | |
| string | 前回のレスポンスの | |
| string | 2文字の国コードと言語コード、およびデバイス |
結果ページはvideoResults、shortsResults、inlineShortsResults、playlistResults、channelResults、shelvesに分割され、有料掲載はadsResultsとsponsoredResultsに入ります。どのブロックが現れるかはクエリによって異なり、報告するものがないブロックは空ではなく存在しません。反復処理の前にキーの存在を確認してください。searchInformationには合計数が含まれ、pagination.nextPageTokenをpaginationTokenとしてフィードバックします。広告がオーガニック配列に混ざることはありませんが、スキップすべき広告配列が2つあります。
{
"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 }
}ここで2点注目すべきことがあります。viewsは1.6M viewsという表示文字列の隣にあるパース済みの整数で、サフィックスパーサーは不要です。また、chaptersは動画自体だけでなく検索結果にも返されます。ただし、チャプターを持つ動画は一部のみです。
検索エンドポイントリファレンスには、エンドポイントが受け付けるすべてのspおよびfilters__トークンが記載されています。
YouTube動画データの取得
hasdata_youtube_video_getYoutubeVideo
IDによる単一動画の取得。
パラメータ | 型 | 必須 | 備考 |
| string | はい |
|
| string | 2文字の国コードと言語コード、およびデバイス |
title、thumbnail、channel、publishedDate、lengthSeconds、category、isFamilySafe、isUnlistedに加え、relatedVideos、endScreenVideos、keywords、captions、music、socialLinksの各配列を返します。descriptionは、全文を保持するcontentと、すべてのリンクとハッシュタグにstartIndex、length、text、urlを持つlinks配列を含むオブジェクトです。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またはハンドルによるチャンネルの取得。一度に1つのタブずつ取得します。
パラメータ | 型 | 必須 | 備考 |
| string | はい | 正規の |
| string | デフォルトは | |
| string | 前回のレスポンスからのトークン | |
| string | 2文字の国コードと言語コード、およびデバイス |
デフォルトのタブではchannelInfo、featuredVideo、sectionsを返します。他のタブはそれぞれ独自の構造を返します。channelInfoにはハンドル、アバター、バナー、説明文、チャンネルキーワード、チャンネルの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文字の動画ID |
| string | 取得したいトラックのBCP-47コード | |
| string | 自動生成トラックの場合は |
レスポンスの
selectedを確認してから言語を信頼してください。動画が保持していないlanguageCodeを要求しても、失敗も空の返却もせず、静かにデフォルトのトラックにフォールバックします。リストの各エントリにはlanguageNameとlanguageCodeが含まれ、同じ言語が2回出現することがあります。1回は人間が作成したもの、もう1回は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は空でないキーなら何でも受け入れ、4つすべてのツールを返すため、クライアントはハンドシェイクを完了し、緑色を表示します。その後の最初のツール呼び出しがisError: trueとテキストHasData API error: 401 Unauthorizedで返ってきます。この文字列に注意してください。フロー内のそれ以前の段階では問題が報告されないからです。
キーが欠落している場合が、唯一の実際のHTTPエラーです。 認証はすべてのツールの前に実行され、接続自体が401で失敗します。CORSヘッダーは存在し、ブラウザクライアントは不透明なネットワーク障害ではなくステータスを読み取ります。
ツールのスキーマを壊す引数は、スクレイピングになる前に拒否されます。 サーバーはisError: trueとテキストMCP error -32602: Input validation errorで応答し、問題のあるフィールドを指定します。何も取得されず、課金もされません。メッセージはフィールド名を指定しますが、受け付けられる値は指定しないため、上記のパラメータ表が参照先となります。
成功して何も見つからない呼び出しが、人々をつまずかせるケースです。 これは通常の結果として到着し、requestMetadata.statusはokに設定され、データキーが単に欠落しています。ボディ内の何も結果が空であることを示していません。エラーではなく、必要なフィールドをテストしてください。
プラットフォームが拒否する識別子は400を返し、requestMetadata.statusはerrorに設定されます。存在しないチャンネルハンドルが、これを確認する一般的な方法です。
データを運ぶ結果にはrequestMetadata.idも含まれており、サポートに問い合わせる際に引用する価値があります。
料金、無料枠、制限
すべてのYouTubeツールは、成功した呼び出しごとに10クレジットかかります。レスポンスサイズによって価格は変わりません。検索結果のフルページも、動画が1つのページも同じ価格です。
無料トライアルはカード不要で30日間1,000クレジット、つまりYouTube呼び出し100回分です。その後、アクティブなアカウントは残高が100を下回るたびに毎日100クレジットが補充されるため、低ボリュームのエージェントは無期限に無料枠で実行できます。
有料プランは月額$49からで200,000クレジット、つまり20,000回の呼び出しです。単価はボリュームに応じて下がり、エントリープランでは1,000回の呼び出しあたり$2.45から、Businessでは**$0.99**、Growthでは**$0.83**、最大の高ボリュームプランでは**$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のようなプロバイダー名と、google_maps_searchのような個別のAPI名を受け取ります。スペルミスのある名前は無視されます。すべての名前が間違っている場合、リクエストは400で失敗し、ボディは認識できなかったものとすべての有効な値の両方をリストします。パラメータを省略すると、同じエンドポイントがHasDataの全57ツールを公開します。
比較
公式のYouTube Data API v3との比較:
YouTube Data API v3 | このサーバー | |
セットアップ | Google CloudプロジェクトとAPIキー | 1つのキーと1つのURL |
検索の割り当て | Googleのスタートガイドによると、1日あたり「デフォルトのクォータ割り当て100回の | プランのクレジット、1回の呼び出しにつき10 |
所有していない動画の文字起こし |
| 可能。言語リスト付き |
検索結果のチャプター | いいえ | はい |
検索結果の再生回数と高評価数 | なし。追加の | 同じレスポンス内に表示文字列と整数の両方 |
コスト | 日次クォータ内では無料 | トライアル後は有料、1回の呼び出しにつき10クレジット |
書き込みとプライベートデータ | OAuthによるアップロード、プレイリスト、コメント、自身のアナリティクス | 読み取り専用、公開データのみ |
最後の2行が重要です。日次クォータがボリュームをカバーし、クエリするチャンネルを所有している場合、公式APIの方が安価な答えであり、それを採用すべきです。
他のほとんどのYouTube MCPサーバーは文字起こしのみを提供します。このサーバーは検索、エンゲージメント数付きの動画読み取り、チャンネルタブの巡回も行うため、エージェントは2つ目のサーバーなしで調査パス全体を実行できます。
このサーバーが行わないこと。 コメントなし、チャンネル管理なし、アップロードなし、アナリティクスなし、プライベートデータなし。サインアウトした訪問者が見ることができるものを読み取ります。
FAQ
公式のYouTube MCPサーバーはありますか？
Googleは公開していません。YouTubeにはファーストパーティのMCPサーバーはありません。すべてのオプションは、YouTube Data API v3または公開ページの周りに、誰か他の人が構築したものです。これはHasDataが保守し、公開ページを読み取るものであり、Googleの認証情報が不要な理由です。
YouTube MCPサーバーとは何ですか？
YouTubeデータをAIクライアントが呼び出せるツールとして公開するサーバーです。クライアントはModel Context Protocolを介してツール呼び出しを送信し、サーバーはデータを取得して構造化JSONを返し、モデルは結果を操作してHTMLページを見ることはありません。これは4つのツールを公開し、リモートで実行されます。クライアントはURLに接続し、ローカルプロセスを起動しません。
YouTube APIキーやGoogle Cloudプロジェクトは必要ですか？
いいえ。唯一の認証情報はHasDataキーです。作成するGoogle Cloudプロジェクトも、記入するクォータフォームも、OAuth同意画面もありません。ツールが公開YouTubeページを読み取り、YouTube Data APIを読み取らないためです。
ホストや実行するものは必要ですか？
いいえ。これはストリーミング可能なHTTP上のリモートMCPサーバーです。インストールするものも、ウォームに保つコンテナも、再起動するプロセスもありません。
データはライブですか、それともキャッシュされていますか？
ライブです。各呼び出しはリクエスト時にページを取得し、独自のrequestMetadata.idを持ちます。2つの同一の呼び出しは2つの別々のフェッチであり、保存されたコピーの再生ではありません。再生回数や高評価数などのカウンターはページを追跡するため、ページが動くにつれて動きます。
YouTubeがレイアウトを変更したらどうなりますか？
あなたの側では何も起こりません。変更を追跡し、レスポンススキーマを安定に保つため、フィールド名と型はそのままです。値のないフィールドはアイテムに存在せず、存在してnullになることはありません。オプションフィールドはデフォルト値で読み取ってください。
他のHasData APIと一緒に使用できますか？
はい。apisパラメータはリストを受け取り、?apis=youtube,google_serpはエージェントに4つのYouTubeツールとGoogle検索を提供します。パラメータを省略すると、すべてが得られます。
任意の動画の文字起こしを取得できますか？
動画に文字起こしがある場合のみです。availableTranscriptsが、要求する前に何が存在するかを教えてくれます。
キーを貼り付ける代わりにOAuthでサインインできますか？
はい、サポートしているクライアントでは可能です。Claude DesktopとCursorはエンドポイントをコネクタとして追加し、サインインできます。無人エージェントとスクリプトはx-api-keyヘッダーを使用します。
コンプライアンスと個人データ
HasDataは公開されているデータのみにアクセスします。プラットフォームの利用規約が自動アクセスを制限している場合があり、コンプライアンスの責任はお客様自身にあります。収集するデータに個人情報が含まれる場合は、GDPR、CCPA、またはお客様の管轄区域の同等の規則に基づく正当な根拠があることを確認してください。
HasDataリンク
プロダクトページとリクエストビルダー | |
サーバードキュメント | |
57のツールを1つのサーバーに | |
クライアントのウォークスルー | |
その他のスクレイピング対象 | |
プランとクレジット料金 | |
キーと利用状況 |
開発
このリポジトリはリモートサーバーの設定とドキュメントです。ビルドステップはなく、コンテナ化するものもありません。
test/内のテストは、ここでのコミットなしに壊れる可能性のある部分であるツール契約を検証します。?apis=youtubeが正確に4つのツールを返すこと、すべてのツールが必須パラメータを宣言していること、名前が変更されていないこと、使用中のキーが実際に受け入れられることを確認します。最後のチェックは実際にツールを呼び出し、10クレジットを消費します。これは、正しい理由で失敗できるカナリアの価格です。
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm test同じスイートは、プッシュのたびにCIで実行され、週に1回スケジュールで実行されます。これは、このリポジトリに誰も触れなくてもアップストリームのツールリストが変更される可能性があるためです。失敗は、ツールリストが移動したか、キーが機能しなくなったか、エンドポイントに到達できなかったことを意味し、アサーションメッセージがその原因を示します。
コントリビューション
ツールテーブルとレスポンスサンプルの修正が最も有用なコントリビューションです。これらの部分は乖離しやすいためです。実行した呼び出しと取得したレスポンスを含めてください。フォークからのプルリクエストはキーなしでスイートを実行し、ライブチェックは失敗する代わりにスキップされます。
ライセンス
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
A4.1/5.0
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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
A4.3/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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
A4.3/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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
A4.1/5.0
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description 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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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
A4.2/5.0
Scored across 4 tools
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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
ActivityActive
ResponsivenessNo issues
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
- 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.12186 npm27MIT
- 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-