Certo, funziona. Ed è una cosa stupida da fare.
Collegare Claude a NotebookLM è possibile e anche divertente, da un punto di vista sperimentale. Ma resta un'idea stupida: ecco perché e cosa fare invece.
⏱ Tempo di lettura stimato: 15 minuti
☕ Caffè necessari per arrivare alla fine: due, ma tieni pronto il terzo.
Quando il “collegalo e funziona” nasconde API non documentate, cookie estratti e termini di servizio ignorati
In rete circola da settimane un’ondata di tutorial entusiastici: “Collega Claude a NotebookLM in 10 minuti e cambia per sempre il tuo modo di fare ricerca”. I video si moltiplicano, i thread su X si accumulano, i Substack dedicati all’IA produttiva ne parlano come di una rivoluzione silenziosa.
L’idea è seducente: prendere Anthropic Claude, il motore di ragionamento migliore della categoria, e dargli accesso diretto alla RAG system più facile del mondo: Google NotebookLM, attraverso il Model Context Protocol, il nuovo standard aperto per l’interoperabilità tra agenti IA.
Sulla carta, funziona. In pratica, bisogna sapere cosa si sta facendo, perché sotto la superficie ci sono alcune cose che nessuno di quei tutorial menziona con sufficiente chiarezza.
E se una volta tanto posso anticipare le conclusioni generali: tra computer, cellulari e IA a basso costo, oggi ognuno di noi ha a disposizione una potenza di calcolo che sarebbe stata impensabile per la NASA, vent’anni fa. Prima di accendere i vostri device, accendete il cervello, leggete le istruzioni e le righe in piccolo dei disclaimer e se vi viene un dubbio, fermatevi.
Better safe, than sorry.
MCP: facciamo a capirci
Il Model Context Protocol1 è uno standard aperto introdotto da Anthropic nel novembre 2024. L’idea è semplice: definire un linguaggio comune che permetta a qualsiasi LLM2 di comunicare in modo strutturato con qualsiasi fonte dati o strumento esterno, eliminando la necessità di scrivere connettori custom per ogni combinazione possibile.
L’architettura prevede tre attori: l’host (per esempio Claude Desktop), il client MCP integrato nell’host come traduttore di protocollo, e il server MCP, il programma esterno che espone strumenti o dati specifici. La comunicazione avviene o via STDIO (per integrazioni locali) o via HTTP con Server-Sent Events (SSE) per connessioni remote.
Il risultato concreto è che in un anno MCP è diventato lo standard di fatto per il collegamento tra agenti IA e sistemi esterni. Al momento in cui scrivo si contano oltre 10.000 server MCP pubblicati, 97 milioni di download mensili dell’SDK e supporto nativo in tutti i principali ambienti: Claude, ChatGPT, Cursor, Gemini CLI, GitHub Copilot, VS Code.
Anthropic e la Linux Foundation
Il 9 dicembre 2025, Anthropic ha donato MCP alla Agentic AI Foundation (AAIF), un fondo diretto costituito sotto l’egida della Linux Foundation3 (nota personale: questa cosa mi ha fatto molto felice, forse c’è speranza).
La AAIF è co-fondata da Anthropic, Block e OpenAI, con il supporto di Google, Microsoft, AWS, Cloudflare e Bloomberg. È un punto importante che i titoli hanno spesso distorto: Google non è co-fondatore della AAIF, è un membro Platinum di supporto. La distinzione conta, perché chi co-fonda ha voce nelle decisioni strategiche, chi supporta contribuisce con le proprie risorse ma non interviene nella governance diretta.
Sono vecchio e cinico: so bene che la mossa di Anthropic non è stata filantropica. È stata una scelta di posizionamento strategico di prima categoria. La Linux Foundation ha decenni di esperienza nella gestione di infrastrutture open-source critiche come il kernel Linux, Kubernetes, Node.js e PyTorch. Portare MCP sotto quella governance vuol dire una cosa: nessun singolo vendor potrà mai controllare il protocollo. Non Anthropic, non OpenAI, non Google. È lo “USB-C dell’IA” che il CPO di Anthropic Mike Krieger aveva promesso: un’infrastruttura neutrale su cui tutti possono costruire senza timore di vendor lock-in4.
L’AAIF include tre progetti fondatori: MCP di Anthropic, Goose di Block (un framework open-source per agenti IA) e AGENTS.md di OpenAI (uno standard per fornire agli agenti di coding il contesto necessario a operare in modo affidabile su repository diversi).
Parallelamente, Google ha percorso un cammino simile con il suo protocollo Agent-to-Agent (A2A)5: annunciato in aprile 2025 e donato alla Linux Foundation il 23 giugno dello stesso anno all’Open Source Summit di Denver, con il supporto di AWS, Cisco, Microsoft, Salesforce, SAP e ServiceNow. Mentre MCP connette un agente a uno strumento, A2A connette agenti tra di loro, permettendo collaborazione e delega di compiti tra sistemi IA eterogenei. I due protocolli non sono in competizione: sono livelli diversi dello stesso stack infrastrutturale.
Lo so, vi siete già persi e state pensando di mollare l’articolo. Ma se state anche pensando di collegare Claude a NotebookLM o lo avete già fatto, è meglio se tenete duro.
NotebookLM non è così socievole (e fa bene)
A questa grande fiera del volemose bbene, condividemose i protocolli, NotebookLM non è stato invitato. Google non ha rilasciato un server MCP ufficiale per NotebookLM. Non esiste un’API pubblica documentata. Non esiste un endpoint autorizzato. NotebookLM usa API interne non documentate, e qualsiasi strumento che ci si aggancia può smettere di funzionare se Google modifica il backend — ragion per cui questi strumenti vanno trattati come tooling personale/sperimentale. Divertente vederli girare, ma meglio tenerli alla larga da qualsiasi ambiente produttivo.
Google ha pubblicato server MCP ufficiali per Google Maps, BigQuery e Google Compute Engine — servizi enterprise con governance chiara. NotebookLM, al contrario, è un prodotto orientato all’utente finale con una filosofia di privacy dichiarata: i dati caricati rimangono privati a meno che non si scelga di condividere un notebook, e NotebookLM non usa i dati caricati per addestrare modelli.
Questa scelta di non aprire un’API non è un’omissione tecnica. È una decisione deliberata di design della privacy. E aggira quell’assenza diventa automaticamente una zona grigia.
Le “ricette” di terze parti: cosa esiste, come funziona, cosa rischi
La comunità open-source ha risposto all’assenza di un’API ufficiale con creatività. Esistono oggi almeno quattro implementazioni attive che meritano analisi separata.
1. notebooklm-mcp-cli (jacob-bd)
Il progetto più maturo e completo (tu pensa gli altri…). Disponibile su PyPI e manutenuto attivamente, espone 29 strumenti MCP che permettono di creare notebook, aggiungere fonti (URL, YouTube, Google Drive, testo libero), gestire note, generare Audio Overview e molto altro. L’autore stesso dichiara con trasparenza: “Full transparency: this project was built by a non-developer using AI coding assistants” — un dettaglio che dice molto sulla natura del progetto, a metà strada tra prototipo brillante e software di produzione.
Funzionamento: il server interagisce con le API interne di NotebookLM usando cookie di autenticazione estratti dal browser (Chrome, Edge, Brave). Il comando nlm doctor diagnostica eventuali problemi di configurazione. Supporta profili multipli (es. “lavoro” e “personale”). Si integra con Claude Desktop, Claude Code, Cursor, Windsurf e altri client MCP.
Pro: completezza funzionale, documentazione buona, pacchetto unificato CLI+MCP, installazione semplificata tramite un file .mcpb per Claude Desktop.
Contro: usa API non documentate che possono rompersi senza preavviso; i cookie di sessione vengono memorizzati localmente in file JSON, esponendo credenziali Google a chiunque abbia accesso alla macchina; lo stesso README avverte “Use at your own risk for personal/experimental purposes”.
2. notebooklm-connector (LeeJuOh / claude-code-zero)
Un approccio radicalmente diverso e forse il meno pericoloso (se proprio non potete fare a meno di provarci, seguite questa strada). Questo plugin è progettato specificamente per Claude Code e richiede l’integrazione Chrome beta di Claude Code (Claude in Chrome extension v1.0.36+). Invece di chiamare API interne, automatizza direttamente il browser: naviga verso NotebookLM, inserisce le domande nell’interfaccia web e recupera le risposte con le relative citazioni.
Il vantaggio principale è che l’autenticazione non richiede gestione manuale dei cookie: finché l’utente è loggato nel browser, tutto funziona. Esiste un meccanismo di “coverage analysis”: se NotebookLM non copre tutti gli aspetti della domanda, il plugin invia automaticamente query di follow-up (fino a 3 round) per garantire la completezza della risposta.
Pro: non espone né memorizza credenziali; l’interfaccia che automatizza (UI web) è più stabile delle API interne; la coverage analysis riduce le risposte incomplete.
Contro: latenza significativa (30–60 secondi per query a causa del caricamento della pagina); funziona solo con Claude Code; richiede Chrome; disponibile solo per utenti con piano diretto Anthropic (Pro, Max, Teams, Enterprise).
3. notebooklm-mcp (PleasePrompto / TypeScript)
Un’alternativa Node.js-based che usa automazione browser con sessioni persistenti. L’autore stesso avverte che ha costruito funzionalità di “umanizzazione” (velocità di digitazione realistica, ritardi naturali, movimenti del mouse) per far sembrare l’automazione più simile al comportamento umano, ma non può garantire che Google non la rilevi o la blocchi. Consiglia di usare un account Google dedicato per l’automazione, non quello principale.
Questo avvertimento merita attenzione: un software progettato per simulare un essere umano al fine di eludere sistemi di rilevamento automatico è, per definizione, un tool in zona grigia rispetto ai termini di servizio.
Pro: sessioni persistenti, gestione di una libreria di notebook con tag e descrizioni, funziona su Claude Code, Codex e Cursor.
Contro: la filosofia di “umanizzazione” per eludere i sistemi di Google è eticamente discutibile e legalmente ambigua; rischio di blocco dell’account.
4. notebooklm-mcp-secure (Pantheon Security)
Un fork con focus dichiarato sulla sicurezza enterprise: si pubblicizza con 14 livelli di hardening, cifratura post-quantistica, log di audit e conformità a GDPR, SOC2. Aggiunge anche funzionalità opzionali tramite API Gemini (con chiave API separata) per ricerche avanzate. Interessante come esperimento, ma va detto: le affermazioni di “post-quantum encryption” per un tool che fondamentalmente aggira un’API non documentata meritano scetticismo metodologico. L’ho aggiunto all’elenco solo per dovere di cronaca.
Privacy: pensaci oggi o piangi domani
Il tema della privacy in queste integrazioni ha livelli multipli, e ognuno va esaminato separatamente.
Il primo livello è l’esposizione delle credenziali. I tool che estraggono cookie di sessione li memorizzano in file locali (tipicamente JSON o SQLite in cartelle come ~/.notebooklm-mcp-cli). Chiunque abbia accesso fisico o remoto alla macchina può leggere quelle credenziali e usarle per accedere all’intero account Google dell’utente. Non è un rischio teorico: è una superficie di attacco reale, che dipende interamente dalla sicurezza della macchina host.
Il secondo livello è la supply chain. Questi strumenti sono pacchetti Python e Node.js installati da repository pubblici (PyPI, npm). Un attacco di supply chain6 potrebbe esfiltrare silenziosamente i cookie o i contenuti dei notebook verso server terzi, senza che l’utente se ne accorga. Il fatto che il codice sia open-source riduce (non elimina) questo rischio: permette solo che chi lo usa possa controllarlo. Cosa che, se avete seguito un tutorial per collegare Claude a NotebookLM, sono certo non facciate.
Il terzo livello è il doppio vettore di esposizione dei dati. In un workflow Claude+NotebookLM, i documenti che carichi in NotebookLM vengono già processati da Google (con le sue policy di privacy). Quando poi interroghi quei notebook attraverso Claude, il testo delle risposte transita anche attraverso l’infrastruttura di Anthropic. Due fornitori, due set di condizioni, due superfici di esposizione. Per documenti sensibili — contratti, ricerche non pubblicate, dati paziente, segreti aziendali — questo raddoppio del perimetro non è mai banale.
Il quarto livello, spesso ignorato, è il rischio di tool poisoning7. Un server MCP locale gira con i privilegi dell’utente sulla macchina host. Un server malizioso o vulnerabile può essere usato per eseguire codice arbitrario, leggere file locali, o manipolare il comportamento del modello attraverso input costruiti ad hoc. L’infrastruttura MCP non ha, di default, un sandboxing forte: ci si affida alla reputazione del developer e all’audit del codice. Auguri…
No, non è una buona idea
L’integrazione Claude–NotebookLM tramite MCP di terze parti non è consigliabile come workflow professionale stabile, e ci sono ragioni precise per affermarlo.
Non è che l’idea sia sbagliata a priori. La complementarietà tra un sistema grounded su fonti (NotebookLM) e un motore di ragionamento generativo (Claude) è molto interessante. Il punto è che i mezzi disponibili oggi per realizzarla non reggono a un esame serio. Usare API non documentate che possono rompersi senza preavviso, estrarre cookie di sessione Google, o simulare input umani per eludere i sistemi di detection è, nel migliore dei casi, ingegneria precaria. Nel peggiore, è una violazione dei termini di servizio Google e un rischio di sicurezza concreto.
Per un ricercatore/hacker che vuole sfidare se stesso in un pomeriggio? Capibile e molto divertente.
Per un professionista che lavora su dati sensibili o un’organizzazione con policy di compliance? Assolutamente NO.
Alternative ne abbiamo?
La buona notizia è che ci sono percorsi stabili, sicuri e tecnicamente coerenti per costruire architetture simili senza appoggiarsi a strumenti sperimentali.
Opzione 1 — Claude Projects + Google Drive MCP ufficiale: Anthropic ha rilasciato una directory di oltre 75 connector ufficiali alimentati da MCP. Il server MCP per Google Drive è tra questi e funziona con autenticazione OAuth standard. Carichi i documenti su Drive, li rendi disponibili a Claude tramite quel connector, e ottieni un sistema grounded senza cookie estratti e senza API interne.
Opzione 2 — Claude Projects con knowledge base nativa: Claude Projects supporta il caricamento diretto di documenti all’interno di un progetto, che diventa la base di conoscenza della conversazione. Non è NotebookLM, ma per molti casi d’uso è sufficiente e la tua knowledge base viene gestita da un unico fornitore con policy chiare.
Opzione 3 — RAG locale: chi ha competenze tecniche può costruire una pipeline di Retrieval Augmented Generation completamente locale usando un vector store come Qdrant o Chroma, un embedding model locale (tramite Ollama), e Claude come interfaccia via MCP. Nessun dato esce dalla macchina. Zero dipendenza da servizi terzi.
Opzione 4 — Obsidian + MCP filesystem: per chi usa già Obsidian come sistema di gestione della conoscenza, il server MCP per il filesystem locale permette a Claude di leggere direttamente le note e il vault. È un sistema meno sofisticato di NotebookLM, ma completamente sotto controllo dell’utente. Io lo adoro.
Opzione 5 — Aspettare: l’evoluzione verso A2A e l’integrazione di NotebookLM in Google Workspace come servizio core suggerisce che nel medio termine Google potrebbe rilasciare un’API pubblica documentata. A quel punto, le integrazioni con Claude tramite MCP o A2A diventeranno stabili, sicure e conformi ai termini di servizio. Ma costruire oggi su API non documentate per poi migrare domani non è efficienza: è debito tecnico.
Una cosa piuttosto stupida.
Ma che c’avete fretta, c’avete?
Il quadro complessivo è quello di un settore in rapida convergenza verso standard aperti e governance condivisa. MCP e A2A sotto la Linux Foundation, AAIF come ombrello neutrale: tutti stanno scommettendo su un’infrastruttura non controllata da nessuno di loro. È la mossa giusta, e il ritmo di adozione, 97 milioni di download SDK mensili per MCP, dimostra che non è marketing.
NotebookLM è un prodotto eccellente. Claude è il migliore motore di ragionamento disponibile su modelli commerciali. La loro integrazione diretta e ufficiale sarà, probabilmente, una delle feature più potenti del prossimo anno. Ma “probabilmente il prossimo anno” non è “oggi, tramite cookie estratti e API fantasma”.
Nel frattempo, la domanda giusta non è come collegare Claude a NotebookLM. È perché farlo passando attraverso backdoor pericolanti.
Sitografia di riferimento
Anthropic. Donating the Model Context Protocol and establishing the Agentic AI Foundation. https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
GitHub. MCP joins the Linux Foundation: What this means for developers. https://github.blog/open-source/maintainers/mcp-joins-the-linux-foundation-what-this-means-for-developers-building-the-next-era-of-ai-tools-and-agents/
Google Cloud. Google Cloud donates A2A to Linux Foundation. https://developers.googleblog.com/en/google-cloud-donates-a2a-to-linux-foundation/
Google Workspace. NotebookLM and NotebookLM Plus — enterprise-grade data protection. https://workspaceupdates.googleblog.com/2025/02/notebooklm-and-notebooklm-plus-now-workspace-core-service.html
jacob-bd. notebooklm-mcp-cli (GitHub / PyPI). https://github.com/jacob-bd/notebooklm-mcp-cli
LeeJuOh. claude-code-zero / notebooklm-connector (GitHub). https://github.com/LeeJuOh/claude-code-zero/tree/main/plugins/notebooklm-connector
Linux Foundation. Formation of the Agentic AI Foundation (AAIF). https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
Linux Foundation. Agent2Agent (A2A) Protocol Project. https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents
Model Context Protocol Blog. MCP joins the Agentic AI Foundation. https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/
Pantheon Security. notebooklm-mcp-secure (GitHub). https://github.com/Pantheon-Security/notebooklm-mcp-secure
PleasePrompto. notebooklm-mcp (GitHub). https://github.com/PleasePrompto/notebooklm-mcp
MCP (Model Context Protocol): protocollo open-source sviluppato da Anthropic per standardizzare la comunicazione tra modelli linguistici e sistemi esterni (database, API, file system). Analogia comune: lo “USB-C dell’IA”.
LLM (Large Language Model): modello linguistico di grandi dimensioni, come Claude (Anthropic), GPT-4 (OpenAI) o Gemini (Google). Alla base dei moderni assistenti IA generativi.
AAIF (Agentic AI Foundation): fondo diretto costituito il 9 dicembre 2025 sotto la Linux Foundation. Co-fondatori: Anthropic, Block, OpenAI. Membri Platinum: Google, Microsoft, AWS, Cloudflare, Bloomberg. Gestisce MCP, Goose e AGENTS.md come progetti fondatori.
Vendor lock-in: dipendenza tecnologica da un singolo fornitore, che rende difficile o costoso cambiare. Uno standard aperto mira a eliminare questa dipendenza garantendo interoperabilità tra fornitori diversi.
A2A (Agent-to-Agent protocol): standard aperto sviluppato da Google per la comunicazione diretta tra agenti IA eterogenei. Annunciato in aprile 2025, donato alla Linux Foundation in giugno 2025. Complementare a MCP: mentre MCP connette agenti a strumenti, A2A connette agenti ad altri agenti.
Supply chain attack: attacco informatico che compromette non il software finale ma le sue dipendenze a monte (librerie, pacchetti npm o PyPI), permettendo l’iniezione di codice malevolo nel processo di installazione.
Tool poisoning: tecnica di attacco specifica all’ecosistema MCP in cui i metadati o gli schemi degli strumenti esposti da un server vengono manipolati per alterare il comportamento del modello, inducendolo a eseguire operazioni non autorizzate.