Most answers you will find say flatly "there is no API". That was true and is now wrong, which is worse than either.

What does the official API cover?​

Google documents a REST surface for Gemini Notebook Enterprise, including notebook operations and audio overviews — a notebook holds one audio overview at a time, created through notebooks.audioOverviews.create. It is marked pre-GA, which means the terms and the shape can both move.

The access path is the part people miss. It needs a Google Cloud project and a Gemini Enterprise or Education Premium licence, set up by an administrator. It is not a key you sign up for on a developer console, and it does not reach the notebooks in your personal account.

What about the Podcast API?​

Deprecated. Google is not allowlisting new customers for it. If a tutorial tells you to request access, that tutorial is out of date.

So what do people actually use?​

Community projects that drive the same interfaces the web app uses. There are several, in Python and in Node, exposing them as a CLI, as an MCP server, or as a local REST API. They work, they are fast, and they reach your own notebooks with your own login.

They also share one honest caveat: nothing about those interfaces is promised. Google can change them, and when it does the project breaks until someone fixes it. That has happened — the mid-2026 interface rebuild broke every such tool at once.

Which should you pick?​

Three questions settle it.

Do you have an enterprise licence and an administrator? Then use the official API. It is supported, it is the only route with a contract behind it, and nothing below competes with that.

Do you need your own personal notebooks? Then the official API is out, and a community tool is the only route that exists.

Do you need it to keep working unattended? Weigh how quickly the project you pick has recovered from past breakages. That is the only signal that matters, and the commit history tells you more than the README.

When is a community tool the wrong answer?​

• When the work is contractual — a client deliverable, a regulated pipeline, an SLA. An undocumented interface has no promise attached to it.
• When you only need text generation over documents. The Gemini API is public, supported and cheaper to reason about; NotebookLM's value is its grounding and citation behaviour, not its text generation.
• When you cannot run a browser anywhere. Login still happens in a real Chrome, once, even for the tools that avoid the browser afterwards.

Trying this one​

Our own route is both an MCP server and a local REST API, so an agent and a workflow tool can use the same install.

# Claude Code
/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields

# Then log into Google once, in a terminal
npx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth

Node 22 or newer. The REST route is in the install guide, and the full endpoint list is in the API reference.

Someone reported it. We fixed it, published the advisory, and then found a second hole of the same family a few weeks later. Here is what we learned, written down because the pattern is not ours alone — researchers scanning public MCP servers keep finding the same three mistakes.

What does binding to 0.0.0.0 actually allow?​

It means the server answers on your laptop's address on the local network, not just on localhost. On a home network that is your household. On café Wi-Fi, a conference network or a shared office, it is everyone within reach.

What they get is whatever your tools do. For us that was reading your notebooks, adding sources, generating content and sharing a notebook publicly. For other servers it has been arbitrary code execution — Penpot's MCP server and MCPJam's inspector both shipped unauthenticated execution endpoints bound to every interface.

The exposure is not exotic. A survey of reachable MCP servers found hundreds with this shape, and a large minority with no authentication mechanism at all.

Is binding to 127.0.0.1 enough?​

No, and this is the part that surprises people. A web page you visit can make requests to localhost from inside your browser. If the server answers them, the page is driving your tools with your session, from the outside.

That is not theory. CVE-2025-49596 in the MCP Inspector scored 9.4 precisely because a malicious site could reach a service listening only on loopback and get to code execution.

The defence is to refuse requests that carry a foreign origin, rather than merely declining to send a permissive header back. Those are different things: the second blocks the page from reading the reply, while the request still executes. For anything that writes, that distinction is the whole game.

What are the three controls?​

Bind to loopback by default, and fail loudly otherwise. Our server now refuses to start on a public interface unless a token is set. Not a warning — a refusal, because a warning in a log nobody reads is not a control.

Refuse foreign origins outright. Requests from an origin that is not allow-listed get a 403 before any handler runs, reads included.

Require a token when exposed, and compare it in constant time. The comparison detail is small but free: compare digests, not strings.

