Five interfaces expose one unofficial NotebookLM client
notebooklm-py provides 5 ways into the same service: an async Python API, CLI, MCP server, REST server, and agent skill. The shared client can create notebooks, add URLs or files, ask questions with citations, manage notes and sharing, run web or Drive research, and download generated results. That is much broader than a wrapper around the chat box.
The artifact surface is the main practical draw. One notebook can produce audio, video, slide decks, reports, quizzes, flashcards, infographics, tables, and mind maps, with structured downloads for several formats. Batch exports and source full-text access remove repetitive browser work. Google still performs the reading and generation, so the library automates NotebookLM rather than bringing its models or source index onto your machine.
Browser login adds about 170 MB before first use
The quickest CLI setup installs the browser extra with uv tool or pipx, then opens a Google sign-in. The README says first use downloads about 170 MB of Chromium. Python 3.10 through 3.14 is supported, and embedding the base library avoids Playwright. Other authentication paths can import browser cookies or use a master token for a headless server.
Those shortcuts carry a serious secret boundary. The security guide calls storage_state.json and master_token.json account-equivalent because one contains live cookies and the other can mint sessions. It recommends a dedicated account for unattended work, restrictive profile access, loopback-only browser-debug endpoints, and immediate revocation after suspected exposure. A remote MCP connector therefore needs more care than placing the command behind a tunnel.
What happened when we ran it
Our sandbox installed commit 558ab48 in 31 seconds. It added 132 Python packages and occupied 377 MB on disk. The build completed successfully in 7 seconds. The checkout itself was 107.1 MB with 1,842 files and about 534,077 lines of source.
Pytest did not finish within the 900-second cap. The last output showed ordinary progress dots reaching 76%, but no final passed, failed, or skipped count. The tail also did not name a failing case or an error. The test result is a timeout, and the supplied log does not establish whether one case stalled or the remaining suite simply needed more time.
Pip-audit found 0 known vulnerabilities in the installed dependency set. The repository had 13 CI workflow files, a tests directory, and no Dockerfile. Our test method used a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets.
Version 0.8.1 still depends on undocumented Google RPCs
Version 0.8.1 documents a stable public Python surface within a major version, yet the project remains in 0.x and may remove deprecated APIs in a later minor release. More importantly, Google gives this client no API stability promise, deprecation notice, SLA, or support. A renamed RPC method or changed response can become a patch release here and an immediate outage in your automation.
Quotas belong to Google accounts, not this package. The README warns that heavy use may be throttled, and its quota guide says live remaining counts and reset times are unavailable through known RPCs. Release v0.8.1 also raised the deep-research CLI wait default from 300 to 1,800 seconds. Scheduled jobs need explicit timeouts, partial-result handling, retry limits, and an owner who can inspect the account when a server response changes.
MCP and Claude Code access widen the credential boundary
The repository ships an MCP server and a Claude Code skill, and its installer can place instructions in both Claude and .agents skill directories. That makes a notebook useful as a cited project memory for coding agents. It also gives the agent tools that create, share, import, generate, download, and delete data. Confirmation gates and a dedicated Google profile should be part of the setup, especially for remote connectors.
Issue 2253 documents a redaction gap for newer Google API keys beginning with AQ. The reporter tested a synthetic key and explicitly said it was not evidence of a live leak. Open PR 2254 adds the missing pattern. Until that fix ships, operators who record RPC cassettes or log failure payloads should avoid placing such keys in the process and inspect diagnostics before sharing them.
29 open items accompany same-day source activity
The last source push was September 2, 2026, and GitHub listed 29 open issues and pull requests that day. Release v0.8.1 arrived on August 14 with collection support, richer citations, auth recovery work, and several compatibility aliases scheduled through v0.x. The small combined queue and same-day protocol investigation show active maintenance, although they cannot turn an undocumented upstream into a contracted API.
notebooklm-py is unusually capable for automating a consumer research product. The 31-second install, 0 audit findings, and detailed security documentation make a contained trial easy to justify. The 900-second test timeout and Google-owned protocol set the boundary: keep raw sources recoverable elsewhere, isolate credentials, pin the package, and design every scheduled or agent-driven run so a NotebookLM change can fail without taking the rest of the system with it.