notebooklm-mcp-cli: driving Gemini Notebook from a shell or an AI agent

The gap this fills: Gemini Notebook has no public API

Gemini Notebook is a web product. The README describes this project as providing programmatic access to it through two surfaces: a command-line interface and a Model Context Protocol server. There is no mention of an official Google API that the tool calls instead. The value proposition is therefore narrow and concrete. If your research material lives in Gemini Notebook and you want it created, queried or exported by something other than a browser tab, this package is one of the few routes available.

The audience follows from that. The CLI examples are aimed at people who script: list notebooks, create one, add a URL as a source, generate a podcast, download the audio, export every artifact into a directory. The MCP half is aimed at people who drive an AI assistant and want that assistant to reach into a notebook. The README shows setup subcommands for claude-code, claude-desktop, gemini, github-copilot, cursor, cline and antigravity, plus a generic json output for anything else. Those are two different users with two different reasons to care, and the project serves both from one package.

One Python package, two front ends, one MCP tool per operation

The architecture visible in the README is flat. A single PyPI distribution, notebooklm-mcp-cli, installs an nlm executable. The CLI subcommands and the MCP tools map onto each other almost one to one, which the feature table makes explicit: nlm notebook list corresponds to the notebook_list tool, nlm notebook create to notebook_create, nlm source add to source_add, nlm notebook query to notebook_query, and the chat commands to chat_list, chat_get and chat_export. That symmetry matters for anyone deciding how to integrate. You are not choosing between two implementations with different capabilities; you are choosing a transport.

One detail in that table is worth pausing on. The row for querying a notebook says the result persists to the web UI. That tells you the tool is not maintaining a private index or a shadow store. It is writing through to the same session state a browser would see, which is what makes the CLI useful for mixed workflows and also what makes it dependent on the web product's own behaviour. Source types are listed as URL, text, Drive and file, so ingestion is not limited to pasted links. Studio content is generated through commands such as nlm audio create, and artifacts are addressed by an identifier when downloaded, as in nlm download audio <notebook> --id <artifact-id>. The README also mentions an nlm --ai flag that prints comprehensive AI-assistant documentation, which is a sensible way to keep agent-facing instructions in the binary rather than in a separate doc that drifts.

Installing it and wiring an MCP client

The README does not show a pip install line in the material provided, but the package is published on PyPI as notebooklm-mcp-cli and the executable is nlm, so the usual Python packaging path applies. What the README does show is the MCP registration step, and it is deliberately tool-specific rather than a single generic command. You run nlm setup add followed by the client name: claude-code, claude-desktop, gemini, github-copilot, cursor, cline or antigravity. For a client not on that list, nlm setup add json emits a JSON config you paste yourself.

Daily use from a shell looks like the examples in the README. nlm notebook list enumerates notebooks. nlm notebook create "Research Project" makes one. nlm source add <notebook> --url "https://..." attaches a source. nlm audio create <notebook> --confirm generates a podcast, and the --confirm flag implies the command otherwise stops short of committing, which is a reasonable guard for an operation that consumes generation quota. nlm download audio <notebook> --id <artifact-id> fetches a single file, while nlm download all <notebook> -d ./exports pulls everything into a directory. Sharing is a separate verb: nlm share public <notebook>.

There is also a doctor command. The README references it in a demo titled Setup, Doctor & mcpb, and given how much of this tool's reliability depends on which account type and which host you are pointed at, that is the first command worth running after setup.

The authentication and host story is the weak point

This is where the project is honest and where you should be cautious. The README states that personal and consumer accounts are tested regularly, and that Gemini Notebook Enterprise support is experimental. It goes further: the documented notebook.cloud.google.com host has been live-verified with a project-qualified global deployment, and other Enterprise host variants may require additional validation. Read that as a boundary rather than a caveat. If you are on a consumer account, the maintainer is exercising that path routinely. If you are on Enterprise, you are on a path the README describes as experimental, with at least one known-good configuration and an open question about the rest.

