Claude Code + NotebookLM: Wie die MCP-Anbindung zum externen Langzeitgedächtnis wird

Claude Code und Google NotebookLM ergänzen sich zu einem produktiven System: NotebookLM dient als externer Wissensspeicher mit Quellen-Zitationen und offizieller Ein-Million-Token-Kontextschicht von Gemini, Claude Code als ausführendes Werkzeug für Code, Automatisierung und Artefakt-Generierung. Die Verbindung läuft über das Model Context Protocol (MCP) in Kombination mit einer inoffiziellen Python-Bridge (notebooklm-py des Entwicklers Teng Lin), da Google bisher keine öffentliche API für NotebookLM anbietet. Die Einrichtung dauert nach Community-Angaben wenige Minuten. Daraus ergeben sich Workflows wie Wrap-up-Sessions ins Langzeitgedächtnis, automatisierte YouTube-Recherche, geplante Research-Routinen mit Präsentations-Decks oder App-Prototypen auf Basis kuratierter Quellen.

Was bringt die Kombination aus Claude Code und NotebookLM?

Beide Tools haben eine spezifische Schwäche. Claude Code verfügt über starke Reasoning- und Coding-Fähigkeiten, leidet aber unter dem klassischen Amnesie-Problem: Nach jeder Session beginnt das Modell wieder bei null, und große Kontextfenster kosten Token. NotebookLM dagegen speichert je nach Plan 50 bis 600 Quellen pro Notebook, liefert Antworten mit Zitationen aus den eigenen Dokumenten und ist im Free-Tier nutzbar. Dafür kann NotebookLM keinen Code schreiben, keine komplexen Aufgaben ausführen und keine Artefakte außerhalb seiner eigenen Oberfläche erzeugen. Die Verbindung beider Tools ergibt ein Setup, das in der Community als Second Brain oder externes Langzeitgedächtnis bezeichnet wird. Claude Code übernimmt die Rolle des Prozessors, NotebookLM die der externen Festplatte. Halluzinationen werden reduziert, weil Antworten in kuratierten Quellen gegroundet sind und jede Aussage bis zu einer Zitation zurückverfolgbar bleibt.

NotebookLM als RAG-Schicht

NotebookLM arbeitet nach dem Prinzip von Retrieval-Augmented Generation (RAG): Große Dokumente werden intern aufbereitet und bei einer Abfrage zusammen mit Quellen-Zitationen zurückgeliefert. Das skaliert in der Praxis besser als das reine Befüllen eines Kontextfensters, da lange Kontexte unter dem „Lost-in-the-middle"-Effekt leiden, bei dem die Aufmerksamkeit des Modells in der Mitte messbar sinkt. Seit Oktober 2025 steht in NotebookLM offiziell das volle Ein-Million-Token-Kontextfenster von Gemini zur Verfügung (9to5Google). Die Quellenlimits sind gestaffelt: 50 Quellen pro Notebook im Free-Tier, 300 in Plus, 600 in Ultra. Pro Einzelquelle erlaubt Google bis zu 500.000 Wörter oder 200 MB Upload (Google Support).

Claude Code als ausführendes Werkzeug

Claude Code läuft im Terminal, besitzt Lese- und Schreibzugriff auf Dateien, kann Skills laden und über MCP-Connectors mit externen Diensten sprechen. Seit dem Release der HTTP-Hooks lassen sich zusätzlich Drittanbieter-APIs direkt anbinden. Typische Kombinationen: Supabase für Datenbank und Auth, Pinecone für Vektorsuche, Vercel für das Frontend-Deployment.

Wie funktioniert die MCP-Anbindung technisch?

