YouTube MCP Server
YouTube MCP Server
Ein gehosteter Model Context Protocol (MCP)-Server, der Claude, Cursor, Windsurf und jedem anderen MCP-Client vier schreibgeschützte YouTube-Tools bietet. Durchsuchen Sie YouTube, lesen Sie Video- und Kanaldaten und rufen Sie Transkripte ab – ohne Google Cloud-Projekt und ohne YouTube Data API-Schlüssel.
https://mcp.hasdata.com/api/mcp?apis=youtube
Inhalt
Related MCP server: YouTube MCP Server
Was Sie brauchen
Ein MCP-Client, der streambares HTTP mit benutzerdefinierten Headern spricht. Ein HasData-API-Schlüssel aus dem Dashboard, kostenlos zu erstellen. Sonst nichts. Dies ist ein Remote-Server. Es gibt kein zu installierendes Paket, keinen zu startenden Container und kein Google-Konto im gesamten Ablauf.
Schnellstart
Die Server-URL ist für jeden Client gleich. Wir testen sie hands-on in Claude Code und Claude Desktop. Die anderen Blöcke folgen dem jeweils dokumentierten Format des Clients für einen Remote-Server.
Feld | Wert |
URL |
|
Transport | HTTP, streamable |
Auth-Header |
|
Clients mit OAuth-Unterstützung können dieselbe URL als Connector hinzufügen und sich anmelden, ohne einen Schlüssel in eine Konfigurationsdatei einzutragen.
claude mcp add --transport http youtube "https://mcp.hasdata.com/api/mcp?apis=youtube" \
--header "x-api-key: HASDATA_API_KEY"Einstellungen, dann Connectors, dann Benutzerdefinierten Connector hinzufügen, dann https://mcp.hasdata.com/api/mcp?apis=youtube einfügen und anmelden.
Für den Konfigurationsdatei-Weg lädt Claude Desktop nur lokale (stdio) Server, daher wird ein Remote-Server über die mcp-remote-Brücke erreicht, die Node benötigt. Fügen Sie dies zu claude_desktop_config.json hinzu:
{
"mcpServers": {
"youtube": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.hasdata.com/api/mcp?apis=youtube",
"--header",
"x-api-key:HASDATA_API_KEY"
]
}
}
}Der Wert von x-api-key: enthält kein Leerzeichen nach dem Doppelpunkt. Claude Desktop übergibt das Argument ohne Shell, und ein Leerzeichen würde den Header teilen.
~/.cursor/mcp.json für jedes Projekt oder .cursor/mcp.json für eines:
{
"mcpServers": {
"youtube": {
"url": "https://mcp.hasdata.com/api/mcp?apis=youtube",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf nennt das Feld serverUrl, nicht 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 im Arbeitsbereich:
{
"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" }
}
}
}Beispiel-Prompts
Prompts, kein Code. Fügen Sie einen ein und der Agent wählt selbst das Tool. Jeder ist mit den benötigten Aufrufen annotiert, da in MCP das Modell entscheidet, wie viele Aufrufe es macht, und jeder erfolgreiche Aufruf 10 Credits kostet.
Finde die zehn meistgesehenen Videos über das Model Context Protocol aus dem letzten Monat, hole dann das Transkript des Top-Videos und nenne mir die drei Behauptungen, die es über Tool-Aufrufe aufstellt.
Zwei Aufrufe, 20 Credits.
Nimm den Kanal @GoogleDevelopers. Liste die Tabs auf, die er veröffentlicht, fasse dann die letzten fünf Uploads zusammen und sage mir, welche Themen sich wiederholen.
Zwei Aufrufe, 20 Credits. Das Lesen eines Tabs, den Sie noch nicht gesehen haben, erfordert einen zweiten Aufruf, da die Tab-Liste in der ersten Antwort enthalten ist.
Nimm diese Video-ID, dQw4w9WgXcQ. Hole seine Statistiken und prüfe dann, welche seiner verwandten Videos vom selben Kanal stammen.
Ein Aufruf, 10 Credits. Verwandte Videos sind in derselben Antwort enthalten.
Suche auf YouTube nach „web scraping tutorial“, sortiert nach Upload-Datum, nur Videos unter vier Minuten, und gib mir die Kapiteltitel jedes Ergebnisses, das welche hat.
Ein Aufruf, 10 Credits.
Hole das deutsche Transkript dieses Videos, falls eines existiert, und sage mir, in welchen Sprachen es verfügbar ist.
Ein Aufruf, 10 Credits.
Die Suche verwendet YouTubes eigene Filter-Tokens, und ein Agent grenzt nach Dauer, Upload-Datum und Inhaltstyp ein, ohne Nachbearbeitung. Transkripte kommen mit der Liste der verfügbaren Sprachspuren, sodass der Agent ohne Raten eine auswählen kann.
Das Blättern kostet jedes Mal einen Aufruf. Ein Recherche-Prompt, der sucht, zweimal blättert und dann drei Transkripte abruft, sind sechs Aufrufe und 60 Credits. Die Testversion reicht bei engen Fragen weiter als bei offenen Crawls.
Tools
Vier Tools, alle schreibgeschützt. Die Beispiele unten sind aus echten Aufrufen gekürzt, und die Zahlen darin ändern sich, wenn YouTube aktualisiert. Lesen Sie sie als Formen. Jeder Tool-Name verlinkt auf seine Endpunkt-Referenz, die die vollständige Feldliste enthält.
Die Beispiele sind die Nutzlast, nicht die gesamte Antwort. Ein tools/call-Ergebnis enthält einen Textblock, und dieser Text ist selbst JSON mit url, status, text und json, wobei die gescrapten Daten unter json liegen. Bei einer rohen JSON-RPC-Antwort ist der Pfad result.content[0].text, geparst, dann .json. Ein Chat-Client entpackt das für Sie, und Code, der direkt mit dem Endpunkt spricht, tut das nicht.
YouTube-Suchergebnisse abrufen
hasdata_youtube_search_getYoutubeSearchResults
Durchsucht YouTube und gibt die gesamte Ergebnisseite zurück, aufgeteilt nach Ergebnistyp.
Parameter | Typ | Erforderlich | Hinweise |
| string | ja | Freitextabfrage, genau wie ein Benutzer sie eingeben würde |
| string | Standardmäßig | |
| string | Upload-Zeitfenster relativ zu jetzt | |
| string | Dauer-Kategorie, zum Beispiel | |
| string | Auf einen Inhaltstyp beschränken | |
| array | Feature-Flags, kombinierbar | |
| string | Rohes YouTube- | |
| string | Das | |
| string | Zwei-Buchstaben-Länder- und Sprachcodes sowie Gerät |
Eine Ergebnisseite ist aufgeteilt in videoResults, shortsResults, inlineShortsResults, playlistResults, channelResults und shelves, mit bezahlten Platzierungen in adsResults und sponsoredResults. Welche Blöcke erscheinen, hängt von der Abfrage ab, und ein Block ohne Meldung fehlt, ist nicht leer. Testen Sie den Schlüssel, bevor Sie iterieren. searchInformation enthält die Gesamtzahl, und pagination.nextPageToken ist das, was Sie als paginationToken zurückgeben. Anzeigen mischen sich nie in die organischen Arrays, obwohl es zwei davon gibt, die übersprungen werden müssen.
{
"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 }
}Zwei Dinge dort verdienen eine Erwähnung. views ist eine geparste Ganzzahl neben der Anzeigezeichenfolge 1.6M views und benötigt keinen Suffix-Parser. Und chapters kommen in den Suchergebnissen zurück, nicht nur auf dem Video selbst, obwohl nur einige Videos sie enthalten.
Die Such-Endpunkt-Referenz listet jedes sp- und filters__-Token auf, das der Endpunkt akzeptiert.
YouTube-Videodaten abrufen
hasdata_youtube_video_getYoutubeVideo
Ein Video per ID.
Parameter | Typ | Erforderlich | Hinweise |
| string | ja | Die 11-stellige Video-ID aus |
| string | Zwei-Buchstaben-Länder- und Sprachcodes sowie Gerät |
Gibt title, thumbnail, channel, publishedDate, lengthSeconds, category, isFamilySafe und isUnlisted zurück, plus die Arrays relatedVideos, endScreenVideos, keywords, captions, music und socialLinks. description ist ein Objekt, das den vollständigen Text in content und ein links-Array enthält, wobei jeder Link und Hashtag startIndex, length, text und url trägt. Das Feld text enthält den Link, wie der Autor ihn geschrieben hat, und url enthält YouTubes Redirect-Wrapper, was wichtig ist, wenn Sie Sponsor- oder Affiliate-Ziele aus Beschreibungen extrahieren.
Lesen Sie das geparste Feld pro Tool namentlich, bevor Sie das Beispiel unten kopieren. Such- und Kanalergebnisse setzen die geparste Zahl in
viewsund die Anzeigezeichenfolge inviewsOriginal. Diese Antwort kehrt es um, behält die Zeichenfolge inviewsund die Zahl inextractedViews, und dieselbe Umkehrung gilt fürlikesundsubscribers. Wenn Sie es falsch machen, vergleichtitem.views > 100000hier eine Zeichenfolge, ohne jemals einen Fehler zu werfen.
{
"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-Kanaldaten abrufen
hasdata_youtube_channel_getYoutubeChannel
Ein Kanal per ID oder Handle, jeweils ein Tab.
Parameter | Typ | Erforderlich | Hinweise |
| string | ja | Kanonische |
| string | Standardmäßig | |
| string | Token aus der vorherigen Antwort | |
| string | Zweibuchstabige Länder- und Sprachcodes sowie Gerät |
Gibt auf dem Standard-Tab channelInfo, featuredVideo und sections zurück. Andere Tabs haben ihre eigene Struktur. channelInfo enthält den Handle, das Avatar, das Banner, die Beschreibung, die Kanalschlüsselwörter und die rssUrl des Kanals – genug, um einen Kanal weiterzuverfolgen, ohne ihn abzufragen.
Das
availableTabs-Array im Beispiel unten enthält Anzeigelabels, und das sind nicht die Werte, dietabakzeptiert.Home,Live,CoursesundSearchlassen sich auf gar keinen Parameterwert abbilden, und der Rest muss kleingeschrieben werden. Ein Agent, der die Liste liest und jeden Eintrag durchgeht, scheitert am ersten.
{
"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-Videotranskript abrufen
hasdata_youtube_transcript_getYoutubeTranscript
Das zeitgestempelte Transkript eines Videos.
Parameter | Typ | Erforderlich | Hinweise |
| string | ja | Die 11-stellige Video-ID |
| string | BCP-47-Code des gewünschten Tracks | |
| string | Auf |
Prüfe
selectedin der Antwort, bevor du der Sprache vertraust. Wenn du nach einemlanguageCodefragst, den das Video nicht enthält, schlägt das weder fehl noch liefert es eine leere Antwort – es fällt stillschweigend auf den Standard-Track zurück. Jeder Eintrag in der Liste enthältlanguageNameundlanguageCode, und eine Sprache kann doppelt vorkommen, einmal von Menschen erstellt und einmal mittypeaufasrgesetzt.
{
"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" }
]
}Fehler und Fehlerpfade
Dein Client sieht bei einem Tool-Aufruf fast nie einen HTTP-Fehlercode. Die MCP-Ebene antwortet mit 200 und legt den Fehler in das Ergebnis, mit isError auf true und dem Grund als Text. Der Agent liest eine Meldung, wo man eine Statuszeile erwarten würde.
Ein falscher Schlüssel erscheint als Tool-Ausgabe, nicht als fehlgeschlagene Verbindung. tools/list akzeptiert jeden nicht-leeren Schlüssel und gibt alle vier Tools zurück, sodass der Client seinen Handshake abschließt und grün anzeigt. Der erste Tool-Aufruf kommt dann mit isError: true und dem Text HasData API error: 401 Unauthorized zurück. Achte auf diese Zeichenkette, denn nichts früher im Ablauf meldet das Problem.
Ein fehlender Schlüssel ist der einzige echte HTTP-Fehler. Die Autorisierung läuft vor jedem Tool, und die Verbindung selbst schlägt mit 401 fehl. CORS-Header sind vorhanden, und ein Browser-Client liest den Status und keinen undurchsichtigen Netzwerkfehler.
Ein Argument, das das Schema eines Tools verletzt, wird abgelehnt, bevor daraus ein Scrape wird. Der Server antwortet mit isError: true und dem Text MCP error -32602: Input validation error und nennt das fehlerhafte Feld. Es wird nichts abgerufen und nichts berechnet. Die Meldung nennt das Feld, aber nicht die akzeptierten Werte, daher sind die Parametertabellen oben die Referenz.
Ein Aufruf, der erfolgreich ist und nichts findet, ist der Fall, über den man stolpert. Er kommt als normales Ergebnis an, mit requestMetadata.status auf ok und der Daten-Schlüssel fehlt einfach. Nichts im Textkörper sagt, dass das Ergebnis leer war. Teste auf das Feld, das du brauchst, nicht auf einen Fehler.
Eine Kennung, die die Plattform ablehnt, gibt 400 zurück, mit requestMetadata.status auf error. Ein Kanal-Handle, das nicht existiert, ist der übliche Weg, das zu sehen.
Ergebnisse mit Daten enthalten auch eine requestMetadata.id, die im Support wertvoll zu zitieren ist.
Preise, kostenloses Kontingent und Limits
Jedes YouTube-Tool kostet 10 Credits pro erfolgreichem Aufruf. Die Antwortgröße ändert den Preis nicht. Eine volle Seite mit Suchergebnissen kostet dasselbe wie eine Seite mit einem Video.
Die kostenlose Testversion umfasst 1.000 Credits über 30 Tage ohne Karte, also 100 YouTube-Aufrufe. Danach erhält ein aktives Konto weiterhin täglich 100 Credits aufgestockt, sobald sein Guthaben unter 100 fällt, sodass ein Agent mit geringem Volumen dauerhaft im kostenlosen Kontingent läuft.
Bezahlte Pläne beginnen bei 49 $ pro Monat für 200.000 Credits, also 20.000 Aufrufe. Der Stückpreis sinkt mit dem Volumen, von 2,45 $ pro 1.000 Aufrufen im Einstiegsplan auf 0,99 $ bei Business, 0,83 $ bei Growth und 0,75 $ bei den größten High-Volume-Plänen.
Dein Plan bestimmt auch die Parallelität. Die kostenlose Testversion erlaubt 1 Anfrage gleichzeitig, Startup 15, Business 30, Growth 50, und die High-Volume-Pläne laufen von 200 bis 1.500. Behandle den Überlauf-Fall in allem Unbeaufsichtigten defensiv, denn ein Agent, der sich aufteilt, erreicht die Obergrenze vor dir.
Eine Anfrage, die mit Nicht-200 zurückkommt, wird nicht berechnet. Ein erfolgreicher Aufruf, der nichts findet, ist trotzdem ein Aufruf.
Tool-Auswahl
Der Abfrageparameter apis entscheidet, welche Tools dein Agent sieht. Weniger Tools bedeutet weniger Kontext für Tool-Definitionen und weniger Chancen, dass das Modell zum falschen greift.
?apis=youtube the four tools in this repo
?apis=youtube,google_serp add Google search
?apis=youtube,tiktok,instagram a social research bundleDer Parameter akzeptiert Anbieternamen wie youtube und einzelne API-Namen wie google_maps_search. Falsch geschriebene Namen werden ignoriert. Wenn jeder Name falsch ist, schlägt die Anfrage mit 400 fehl, und der Textkörper listet sowohl das, was nicht erkannt wurde, als auch jeden gültigen Wert auf. Lasse den Parameter weg, und derselbe Endpunkt stellt alle 57 HasData-Tools bereit.
Vergleich
Gegenüber der offiziellen YouTube Data API v3:
YouTube Data API v3 | Dieser Server | |
Einrichtung | Google-Cloud-Projekt und ein API-Schlüssel | Ein Schlüssel und eine URL |
Suchkontingent | „Standard-Quotenzuteilung von 100 | Die Credits deines Plans, 10 pro Aufruf |
Transkripte von Videos, die dir nicht gehören |
| Ja, mit der Sprachliste |
Kapitel in Suchergebnissen | Nein | Ja |
Aufrufe und Likes in Suchergebnissen | Fehlen, und ein zweiter | Anzeigezeichenkette und Ganzzahl in derselben Antwort |
Kosten | Kostenlos innerhalb des täglichen Kontingents | Bezahlt nach der Testversion, 10 Credits pro Aufruf |
Schreibzugriff und private Daten | Uploads, Playlists, Kommentare und eigene Analysen über OAuth | Nur lesend, nur öffentliche Daten |
Die letzten beiden Zeilen sind wichtig. Wenn das tägliche Kontingent dein Volumen abdeckt und du den Kanal besitzt, den du abfragst, ist die offizielle API die günstigere Antwort, und du solltest sie nehmen.
Die meisten anderen YouTube-MCP-Server machen nur Transkripte. Dieser sucht auch, liest Videos mit ihren Engagement-Zahlen und durchläuft Kanal-Tabs, sodass ein Agent eine ganze Recherche-Runde ohne zweiten Server erledigt.
Was dieser Server nicht tut. Keine Kommentare, keine Kanalverwaltung, keine Uploads, keine Analysen, keine privaten Daten. Er liest, was ein abgemeldeter Besucher sehen kann.
FAQ
Gibt es einen offiziellen YouTube-MCP-Server?
Google veröffentlicht keinen. YouTube hat keinen First-Party-MCP-Server. Jede Option wird von jemand anderem gebaut, entweder um die YouTube Data API v3 oder um die öffentlichen Seiten herum. Dieser wird von HasData gepflegt und liest öffentliche Seiten, weshalb er keine Google-Anmeldedaten benötigt.
Was ist ein YouTube-MCP-Server?
Ein Server, der YouTube-Daten als Tools bereitstellt, die ein KI-Client aufrufen kann. Der Client sendet einen Tool-Aufruf über das Model Context Protocol, der Server ruft die Daten ab und gibt strukturiertes JSON zurück, und das Modell arbeitet mit dem Ergebnis und sieht nie eine HTML-Seite. Dieser stellt vier Tools bereit und läuft remote. Der Client verbindet sich mit einer URL und startet keinen lokalen Prozess.
Brauche ich einen YouTube-API-Schlüssel oder ein Google-Cloud-Projekt?
Nein. Die einzige Anmeldedaten sind dein HasData-Schlüssel. Es gibt kein Google-Cloud-Projekt zu erstellen, kein Quotenformular auszufüllen und keinen OAuth-Zustimmungsbildschirm, weil die Tools öffentliche YouTube-Seiten lesen und nicht die YouTube Data API.
Muss ich etwas hosten oder ausführen?
Nein. Dies ist ein Remote-MCP-Server über streamable HTTP. Nichts zu installieren, kein Container warmzuhalten, kein Prozess neu zu starten.
Sind die Daten live oder zwischengespeichert?
Live. Jeder Aufruf ruft die Seite zum Zeitpunkt der Anfrage ab und trägt seine eigene requestMetadata.id. Zwei identische Aufrufe sind zwei getrennte Abrufe und keine Wiedergabe einer gespeicherten Kopie. Zähler wie Aufrufe und Likes folgen der Seite, also bewegen sie sich, wenn sich die Seite bewegt.
Was passiert, wenn YouTube sein Layout ändert?
Auf deiner Seite nichts. Wir verfolgen die Änderungen und halten das Antwortschema stabil, sodass Feldnamen und Typen bleiben. Ein Feld ohne Wert fehlt im Element, es ist nicht vorhanden und null. Lies optionale Felder mit einem Standardwert.
Kann ich das zusammen mit anderen HasData-APIs verwenden?
Ja. Der Parameter apis akzeptiert eine Liste, und ?apis=youtube,google_serp gibt deinem Agenten die vier YouTube-Tools plus Google-Suche. Lasse den Parameter weg und du bekommst alles.
Kann ich für jedes Video ein Transkript bekommen?
Nur wo das Video eines hat, und availableTranscripts sagt dir, was existiert, bevor du fragst.
Kann ich mich mit OAuth anmelden, statt einen Schlüssel einzufügen?
Ja, in Clients, die das unterstützen. Claude Desktop und Cursor können den Endpunkt als Connector hinzufügen und sich anmelden. Unbeaufsichtigte Agenten und Skripte verwenden den x-api-key-Header.
Compliance und personenbezogene Daten
HasData greift ausschließlich auf öffentlich verfügbare Daten zu. Die Nutzungsbedingungen einer Plattform können den automatisierten Zugriff einschränken, und Sie sind für Ihre eigene Compliance verantwortlich. Wenn die von Ihnen erfassten Daten personenbezogene Informationen enthalten, stellen Sie sicher, dass Sie eine rechtmäßige Grundlage dafür gemäß GDPR, CCPA oder den entsprechenden Regelungen in Ihrer Rechtsordnung haben.
HasData-Links
Produktseite und Request-Builder | |
Server-Dokumentation | |
Alle 57 Tools in einem Server | |
Client-Walkthroughs | |
Alles andere, was wir scrapen | |
Pläne und Credit-Kosten | |
Schlüssel und Nutzung |
Entwicklung
Dieses Repository enthält Konfiguration und Dokumentation für einen Remote-Server. Es gibt keinen Build-Schritt und nichts zu containerisieren.
Die Tests in test/ prüfen den Tool-Vertrag, den Teil, der ohne einen Commit hier brechen kann. Sie prüfen, dass ?apis=youtube genau vier Tools zurückgibt, dass jedes Tool weiterhin seinen erforderlichen Parameter deklariert, dass sich kein Name geändert hat und dass der verwendete Schlüssel tatsächlich akzeptiert wird. Diese letzte Prüfung ruft ein Tool tatsächlich auf und kostet 10 Credits, was der Preis eines Canarys ist, der aus dem richtigen Grund fehlschlagen kann.
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm testDieselbe Suite läuft in CI bei jedem Push und einmal pro Woche planmäßig, da sich die Upstream-Tool-Liste ändern kann, ohne dass jemand dieses Repository anfasst. Ein Fehlschlag bedeutet, dass sich die Tool-Liste verschoben hat, der Schlüssel nicht mehr funktioniert oder der Endpunkt nicht erreichbar war, und die Assertion-Meldung sagt, welcher Fall eingetreten ist.
Mitwirken
Korrekturen an den Tool-Tabellen und den Antwortbeispielen sind der nützlichste Beitrag, weil dies die Teile sind, die abweichen. Fügen Sie den von Ihnen durchgeführten Aufruf und die erhaltene Antwort hinzu. Pull Requests von Forks führen die Suite ohne Schlüssel aus, und die Live-Prüfungen werden übersprungen, anstatt rot zu werden.
Lizenz
MIT. Siehe 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.43MIT
- 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-