In a container the first rule inverts — a published port is useless on loopback — so the entrypoint binds to all interfaces and exits with an explanation if no token is set.

What was the second hole?​

File paths. Three of our tools take a path from the caller: one reads a file to upload, two write one. The data directory was an allowed root, and that directory holds the live Google session.

So a document could tell an agent to add the session file as a source, and another tool could then make that notebook public. Not a file leak — an account takeover, via a tool that looks like it only reads documents.

Three things made it work, and all three are worth checking in your own code:

• the path was checked before it was resolved, so the check applied to a string that was not what got opened;
• symlinks were never followed, so a link inside an allowed directory walked straight out of it;
• containment was a string prefix test, so /data-evil passed a check for /data.

What would we tell someone shipping an MCP server today?​

• Default to loopback. Make exposure a deliberate act that fails without a credential.
• Treat every caller-supplied path as hostile. An agent acts on text it was handed, so your tool arguments are reachable by whoever wrote that text.
• Check what your tools can reach, not just what they are for. Ours could reach the session that authorises them.
• Write the guard, then break it on purpose and confirm it fails. Two of ours did not bite on the first attempt.

When is this not your problem?​

If your server is stdio-only, it has no port and none of this applies. Most of the risk arrives with the HTTP transport, which people add for n8n or for a remote machine and then forget is listening.

Trying this one​

/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields

The full model, including what the container requires, is in the security page. Past advisories are listed there too.

The official route​

Google documents audio overview creation in the Gemini Notebook Enterprise API. A notebook holds one audio overview at a time, so a loop means creating notebooks, not stacking overviews.

It is pre-GA, and it needs a Cloud project plus an enterprise or education licence with an administrator to turn it on. If you have that, stop reading — it is supported and nothing below is.

The separate Podcast API that older tutorials point at is deprecated and not taking new customers.

Driving the browser​

The oldest community approach: a real browser clicks the same buttons you would. It works, it reaches your personal notebooks, and it is slow — minutes per generation, most of it waiting.

Its weakness is the web app. When Google rebuilt the interface in mid-2026, every selector moved and every browser-driven tool broke at once.

Driving the internal interface​

Newer tools call the same internal requests the web app makes, skipping the page entirely. Generation that took minutes through the browser takes seconds to kick off, and the result is read back directly rather than scraped.

It is immune to visual redesigns, because there is no selector to break. It is not immune to the interface itself changing, which is a different and rarer event.

Our own server does this first and falls back to the browser when the internal route does not answer — deliberately, because the two break for different reasons and rarely at the same time.

What actually bites in a loop​

You must own the notebook. Google refuses Studio generation on notebooks merely shared with you. The refusal arrives as a permission status buried in the response, which is easy to misread as "the identifier changed" — we lost two investigations to exactly that before reading the raw body.

One overview per notebook. Plan the loop around notebooks, not around generations.

Generation costs allowance. Usage is compute-based and refreshes every five hours. Audio is one of the expensive features, so a batch will hit the ceiling sooner than the same number of questions would.

The download is not the obvious URL. The media link serves a viewer page, not the file, so a naive fetch returns HTML that looks like a success.

When is this not worth automating?​

• For a handful a month. The web app is three clicks and no maintenance.
• When you need a specific voice, length or script. You get the format NotebookLM produces; a text-to-speech pipeline over your own script gives you control it does not.
• When the output is client-facing and must arrive on a date. An undocumented interface and a compute allowance are two reasons it might not.

Trying this one​

/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
npx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth

Generation, listing and download are covered in content management; the REST equivalents are in the API reference.

If you are feeding answers to anything downstream — a review, a database, an agent that must not invent — the citation is the part you actually need.

What does a citation contain?​

Two things worth separating. The source name tells you which document a claim came from. The excerpt is the passage itself, the few sentences the model drew on.

The first is cheap to get and almost always enough to audit an answer. The second is what lets a downstream reader judge without opening the source, and it costs more to obtain.

How do you get them out?​

