Nblm

Servidor MCP de NotebookLM multicuenta, con cuenta y notebook pegajosos por sesión.

Está construido encima de notebooklm-py (MIT), que habla la RPC interna de NotebookLM (batchexecute) en vez de automatizar el DOM con un browser headless — por eso no se desloguea cada dos por tres. Este paquete no forkea esa base: la usa como dependencia y le pone encima sólo lo que le falta.

Por qué esto y no otro MCP de NotebookLM

Lo de multicuenta no es cosmético: una cuenta free de NotebookLM tiene ~50 consultas/día. Poder saltar de cuenta sin reiniciar el server es la diferencia entre seguir trabajando o parar.

Qué añade sobre las 33 tools de upstream

Cómo funciona por dentro: el cliente que ven las tools de upstream es un proxy (SwitchingClient) que apunta al perfil activo, y un middleware (StickyContext) rellena el notebook que falte. Cero cambios en las 33 tools originales, así que un uv sync -U trae las mejoras de upstream gratis.

Con más de una cuenta configurada, el middleware exige account_use antes de tocar nada — que es el flujo que se quiere: elegir cuenta → elegir/crear notebook → trabajar.

Dependencias

• Python ≥ 3.11
• uv para instalar y correr (instalación)
• notebooklm-py[mcp,browser,headless]==0.8.0rc1 — única dependencia directa; trae fastmcp, el cliente RPC, el CLI notebooklm y las 33 tools. uv la instala sola.
• Un browser (Chromium/Chrome) sólo la primera vez, para el login inicial de cada cuenta.
• Una cuenta de Google con acceso a NotebookLM.

Instalación

git clone https://github.com/Solar2004/nblm-mcp.git
cd nblm-mcp
uv sync

Alta de cuentas (una vez por cuenta, la corre el humano)

uv run notebooklm login --master-token --account [email protected]   -p personal
uv run notebooklm login --master-token --account [email protected] -p secundaria

--master-token = un sign-in en el browser y a partir de ahí re-mintea cookies solo, sin browser.

El master_token.json que queda en ~/.notebooklm/ es una credencial durable de tu cuenta de Google: trátalo como un secreto, no lo subas a ningún repo.

Comprobar que quedó bien: uv run nblm-mcp y llamar a la tool health, o directamente uv run notebooklm doctor.

Cablearlo a un cliente MCP

Claude Code (.mcp.json del proyecto, o claude mcp add), Claude Desktop (claude_desktop_config.json) y cualquier otro cliente stdio:

{
  "mcpServers": {
    "notebooklm": {
      "command": "uv",
      "args": ["run", "--directory", "/ruta/absoluta/a/nblm-mcp", "nblm-mcp"]
    }
  }
}

También habla HTTP si hace falta:

uv run nblm-mcp --transport http --host 127.0.0.1 --port 9421

Uso

Flujo típico desde el agente:

1. account_list() → account_use("personal")
2. notebook_list() → notebook_use("Mi investigación") (acepta título, prefijo único o id)
3. source_add(...) para meter fuentes, chat_ask(...) para preguntar
4. studio_generate(...) para audio, video, slide-deck, infographic, mind-map, report o quiz
5. studio_download(path=...) para bajar lo generado y leerlo del disco

Desde el paso 2 en adelante ya no hace falta pasar notebook en ninguna llamada.

Tests

uv run python test_server.py   # sin red: gate de cuenta, cambio de cuenta, inyección de notebook

Límites (heredados de la base)

• Usa una API interna no documentada de Google: puede romperse sin aviso.
• ~50 consultas/día en cuentas free (de ahí lo de multicuenta).
• research_import no es atómico.
• Estado en memoria del proceso: con stdio hay un proceso por sesión de agente, que es justo el alcance que se busca.

Licencia

MIT. La base notebooklm-py también es MIT. Proyecto no afiliado a Google ni a NotebookLM.