Die Verbindung läuft über das Model Context Protocol, einen von Anthropic veröffentlichten Standard für den Zugriff von Sprachmodellen auf externe Datenquellen und Tools. Google hat bisher weder eine öffentliche NotebookLM-API noch einen offiziellen MCP-Server dafür veröffentlicht. Die Community schließt diese Lücke mit inoffiziellen Bridge-Skripten. Zentrales Projekt ist notebooklm-py des Entwicklers Teng Lin. Das Paket beschreibt sich selbst als „inoffizielle Python-API und Agentic Skill für Google NotebookLM" und greift nach eigener Aussage auf undokumentierte Google-Endpunkte zu, die sich jederzeit ändern können. Nach dem Login-Befehl öffnet sich ein isolierter Chrome-Browser für die einmalige Google-Anmeldung. Das Skript extrahiert die Session-Cookies und nutzt sie anschließend für Hintergrund-Requests. Nach der Ersteinrichtung spielt sich alles im Terminal ab. Hinweis: Dieses Verfahren bewegt sich in einer rechtlichen Grauzone und dürfte in Konflikt mit den Google-Nutzungsbedingungen stehen. Eine belastbare juristische Einordnung steht aus; dieser Artikel ersetzt keine Rechtsberatung. In der Community wird daher durchgehend ein dedizierter Google-Dummy-Account empfohlen, um das Hauptkonto von einer möglichen Sperrung auszuschließen. Die Bridge funktioniert mit Claude Code, der Claude-Desktop-App und der Gemini CLI, nicht aber mit der Web-Version von Claude.

Welche Tools und Bausteine gehören zum Setup?

Die vollständige Integration besteht aus mehreren Komponenten, die je nach Workflow kombiniert werden: - notebooklm-py: Python-Bridge zwischen CLI-Tools und NotebookLM. Kernstück der Anbindung und Grundlage für alle weiteren Workflows. - Skills (.md oder .workmd): Markdown-Dateien mit Instruktionen, die Claude Code zeigen, wie bestimmte Aufgaben ausgeführt werden sollen. Beispiele: ein Wrap-up-Skill für Session-Zusammenfassungen, ein Slide-Deck-Skill mit festen Brand-Farben, ein YouTube-Search-Skill. - yt-dlp: Kommandozeilen-Tool zum Abgreifen von YouTube-Metadaten und vollständigen Video-Transkripten. In Kombination mit einem Custom-Skill landen Videos damit automatisiert als Quellen in NotebookLM. - Ergänzende MCP-Connectors: Für produktive App-Workflows erweitern offizielle MCPs die Kette. Supabase übernimmt Datenbank und Auth, Pinecone die Vektorsuche, Vercel das Frontend-Deployment.

Wie läuft die Einrichtung ab?

Community-Tutorials und Video-Demos geben eine Setup-Dauer von wenigen Minuten an, abhängig von vorhandener Python-Umgebung und Berechtigungen. Der typische Ablauf folgt fünf Schritten: 1. Tool-Manager und Python-Bridge via Terminal installieren. 2. Die entsprechende Skill-Datei in die Claude-Code-Instanz laden. 3. Den Befehl notebooklm login ausführen. Ein isolierter Chrome-Browser öffnet sich für die einmalige Google-Anmeldung. 4. Die MCP-Konfigurationsdatei (MCP.json) anpassen und weitere Connectors eintragen. 5. Claude Code neu starten und die Verbindung mit einer Test-Query validieren, zum Beispiel: „Nenne die letzten drei Notebooks." Hinweis: Nach erfolgreichem Login bleibt der Cookie lokal gespeichert. Solange die Session gültig ist, läuft die gesamte Kommunikation headless im Hintergrund.

Welche Workflows sind mit der Integration realisierbar?

Wrap-up-Skill: Claudes Langzeitgedächtnis