Ask for a machine-readable citation format when you make the request. Our server takes a source_format on every question:

json is the one to use when something other than a person reads the result. expanded is the one for a human report.

Why is the excerpt harder than the name?​

Because of where each lives. Source names sit in the answer's markup and come back in one pass. Excerpts are revealed by opening each citation, which means asking for each one in turn and collecting what comes back.

That is slower, and it is why the two are separate options rather than one. If you only need to know which document answered, do not pay for the rest.

What do you do with them?​

The pattern we keep coming back to: write each answer, with its citations, as a document in a store you control — a vault, a table, a search index. Then query that store instead of re-asking.

It costs one pass through NotebookLM and nothing thereafter, which matters more since usage became a compute allowance rather than a query count. It also gives you something NotebookLM does not: a corpus of past answers you can search, diff and cite.

We emit those documents against a published schema so the shape does not drift between versions.

When is this not worth it?​

• When you are reading the answers yourself, in the app. The clickable markers are better than anything you would export.
• When the answer is a one-off. The citation machinery earns its keep over a corpus, not over a question.
• When you need page numbers or offsets. You get the passage and the source name, not a position in the original document.

Trying this one​

/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields

The request and response shapes are in the API reference; the storage pattern is in the RTFM integration page.

Two commands and one login.

What does the agent actually gain?​

Grounding, and a way to show its work. A NotebookLM answer comes back with the sources it used and the exact passages it drew on. For an agent that matters more than for a human reader: the agent can carry the citation into whatever it writes next, and you can check it without re-reading the corpus.

It also gains the Studio side — audio overviews, reports, mind maps, study aids — which it can trigger and then collect.

How do you install it?​

/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields

That registers the server and an agent skill that teaches Claude when to reach for it. Node 22 or newer.

Then log into Google once, in a terminal rather than through the agent:

npx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth

A visible Chrome opens, you log in, and the session is saved. Run it in a terminal because the login can take minutes and an MCP client will time the tool call out first.

Why is the login separate?​

NotebookLM has no developer key for personal accounts. Reaching your own notebooks means holding your own session, the way your browser does. That session lives on your machine, outside the project directory, and it survives restarts and days.

It also means the session is worth protecting, which is why the server listens on loopback and refuses to bind anywhere else without a token.

What does a first query look like?​

Ask the agent in plain language — "what do my notebooks say about X" — and let it pick the notebook. Under the hood it lists your notebooks, asks the question, and returns the answer with citations attached.

The one option worth knowing is the citation format. Ask for the machine -readable one when the answer feeds something else: you get the source names and the cited excerpts as data rather than as footnote markers in prose.

When is this not the right tool?​

• For code. NotebookLM reasons over documents, not over a repository. For code, a code-aware index serves the agent far better.
• For one quick question about one PDF. Attaching the file to the conversation is faster than curating a notebook.
• For unattended loops that must not stall. Usage is compute-based and refreshes every 5 hours; a long run can stop mid-way. Plan for it, or cache.
• For notebooks shared with you rather than owned by you. Google refuses Studio generation on those, and no client can work around it.

Upgrading later​

/plugin marketplace update roomi-fields
/reload-plugins

There is no /plugin update. Full setup, including Cursor, Codex and the REST route, is in the install guide.

This is not a dunk. It was good work, it taught the pattern everyone else copied, and the author said so plainly rather than letting it rot quietly.

Does an archived server stop working?​

Not immediately, and that is the trap. These tools drive interfaces Google does not document. They keep working until Google changes something, and then they stop — all at once, for everyone.

That happened in mid-2026, when the web app was rebuilt. Every project in this space broke the same week. The maintained ones shipped fixes; the others stayed broken.

So the question is not whether your install works today. It is who answers when it stops.

What are the alternatives?​

Several projects are active, in different shapes:

• A Python CLI plus MCP server, with the broadest coverage of the internal interfaces and the most contributors. If you work in Python, start there.
• A Node MCP server with a local REST API — ours. One install serves both an agent and a workflow tool over HTTP.
• A separate CLI-first project with a very large tool surface, which is worth knowing costs an agent context on every turn.