There is a second structural risk that the README implies without stating. The tool automates a web product through whatever interface it can reach. Nothing in the material suggests a contract with Google that guarantees endpoint stability. A change to the notebook UI, to session handling, or to how artifacts are identified could break commands without any version bump here. The --id <artifact-id> pattern in nlm download audio is a small illustration: the CLI needs an identifier that originates from the web product, so the two are coupled by design. Version 0.11.2 is labelled a security release, which is a reminder that this layer sits between your credentials and a third party service and needs to be updated on its own schedule, not only when a feature you want appears.

When a general-purpose browser automation stack is the better fit

The obvious alternative for anyone who needs Gemini Notebook driven programmatically is to automate the browser directly, with Playwright or Selenium, rather than depend on a third-party wrapper. The difference in approach is not cosmetic. A browser automation script owns its own selectors and session handling, so you control exactly which requests are made and can adapt the moment the page changes. This project instead asks you to trust its maintainer to track those changes and ship a release. You trade control for not having to maintain the adapter.

That trade is worth taking when your use is close to the documented command set: create a notebook, add sources, query, generate and download artifacts. It is a worse trade when you need something the feature table does not cover, because you will be extending someone else's abstraction over an interface that is not published. If your requirement is durable, vendor-blessed programmatic access to a research corpus, the honest answer is that neither this project nor a Playwright script gives you that, and you should be looking at a product with a documented API instead of routing around the absence of one.

Licence, maintenance and the cost of staying current

The repository is MIT licensed, which is permissive and imposes no copyleft obligation on your own code. This is not legal advice, and the licence covers the code in this repository, not your relationship with Google or the terms attached to the Gemini Notebook account you point it at. Those are separate questions and the README does not address them. Treat the MIT grant as covering the wrapper only.

Maintenance cost is the more practical concern. The release history in the material shows v0.11.0, v0.11.1 and v0.11.2 within roughly two days in September 2026, with the last one marked as a security release. That cadence tells you the maintainer is actively reacting to something, whether upstream changes or reported issues. For a consumer of the package it means upgrades are not optional background noise. Pinning a version and forgetting it leaves you exposed if a security fix lands, and upgrading on every release means re-verifying that your own scripts still behave. The README notes the project is built in the maintainer's spare time and asks for coffee donations, which is a straightforward signal about resourcing: there is no support contract behind this. Budget for the possibility that a breaking upstream change goes unfixed for a while, and keep your own thin wrapper around the nlm commands you depend on so a change in flags does not ripple through every script.

What to verify before you build on it

Start with nlm doctor, then run nlm notebook list against the account you actually intend to use. If that account is Enterprise, the README's own wording tells you to expect friction, so test the specific host and project configuration you have rather than assuming the verified global deployment matches yours. Next, exercise the exact commands your workflow needs, not the ones in the README. The feature table is a list of capabilities, not a statement that every path is equally tested, and the Enterprise note is evidence that the project distinguishes between what is exercised regularly and what is not.

The MCP side deserves its own check. Run nlm setup add for your client, confirm the generated configuration points where you expect, and then verify that the tool names you plan to call (notebook_list, notebook_create, source_add, notebook_query, chat_list, chat_get, chat_export) are actually exposed in that client. If you are scripting rather than chatting, the CLI is the more predictable surface, since you can inspect exit behaviour directly. Whichever you choose, keep the artifact identifiers your workflow depends on somewhere durable, because nlm download audio needs an --id that comes from the notebook side, and losing track of it means going back to the web UI you were trying to avoid.

Editorial conclusion

Adopt it if you already keep research in Gemini Notebook and want a shell pipeline or an MCP client to create notebooks, add URL or Drive sources, run queries and pull generated audio without touching the web UI. Do not adopt it if you need a vendor-supported API, an enterprise SLA, or if your organisation cannot tolerate an automation layer that talks to an undocumented consumer endpoint. Before committing, run nlm doctor, confirm which host your account resolves to, and check whether the commands you depend on in the feature table are documented as tested or as experimental.

Official sources

1. Issues
2. jacob-bd/gemini-notebook-mcp-cli on GitHub
3. License: MIT
4. README
5. Releases