youtube-analytics-mcp

Ein MCP-Server, der einem KI-Assistenten die gesamte YouTube Analytics-, Data-v3- und Reporting-API-Oberfläche für Kanäle bietet, die du besitzt – einschließlich mehrerer Kanäle gleichzeitig.

Die meisten YouTube-MCP-Server kodieren eine Handvoll Metrik-Strings fest, sodass die erste Frage außerhalb ihrer vordefinierten Liste unbeantwortbar bleibt, ohne sie zu forken. Dieser ist andersherum aufgebaut: youtube_analytics_query akzeptiert jeden Parameter, den reports.query akzeptiert, und youtube_data_call / youtube_reporting_call tun dasselbe für die anderen beiden APIs. Die Voreinstellungen sind Annehmlichkeiten obendrauf, niemals der einzige Weg zu etwas.

Du bringst deinen eigenen Google-Cloud-OAuth-Client mit. Mit diesem Paket wird nichts ausgeliefert, keine Anmeldedaten passieren einen Dritten, und alles läuft lokal über stdio.

Tools

Jedes Datentool akzeptiert ein optionales account, sodass eine Konversation zwei Kanäle vergleichen kann.

Große Ergebnisse gehen in eine Datei, nicht durch das Modell

youtube_analytics_query, youtube_data_call und youtube_reporting_call akzeptieren outputPath (und optional format: csv oder json, sonst aus der Erweiterung abgeleitet). Damit wird das vollständige Ergebnis auf die Festplatte geschrieben und nur eine Zusammenfassung – Zeilenanzahl, Spalten, Bytegröße, erste drei Zeilen – kommt zurück. Ohne sie werden Ergebnisse über 100 Zeilen abgeschnitten mit einem Hinweis auf die Option, weil ein tausendzeiliger Bericht inline zurückgegeben den Kontextfenster des Aufrufers kostet und unlesbar ist, wenn er ankommt.

Für wirklich umfangreiche Arbeiten – jeden Tag jedes Videos, monatelang – verwende die Reporting API über youtube_reporting_call: Sie erzeugt herunterladbare tägliche CSV-Berichte mit Dimensionskombinationen, die reports.query nicht in einem einzigen Aufruf zurückgibt.

Related MCP server: YouTube MCP Server

Einrichtung

1. Ein Google-Cloud-OAuth-Client, einmalig

• Ein Projekt erstellen oder auswählen.

• APIs & Dienste → Bibliothek: YouTube Analytics API, YouTube Data API v3 und YouTube Reporting API aktivieren.

• OAuth-Zustimmungsbildschirm → Zielgruppe: Benutzertyp auf Extern setzen (Intern wird nur angeboten, wenn eine Workspace-Organisation angehängt ist). Auf derselben Zielgruppenseite unter Testnutzer auf + Nutzer hinzufügen klicken und das Google-Konto jedes Kanalinhabers hinzufügen – einschließlich deines eigenen.

  Wenn du das verpasst, schlägt die Zustimmung fehl mit "… hat den Google-Verifizierungsprozess nicht abgeschlossen. Die App wird derzeit getestet und kann nur von entwicklergenehmigten Testern aufgerufen werden." Projektinhaber zu sein macht dich nicht zum Testnutzer; du musst dich selbst explizit hinzufügen.

• Veröffentlichungsstatus auf Produktion setzen. Das ist wichtiger, als es aussieht. Google:

  Ein Google-Cloud-Platform-Projekt mit einem OAuth-Zustimmungsbildschirm, der für einen externen Benutzertyp konfiguriert ist und einen Veröffentlichungsstatus von "Test" hat, erhält ein Refresh-Token, das in 7 Tagen abläuft, es sei denn, die einzigen angeforderten OAuth-Bereiche sind eine Teilmenge von Name, E-Mail-Adresse und Benutzerprofil.

  Jeder YouTube-Bereich ist sensibel, also macht eine Test-App dich jede Woche neu autorisieren.

  Sei gewarnt, dass Veröffentlichen für diese Bereiche nicht einfach ein Schalter ist: Die Konsole wird wahrscheinlich ein Demo-Video verlangen und die App durch die YouTube-API-Verifizierungsprüfung schicken, bevor sie dich aus dem Testmodus lässt. Das ist echte Arbeit für ein persönliches Werkzeug, und wöchentliche Neuzustimmung ist oft der bessere Kompromiss. Siehe Die 7-Tage-Gewährungsgrenze unten für die Alternativen.

• Anmeldedaten → Anmeldedaten erstellen → OAuth-Client-ID → Desktop-App. Nicht Web Anwendung: Dieser Server lauscht bei jedem Lauf auf einem zufälligen freien Loopback-Port, und ein Web Client erfordert, dass jede Weiterleitungs-URI, einschließlich Port, im Voraus registriert wird.