Pick on language, on whether you need HTTP, and on how fast the project recovered last time Google moved.

What moves when you switch from the archived one?​

Less than you would expect. Most of its tool names were copied by everyone after it, so an agent's habits largely carry over. In our case 17 of its 19 tool names work unchanged.

Two were renamed, because the thing they did grew: generating an audio overview became generating content of several kinds, and downloading audio became downloading content.

The trap worth knowing about​

One environment variable has the same name and a different meaning in different projects. In the archived server, the transport variable chose between the stdio and HTTP ways of talking to the client. In ours, it chooses between the internal-API and browser ways of talking to NotebookLM.

Copy a configuration across without reading it and you will set something real, that does something else, silently. Check every variable you carry over rather than assuming a shared vocabulary.

When should you not migrate at all?​

• If your install works and the work is finished. An archived tool that already produced what you needed owes you nothing.
• If you only ever ask one notebook one kind of question. The web app is right there, and it is better at that than any of us.
• If you have an enterprise licence. Google's own API is supported and nothing here competes with a contract.

Trying this one​

/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
npx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth

The tool-by-tool mapping, the environment variable table and the full feature comparison are on the migration page.

That is the whole idea, and it works. What is worth saying plainly is what it does not do, and what it asks you to hold on disk.

What rotation actually buys​

Since 2 September 2026, NotebookLM meters compute on a rolling five-hour window rather than counting chats per day. Rotation therefore multiplies a budget, not a quota.

The difference matters when you plan. With a daily count you could say "three accounts, 150 questions". With an allowance you cannot: the same three accounts carry a long conversation over forty sources far less far than they carry short, fresh questions.

What you get is continuity — the run does not stop at the first exhausted account — not a number to promise.

How does the switch work?​

The server keeps a session per account, notices the usage refusal, and moves to the next account that still has room. Each account has its own browser profile, so switching does not disturb the one currently in use.

Re-authentication mid-run works the same way: the session for that account is refreshed on its own profile, then promoted, rather than restarting everything.

Where do the sessions live?​

Not in the project directory. They sit in the operating system's application data directory, outside any repository by construction. That is deliberate — you do not want a live Google session inside something you might commit or copy.

One consequence surprises people: sessions do not travel. Copying cookies from one machine to another fails. Google binds them server-side to the device and address that created them, even when the local expiry says they are valid. Log in on the machine that will run the work.

Why that directory deserves care​

It holds live logins. Anything that can read it can act as you.

We learned this the uncomfortable way. Our own file-upload tool treated that directory as an allowed location, so a document could have told an agent to add the session file as a source — and another tool could then have made the notebook public. It is fixed, and the lesson generalises: check what your tools can reach, not only what they are for.

If you run several accounts, you are concentrating several logins in one place. Treat it accordingly.

When is rotation the wrong answer?​

• When you re-ask the same questions. Cache the answers instead. Paying twice across two accounts is still paying twice.
• When the accounts are not yours. Using colleagues' accounts to stretch an allowance is a policy problem before it is a technical one.
• When one paid plan would do. AI Plus doubles the allowance and AI Pro quadruples it, with one login to secure instead of three.
• When the work must be reproducible. Which account answered changes nothing about correctness, but it does complicate an audit trail.

Trying this one​

/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields

Adding accounts, inspecting their state and forcing a switch are covered in multi-account. Where sessions are stored, and how to move them, is in configuration.

That is the honest state. What follows is the workaround that actually automates the part people want: asking a question and getting a citation-backed answer into the workflow.

Why is there no connector?​

Because a connector needs an API with a key, and the consumer NotebookLM has neither. Google's documented API is the enterprise one, behind a Cloud project and an administrator. A connector built on it would serve the subset of users who could already script it.

What does the workaround look like?​

Run a small HTTP server on a machine your workflow can reach. It holds your Google session and exposes the operations as ordinary endpoints. Your workflow then uses the same HTTP node it would use for any other service.

