Blog / 7 min read · 2026-10-15

Gemini Notebook MCP: Official and Community Options

Compare official Gemini Notebook connections, Enterprise API access and a community MCP server, including authentication, permissions and untested limits.

Choose the connection by what you need to control. For notebook work inside Gemini Apps, start with Google’s built-in connection. For an MCP client that needs to operate notebooks, a community connector is a separate option with different authentication and permissions. Enterprise users also have an official API path.

Review scope: 15 October 2026. We checked official documentation and the source and package metadata of one community implementation. We did not install it, sign in, connect an account or execute its tools. This is a comparison of documented paths, not a tested setup guide.

Which path fits your task?

These paths are not interchangeable. A Jupyter notebook is a place to run code; it is not the notebook service managed by the community connector.

The official Gemini Apps connection

Google documents using @Gemini Notebook in a chat or task thread. If a connection is needed, Gemini offers the connection flow; it can also be managed in Connected Apps settings. Documented actions include listing notebooks, answering questions, managing sources and creating, editing or deleting notebooks. Availability is still rolling out. Google’s connection guide

For ordinary notebook work within Gemini, this is the first path to investigate. The cited guide does not document a public MCP endpoint or an mcpServers setting. Its supported actions also include writes and deletion, so “official” does not mean “read-only.”

For source-analysis prompts after choosing your connection, see our Gemini Notebook templates.

The community MCP option: identify the actual package

We examined jacob-bd/gemini-notebook-mcp-cli, an unofficial project whose package and executable names retain “NotebookLM.” Its code targets the notebook web service, including notebook, source and chat operations.

The names above identify the reviewed artifact; they are not installation instructions. We checked the wheel hash against PyPI metadata and compared five selected source files with the release commit. That establishes limited artifact consistency, not a complete supply-chain or dependency audit. The package declares dependency ranges, so the version of the top-level package alone does not identify every dependency an installation would resolve. Release, PyPI version, package definition

Authentication uses a browser session

In the reviewed implementation, nlm login uses a managed browser to obtain Google session cookies. It is not a Gemini API-key login or an OAuth flow with narrowly selected Notebook scopes. nlm login --check validates credentials against the service; it is not an offline syntax check. Authentication documentation

The project supports file-based and protected credential storage. Protected storage depends on the operating system’s keyring facilities, so it should not be assumed to work in a headless SSH environment. The connector’s requests use internal web RPC endpoints, including a separate enterprise web route. Those routes are different from Google’s documented Enterprise REST API. Storage configuration, request routing

Default tools include changes and sharing

The server registers tools by default, including notebook creation, deletion and sharing. When notebook_share_public is called, omitting is_public requests public-link access. notebook_delete requires confirm=True. Installing the package alone does not call these operations. These capabilities are available by default, and a confirmation parameter is not permission isolation. A prompt saying “read only” does not remove them; review the actual tool surface before connecting an account containing private material. Notebook tools, sharing tools

There is an important configuration trap: NOTEBOOKLM_ENABLED_TOOLS re-enables tools hidden by the disabling settings. It is not an allowlist that disables every unlisted tool. A restricted setup needs explicit filtering and verification of the actual tools exposed to its client. Tool-filter implementation

Local transport does not provide a remote deployment plan

The default transport is stdio. The HTTP option defaults to a loopback address, with no built-in authentication; the server rejects external binding unless explicitly overridden. Do not treat a localhost example as an authenticated endpoint ready for a remote Gemini application. Server implementation

The reviewed release differs from the main branch

The main-branch snapshot checked on 15 October lists additional authentication fixes as unreleased: headless sign-in validation now requires a valid notebook API response, background recovery preserves newer saved credentials, and failed profile saves leave the legacy credential cache unchanged. The first change concerns the headless sign-in path; it does not mean release 0.15.5 performs no credential validation. Those entries are not evidence that release 0.15.5 includes the fixes. Recheck release status before evaluating it with an account. This review did not establish an exploitable vulnerability. Changelog snapshot

The official Enterprise API is a separate path

Google documents a Preview API for creating and managing enterprise notebooks. It uses Discovery Engine REST resources under a project and location, with OAuth authorization and Enterprise setup and access requirements. This is a relevant starting point for organizations that need an official integration. It does not establish equivalent API access for a personal notebook account, and it is not itself an MCP server. Enterprise notebook API documentation

What Gemini API remote MCP support actually connects

Google’s Interactions API documentation supports remote MCP through an mcp_server tool configuration. In this arrangement, the Gemini application is the client of the server you specify. The documented transport is Streamable HTTP, not legacy SSE. Gemini API documentation

That feature does not supply a Notebook server, export your notebook collection or authorize a community connector. You still need a suitable server with the required tools and access controls. Code running in Jupyter follows the same distinction.

What remains unverified?

For the community package, we have not verified installation, dependency resolution, login success, current service compatibility, tool-list filtering or credential recovery. We have not checked the persistence or quota effects of a query. Do not infer those results from source inspection.

If you need an installation recommendation rather than this path comparison, the next evidence should come from an isolated evaluation using a dedicated test account and disposable notebook content. Record the exact package and dependency versions, actual exposed tools and observed operations before describing the setup as working.

FAQ

Is Gemini Notebook MCP an official Google connector?

The community project reviewed here is unofficial. Google’s Gemini Apps connection and Enterprise API are separate official paths with their own access requirements.

Can a community MCP server add sources automatically?

The reviewed implementation exposes source-management tools. That is a code-level capability, not a successful end-to-end test or proof that the built-in Gemini Apps connection accepts that server.

Is the community server read-only by default?

No. Its default tool surface includes operations that modify notebooks and sharing. Tool filtering must be configured and checked; an instruction in a prompt is not a permission boundary.

Which option should I choose first?

Start with the built-in connection for notebook tasks inside Gemini Apps. Investigate the official API for an eligible enterprise integration. Consider the community route when an MCP client specifically needs notebook operations and you can evaluate its browser-session access and tool permissions.