• Das JSON herunterladen.

2. Dem Server mitteilen, wo der Client ist

Lege es in die Konfigurationsdatei (siehe config.example.json):

// %APPDATA%\youtube-analytics-mcp\config.json          (Windows)
// ~/Library/Application Support/youtube-analytics-mcp/  (macOS)
// ~/.config/youtube-analytics-mcp/config.json           (Linux)
{
  "client": { "client_id": "...", "client_secret": "..." }
}

Führe youtube-analytics-mcp --where aus, um dieses Verzeichnis zu drucken. Umgebungsvariablen funktionieren auch und haben Vorrang – YTMCP_CLIENT_ID + YTMCP_CLIENT_SECRET, oder YTMCP_CLIENT_FILE, das auf Googles Download wörtlich zeigt (der {"installed": …}-Wrapper wird für dich entpackt). YTMCP_CONFIG_DIR verlegt das gesamte Verzeichnis.

3. Jeden Kanal autorisieren

bun run auth                      # or: youtube-analytics-mcp --authorize
bun run auth -- --alias second    # name it yourself

Dein Browser öffnet sich automatisch auf der Zustimmungsseite; die URL wird auch gedruckt, für die Fälle, in denen das nicht möglich ist (SSH, Container, CI). Wähle das Google-Konto, das den Kanal besitzt, und genehmige. Wiederhole für jeden Kanal – wähle jedes Mal ein anderes Konto im Browser. Konten werden nach ihrem @handle benannt, es sei denn, du übergibst --alias.

Setze YTMCP_NO_BROWSER=1, um niemals einen Browser zu starten, oder übergib openBrowser: false an das youtube_authorize-Tool für einen einzelnen Aufruf.

Refresh-Tokens werden in accounts.json im selben Verzeichnis geschrieben, getrennt von der config.json, die du von Hand bearbeitest, sodass die Datei, die du in einen Fehlerbericht einfügen könntest, niemals die Datei ist, die Tokens enthält. Beide werden mit 0600 geschrieben, wo die Plattform das unterstützt.

Dein Assistent kann das auch steuern. youtube_authorize gibt die Zustimmungs-URL sofort zurück und hört im Hintergrund weiter zu; youtube_authorize_status meldet, wie es endete. Es blockiert nicht, weil Zustimmung so lange dauert wie ein Mensch braucht und MCP-Clients bei einem Tool-Aufruf lange vorher aufgeben. Die URL wird auch in pending-auth.txt im Konfigurationsverzeichnis geschrieben, da die meisten Clients den stderr eines Servers verwerfen und eine URL, die niemand lesen kann, nutzlos ist.

4. Bei deinem MCP-Client registrieren

Claude Code:

claude mcp add youtube-analytics --scope user -- bunx youtube-analytics-mcp

Oder von Hand, in der mcpServers-Map eines beliebigen Clients:

{
  "mcpServers": {
    "youtube-analytics": { "command": "bunx", "args": ["youtube-analytics-mcp"] }
  }
}

Standardmäßig schreibgeschützt

Das Aktualisieren eines Videos, das Posten oder Moderieren von Kommentaren und das Hochladen von Thumbnails sind auf einem Live-Kanal nicht umkehrbar, daher wird der Schreibbereich nicht angefordert und Nicht-GET-Aufrufe werden abgelehnt. Um sie zu aktivieren, setze YTMCP_ALLOW_WRITE=1 und autorisiere erneut – das Flag allein tut nichts, weil das gespeicherte Token den Bereich nicht trägt.

Gleichzeitige Zuschauer und die Abfrageform, die niemand errät

averageConcurrentViewers und peakConcurrentViewers funktionieren auf beendeten Streams, und sie stimmen exakt mit Studios eigenen Zahlen überein. Es wird weithin geglaubt, dass sie nicht existieren, weil die API sie in jeder Form außer einer ablehnt: Der Filter muss ein einzelnes Video festlegen und dimensions muss livestreamPosition sein.

Kein Fehler nennt die fehlende Dimension, und insbesondere der 500 liest sich so, als wäre die Metrik kaputt, nicht die Anfrage falsch. youtube_concurrent_curve setzt das für dich zusammen und gibt den Peak, den Mittelwert und die gesamte Minute-für-Minute-Kurve zurück.

Was es wirklich nicht liefern kann

youtube_capabilities gibt die aktuelle Liste zurück. Beide wurden überprüft, indem man nach der Metrik fragte und Unknown identifier zurückbekam, was die API so unterscheidet: einen Namen, den sie noch nie gehört hat, von einem, den sie kennt, aber hier nicht bedienen kann:

• Live-Chat-Nachrichten- und Reaktionssummen. Nur Studio. liveChatMessages liest einen Chat in Echtzeit und kann einen beendeten nicht wiederherstellen.

• Impressionen und Impression-Klickrate. Nur Studio, im Reichweiten-Tab.

Zwei Dinge, die man wissen sollte

Es gibt kein "seit Veröffentlichung"-Fenster. Die Analytics-API ist rein datumsbereichsbasiert, also ein Fenster, das einen Stream-Tag abdeckt, gibt das Live-Publikum dieses Streams konstruktionsbedingt zurück. Studios Standardfenster pro Video schließt die gesamte Live-Periode aus, was eine einfache und teure Falle bei der Analyse von Live-Streams ist. Diese API kann nicht hineinfallen.

Analytics-Kontingent ist getrennt. Die Analytics- und Reporting-APIs messen unabhängig vom täglichen Einheitenbudget der Data API v3, also verbraucht das Abfragen hier nicht das Kontingent, um das Live-Chat-Polling konkurriert. Starke Schlussfolgerung daraus, dass es sich um separate APIs mit eigenen Konsolen-Kontingentseiten handelt – nicht gemessen.

Entwicklung

bun install
bun run dev          # start on stdio
bunx tsc --noEmit    # typecheck
bun run inspector    # MCP Inspector

MIT.

Die API hinkt ein paar Tage hinterher

Finalisierte Analytics-Daten sind nicht sofort verfügbar. Gemessen am 2026-08-25 liefen Tag-Dimension Zeilen bis 08-22 und stoppten: Sitzungen aus den vorherigen drei Tagen gaben überhaupt keine Zeilen zurück, nicht null Zeilen. Eine Abfrage für einen Stream, der vor Stunden endete, sieht aus wie ein Kanal ohne Verkehr.

Studios Web-UI hat einen Echtzeitpfad, den die API nicht offenlegt, also die Berichterstattung für denselben Tag muss weiterhin aus Studio kommen. Verwende diesen Server für alles, was älter als ungefähr drei Tage ist, wo er weit besser ist, als durch Studio ein Video nach dem anderen zu klicken.

Die 7-Tage-Gewährungsgrenze und warum kein Code sie umgehen kann

Während der Veröffentlichungsstatus des Cloud-Projekts Test mit einem externen Benutzertyp ist, widerruft Google Refresh-Tokens nach 7 Tagen, es sei denn, die einzigen angeforderten Bereiche sind Name, E-Mail und Profil. Jeder YouTube-Bereich ist sensibel, also gilt die Ausnahme hier nie.

Das kann nicht automatisiert werden. Die 7 Tage gelten für das Refresh-Token. Ein neues zu prägen erfordert, dass ein Mensch einen Zustimmungsbildschirm in einem Browser genehmigt – das bedeutet Zustimmung, nicht eine Lücke, die man umgehen kann. Häufigeres Aktualisieren von Zugriffstokens berührt das nicht.

Was dieser Server stattdessen tut:

• youtube_accounts meldet das ageDays jeder Gewährung und warnt ab Tag 5.

• Eine abgelaufene Gewährung schlägt fehl mit einer Meldung, die Ursache und Lösung nennt, nicht nur ein nacktes invalid_grant.

• youtube_refresh_tokens (oder --refresh von der CLI) übt jede Gewährung als Gesundheitscheck aus. Es ist auch eine Absicherung: Es ist nicht festgestellt, ob die 7-Tage-Uhr absolut ab Ausstellung ist oder bei Nutzung gleitet. Wenn sie gleitet, hält das tägliche Ausführen auf einem Zeitplan Gewährungen unbegrenzt am Leben; wenn nicht, kostet der Aufruf fast nichts. Es lohnt sich, es so oder so auszuführen.

• Erneute Zustimmung ist ein Aufruf an youtube_authorize, der den Browser selbst öffnet – etwa fünfzehn Sekunden.

Die echten Lösungen, in der Reihenfolge der Kosten:

1. Veröffentlichungsstatus → In Produktion. Kostenlos, und Berechtigungen laufen nicht mehr ab. Für sensible YouTube-Bereiche kann Google ein Demo-Video und eine Verifizierungsprüfung verlangen, bevor du veröffentlichen darfst, was für ein persönliches Tool einiges an Arbeit bedeutet.

2. Interner Benutzertyp. Keine 7-Tage-Grenze und keine Verifizierung, aber die Option existiert nur, wenn das Projekt zu einer Google Workspace-Organisation gehört — einem kostenpflichtigen Abonnement.

3. Live mit wöchentlicher erneuter Zustimmung. Für ein Einzelbenutzer-Tool ist das oft die richtige Antwort.