In n8n that is one HTTP Request node: POST the question, read the answer and its citations out of the response, pass them to the next step. In Make and Zapier it is their generic webhook or HTTP action.

The answer arrives as data, so it can go to a sheet, a Slack message, a database row or a document, like anything else in the workflow.

Where does the server have to run?​

Somewhere the workflow engine can reach, which is the real constraint.

Self-hosted n8n on the same machine is the simple case: the server stays on loopback and nothing is exposed. Cloud-hosted n8n, Zapier or Make cannot reach your laptop, so you need the server on a host they can see — and at that point you are exposing an endpoint that holds a live Google session.

If you do that, set a token. Our server refuses to start on a public interface without one, which is deliberate: the failure is louder than a leak.

What is worth automating this way?​

The jobs where the answer is one step of several. A weekly digest that asks each notebook what changed. A support flow that answers from internal documentation with the passage attached. A research pipeline that files each answer with its citations into a table.

The pattern that pays best is answer-once-then-store. Usage is a compute allowance now, refreshed every five hours, so a workflow that re-asks the same question every run is spending for nothing.

When is this the wrong design?​

• When latency matters. An answer takes seconds, not milliseconds. Do not put it in front of a user who is waiting.
• When the workflow must never stall. The allowance can run out mid-run.
• When you would be exposing the server to the public internet just to reach a cloud workflow tool. Weigh that against moving the workflow instead.
• When a plain Gemini API call would do. If you do not need grounding in your own documents, you do not need any of this.

Trying this one​

git clone https://github.com/roomi-fields/notebooklm-mcp.git
cd notebooklm-mcp && npm install && npm run build
npx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth
HTTP_PORT=3000 node dist/http-wrapper.js

Node 22 or newer. The worked n8n flow is in the n8n guide; the full endpoint list is in the API reference.

Our own documentation said "50 queries per day, resets at midnight UTC" until this week. It was wrong, and we had been repeating it for months.

What is actually metered now?​

Not requests. Google's own wording is that limits are compute-based and depend on "the complexity of your prompt" and "the models and features you use". Chat length and the number of sources count too.

The practical consequence: two scripts issuing the same number of questions can consume wildly different amounts. A long conversation across forty sources is not the same purchase as forty short, fresh questions.

When does it come back?​

Every five hours, on a rolling window, until you hit a weekly ceiling. There is no daily reset and no fixed hour to wait for. The remaining balance and the reset time are shown in the app under Settings → Usage, and in the chat when you get close.

Paid plans multiply the allowance rather than changing the mechanism — two times on AI Plus, four on AI Pro, more above that.

What should change in a batch script?​

Stop counting. A counter that stops at 50 either stops too early or too late, and you cannot tell which.

Prefer short, stateless questions. Each one costs less than extending a conversation that carries its whole history. If you do not need the thread, do not open one.

Narrow the source list. Asking against the three relevant sources instead of the whole notebook is cheaper as well as more accurate.

Make the run resumable. The allowance will run out mid-batch sooner or later. A run that records each answer as it arrives loses nothing; a run that writes at the end loses everything.

Treat the refusal as a signal, not an error. When the server reports the limit, back off for the window rather than retrying immediately.

Does rotating accounts still help?​

Yes, with a caveat worth being clear about. Rotation moves work onto another account's allowance when the first runs out. It multiplies a budget, not a quota, and it does nothing about the fact that you can no longer predict how far that budget goes.

It is also a per-account login each time, with everything that implies for where those sessions live.

When is NotebookLM the wrong place for the work?​

• When you re-ask the same questions. Answer once, store the result, query your own store afterwards. Paying the allowance twice for the same answer is the most common waste we see.
• When you only need generation, not grounding. The Gemini API is public and supported, with limits you can plan against.
• When the deadline is fixed. A compute-based allowance with a weekly ceiling is not something to promise a delivery date on.

Trying this one​

/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields

The batch pattern, including how to cache answers so a re-run costs nothing, is in running a thousand questions. Account rotation is in multi-account.