Am Ende einer umfangreichen Session wird der Wrap-up-Skill aktiviert. Claude komprimiert den Chatverlauf, extrahiert Entscheidungen, To-dos und zentrale Erkenntnisse und legt die Zusammenfassung als neue Quelle in einem dedizierten Notebook ab (oft „Jack's brain" oder ähnlich benannt). In zukünftigen Sessions lässt sich dieser Speicher gezielt abrufen, ohne den Kontextpuffer zu fluten. Das reduziert Token-Kosten deutlich und macht ein konsistentes Projektgedächtnis über Monate hinweg praktikabel.

Automatisierte YouTube-Recherche mit Infografik-Export

In einer in Community-Demos gezeigten Kette stößt ein einzelner Prompt-Kickoff die Kette an: Claude Code durchsucht YouTube via yt-dlp, sammelt Video-URLs zu einem Keyword (im Free-Plan bis zur Quellen-Obergrenze von 50), schiebt diese Quellen in ein frisches NotebookLM-Notebook und lässt dort die Analyse laufen. Die anschließende Infografik-Generierung nutzt Nano Banana Pro, das Google offiziell in NotebookLM integriert hat (Google Workspace Updates). Die rechenintensive RAG-Analyse läuft offsite auf Google-Infrastruktur. Claude Code verbraucht dabei nur Tokens für Steuerung und Rückgabe, die konkrete Token-Ersparnis hängt stark vom Prompt-Design ab.

Tägliche Cron-Jobs für Research-Routinen

Sowohl über lokale Scheduled Tasks als auch über die neueren Remote Tasks von Anthropic lassen sich wiederkehrende Aufträge automatisieren. Ein Beispiel: Jeden Tag um 12 Uhr recherchiert Claude aktuelle Cybersecurity-Trends, lädt die Fundstücke als Quellen in NotebookLM, lässt dort ein Slide-Deck im vorgegebenen Brand-Design generieren und legt das Ergebnis im Projektordner ab. Lokale Cron-Jobs laufen nur bei eingeschaltetem Rechner. Remote Tasks erfordern ein GitHub-Konto mit hochgeladenem Workspace und laufen auf Anthropics Infrastruktur weiter, auch wenn der Rechner aus ist.

Atlas-Framework: Vom Podcast zur App in 25 Minuten

Der aufwendigste Use Case kombiniert alle Bausteine und wurde von Content-Creatorn aus der Community als Demo dokumentiert. In ein NotebookLM-Notebook werden wissenschaftliche Quellen geladen: stundenlange Podcasts von Andrew Huberman und BJ Fogg, Artikel von James Clear, Reviews bestehender Habit-Tracking-Apps. Claude Code liest diese kuratierten Erkenntnisse via MCP aus, leitet daraus die Feature-Liste einer Habit-Tracking-App ab (Habit Stacking, Dopamin-Architektur, Environment Design), schreibt den Code für ein MVP mit Vite und React 19, richtet das Supabase-Backend inklusive Row-Level-Security ein und deployt das Frontend auf Vercel. In einer dokumentierten Demo lag die Laufzeit bei rund 25 Minuten nach einem Prompt-Kickoff. Wie stabil solche End-to-End-Ketten in produktiven Projekten laufen, hängt stark von Prompt-Qualität, Skill-Definition und Test-Aufwand ab; reine Demo-Ergebnisse lassen sich nicht direkt als Produktivitätskennzahl übernehmen.

Welche Grenzen und Risiken bestehen?

Die inoffizielle Natur der Anbindung bringt drei zentrale Risiken mit sich: - Fragilität: notebooklm-py nutzt nach eigener Aussage undokumentierte Google-Endpunkte. Ein UI- oder API-Update auf Google-Seite kann die Bridge jederzeit brechen, bis die Community ein Patch veröffentlicht. - Compliance-Unsicherheit: Der Zugriff über extrahierte Cookies steht mutmaßlich in Konflikt mit den Google-Nutzungsbedingungen. Eine abschließende rechtliche Bewertung existiert nicht; ein Dummy-Account wird in der Community durchgehend empfohlen. - Quellenlimits: Die Obergrenze pro Notebook hängt am Plan: 50 im Free-Tier, 300 in Plus, 600 in Ultra. Für großvolumige Rechercheprojekte im Free-Plan wird das schnell zur Bremse. Hinzu kommt eine Workflow-Einschränkung: Textabfragen und Zitationen laufen stabil im Terminal. Für medial aufbereitete Artefakte sind Download-Funktionen in notebooklm-py zwar dokumentiert, in der Praxis wird die Weboberfläche aber häufig zur finalen Kontrolle und Nachbearbeitung geöffnet. Eine vollständig headless ablaufende Produktions-Pipeline ist damit nicht durchgängig etabliert.

FAQ: Häufig gestellte Fragen zu Claude Code und NotebookLM

Gibt es einen offiziellen MCP-Server von Google für NotebookLM? Nein. Google hat bisher weder eine öffentliche NotebookLM-API noch einen offiziellen MCP-Server dafür veröffentlicht. Die gesamte Community-Integration basiert auf inoffiziellen Bridge-Skripten, primär notebooklm-py des Entwicklers Teng Lin, das über undokumentierte Google-Endpunkte arbeitet. Funktioniert die Integration auch mit Claude im Browser? Nein. Die Anbindung setzt lokalen Shell-Zugriff voraus und funktioniert ausschließlich mit Claude Code, der Claude-Desktop-App sowie der Gemini CLI. Die Web-Version von Claude unterstützt keine lokale Bridge. Warum ein Dummy-Account? Die Authentifizierung erfolgt über extrahierte Session-Cookies eines echten Google-Logins. Dieses Vorgehen entspricht nicht den offiziellen Nutzungsbedingungen von Google. Ein dediziertes Dummy-Konto schützt das Hauptkonto vor einer möglichen Sperrung und isoliert die inoffizielle Integration vom produktiven Google-Workspace. Was kostet die Kombination? NotebookLM ist im Free-Tier mit 50 Quellen pro Notebook und dem vollen Ein-Million-Token-Kontextfenster von Gemini nutzbar, Plus und Ultra erhöhen die Quellen-Grenze auf 300 bzw. 600. Claude Code wird über das Anthropic-Abo abgerechnet. Die RAG-Analysen laufen auf Googles Infrastruktur und verbrauchen keine Anthropic-Tokens, was die Token-Last auf Claude-Seite für die reine Steuerung reduziert. Die konkrete Kostenersparnis hängt vom Workflow und von der Größe der verarbeiteten Quellen ab. Was sind Skills in diesem Kontext? Skills sind Markdown-Dateien mit Anweisungen für Claude Code. Sie enthalten Prompt-Vorlagen, Design-Regeln (etwa Brand-Farben für Slide-Decks), Skript-Pfade und Beispielaufrufe. Claude lädt sie beim Start und nutzt sie als Playbook für wiederkehrende Aufgaben. Welche Alternativen gibt es zur Python-Bridge? Für einzelne Use Cases lassen sich Google-Drive-MCPs, direkte RAG-Systeme in Claude (über Supabase und Pinecone) oder spezialisierte Research-Agenten wie Perplexity via MCP einbinden. Keine dieser Alternativen erreicht aber die Kombination aus Free-Tier-Kontextgröße, automatischer Chunking-Qualität und Multimodal-Output-Generierung, die NotebookLM bietet. Lassen sich Ausgaben von NotebookLM direkt in Claude Code abrufen? Textantworten und Zitationen kommen direkt ins Terminal zurück. Für medial aufbereitete Artefakte wie Audio-Overviews, Mindmaps, Videos oder Infografiken dokumentiert das notebooklm-py-Repo Download-Funktionen in mehreren Formaten. In vielen Community-Demos werden diese Outputs zur finalen Prüfung trotzdem in der NotebookLM-Weboberfläche geöffnet, weil die UI zusätzliche Styling- und Export-Optionen bietet.

Fazit

Die Kopplung von Claude Code und NotebookLM entschärft Claudes Kontextproblem, indem externe Quellen über eine RAG-Schicht nachgeladen werden. Das ersetzt kein unbegrenztes Gedächtnis, reduziert aber Token-Last und Halluzinationen gegenüber einer reinen Claude-Lösung. Die Community-Bridge ist inoffiziell, stützt sich auf undokumentierte Google-Endpunkte und sollte im Produktivbetrieb nur mit Dummy-Account und realistischer Fragilitäts-Erwartung eingesetzt werden. Für verwandte Ansätze eignen sich der Artikel zu Claude Code + Obsidian als Second Brain sowie der Überblick zu AI Harnesses im Vergleich.