Which integrations are available for this server?

Provides tools for interacting with Google NotebookLM, allowing AI agents to manage notebooks, add sources, and query notebook content.

How do I use notebooklm-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@notebooklm-mcp Create a new notebook called 'Meeting Notes'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

notebooklm-mcp

by Agustinfacu01

Overview Schema Related Servers Score Discussions

TypeScript

Local

notebooklm-mcp

An MCP (Model Context Protocol) server that lets Claude interact with Google NotebookLM via browser automation.

Usage

npx notebooklm-mcp@latest

Related MCP server: notebooklm-mcp-2026

Setup

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "notebooklm": {
      "command": "npx",
      "args": ["-y", "notebooklm-mcp@latest"]
    }
  }
}

VS Code / Cursor / Cline

{
  "mcp": {
    "servers": {
      "notebooklm": {
        "command": "npx",
        "args": ["-y", "notebooklm-mcp@latest"]
      }
    }
  }
}

Authentication

On first run, a Chrome browser window opens automatically. Log in to your Google account and navigate to NotebookLM. The session is saved to ~/.notebooklm-mcp/session so you only need to log in once.

Environment Variables

Variable	Default	Description
`NOTEBOOKLM_HEADLESS`	`false`	Set to `true` to run browser headless (requires existing session)
`NOTEBOOKLM_USER_DATA_DIR`	`~/.notebooklm-mcp/session`	Path to Chrome profile for persistent sessions

Available Tools

Tool	Description
`list_notebooks`	List all notebooks in your account
`create_notebook`	Create a new notebook
`open_notebook`	Open a notebook by title or ID
`add_source`	Add a URL or text source to the open notebook
`query_notebook`	Ask a question and get an AI response
`get_notebook_info`	Get title and sources of the open notebook
`delete_notebook`	Delete a notebook

Example Prompts

"List my NotebookLM notebooks"
"Create a notebook called 'Research Notes'"
"Open the 'Research Notes' notebook and add this URL as a source: https://example.com/paper"
"Ask the notebook: What are the key findings?"

Requirements

Node.js 18+
A Google account with access to NotebookLM

License

MIT

Available Tools

7 tools

add_sourceB

Add a source to the currently open notebook. Sources can be a public web URL or arbitrary text content.

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes	'url' to add a web page by link; 'text' to paste raw text content.
`content`	Yes	The URL (e.g. https://example.com/article) or the text content to add as a source.

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fails to disclose behavioral traits such as error handling when no notebook is open, idempotency, side effects, or return value. This leaves the agent uninformed about critical runtime behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but omits important behavioral details. It could be restructured to include essential context without adding length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should explain the return value or confirmation of success, which it does not. It also lacks information on prerequisites beyond 'currently open notebook.'

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds no new parameter meaning beyond what the schema provides. The description's mention of 'public web URL or arbitrary text content' mirrors the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Add a source'), the resource ('to the currently open notebook'), and the types of sources (URL or text). It distinguishes itself from sibling tools which handle notebook creation, deletion, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (requires an open notebook) and the two input types. However, it lacks explicit guidance on when to use versus alternatives or edge cases like no open notebook.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_notebookA

Create a new, empty notebook in Google NotebookLM with the given title. The newly created notebook becomes the currently active notebook.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title for the new notebook (1–200 characters).

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the notebook becomes active but does not mention behavior on duplicate titles, permissions, or other side effects. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff, front-loaded with the action verb. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description covers creation and activation. Could optionally mention return value or duplicate handling, but current completeness is good for a single-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds no new semantics beyond 'with the given title' and the character limit already in the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new empty notebook in Google NotebookLM with a given title. Verb 'create' and resource 'notebook' are specific, and the note about it becoming active distinguishes it from sibling tools like list_notebooks or open_notebook.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates when to use (when a new notebook is needed) but does not provide explicit guidance on when not to use or contrast with alternatives like open_notebook for existing notebooks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_notebookA

Permanently delete a notebook by its title or ID. This action cannot be undone.

ParametersJSON Schema

Name	Required	Description	Default
`title_or_id`	Yes	The title or ID of the notebook to delete.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It clearly states the deletion is permanent and cannot be undone, which is the key behavioral trait. However, it does not mention potential prerequisites (e.g., notebook must exist, cannot be open) or side effects beyond irreversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, both front-loaded with essential information. No extraneous words or rephrasing of the tool name. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete tool with one parameter and no output schema, the description is complete. It explains the action, the parameter, and the irreversible nature. The sibling tools cover other operations on notebooks, so no further context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is 100% with a description for the only parameter. The description adds context by stating 'by its title or ID', which clarifies the parameter's purpose. This adds value beyond the schema, but not significantly, as the schema already has a description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (permanently delete), resource (notebook), and how to specify it (by title or ID). It is distinct from sibling tools like create_notebook, get_notebook_info, list_notebooks, open_notebook, query_notebook, and add_source, which all have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for deletion but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives or prerequisites are mentioned. The context from sibling tools helps, but the description itself lacks explicit guidelines.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_notebook_infoA

Retrieve metadata about the currently open notebook: its title, the number of sources, and the list of source titles/URLs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It accurately describes what metadata is returned and implies a read-only operation. However, it could explicitly state that no side effects occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is front-loaded with the action and includes all relevant details. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description fully enumerates the return values (title, source count, source titles/URLs). For a simple read tool with no parameters, this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is 100% (empty). The description adds no input meaning, but none is needed. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Retrieve' and the resource 'currently open notebook', specifying exact metadata items (title, number of sources, list of source titles/URLs). It effectively differentiates from siblings like list_notebooks or open_notebook.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving metadata of the currently open notebook, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_notebooksA

List all notebooks available in the user's Google NotebookLM account. Returns notebook titles and IDs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It states the operation is a list and returns data, but does not explicitly confirm it is read-only or mention any side effects, auth requirements, or rate limits. The safe nature is implied but not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the action and resource. Every word is necessary; no redundancy or verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description adequately conveys the purpose and return values. It could mention potential pagination or ordering, but for a simple list tool it is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters in the input schema (100% coverage trivially). The description adds value by specifying the return content (titles and IDs), which helps the agent understand output without an output schema. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List'), resource ('notebooks'), and scope ('all...in the user's Google NotebookLM account'). It distinguishes from siblings by being the only tool that returns a list of all notebooks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (for retrieving a list of notebooks), but does not explicitly specify when to use this tool over alternatives, nor does it mention scenarios where it should not be used. No prerequisites or conditions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

open_notebookA

Open an existing notebook by its title or ID. The opened notebook becomes the currently active notebook for subsequent tool calls.

ParametersJSON Schema

Name	Required	Description	Default
`title_or_id`	Yes	The exact title or the NotebookLM notebook ID of the notebook to open.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explains the state change (active notebook) but omits details about error handling, permissions, or whether it is a read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the action and effect, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter tool and lack of output schema, the description adequately covers purpose and effect, though it could mention default return behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description only reiterates 'by its title or ID', adding no new meaning beyond the schema's parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool opens an existing notebook using title or ID, distinguishing it from sibling tools like create_notebook or delete_notebook.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool sets the active notebook for subsequent calls, but does not explicitly state when to use it versus alternatives or provide exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_notebookA

Ask a question to the currently open notebook and receive the AI-generated answer that is grounded in the notebook's sources.

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes	The question to send to the notebook's AI chat.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the answer is AI-generated and grounded, but does not mention side effects (e.g., AI quota usage) or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema, the description is mostly complete. It assumes a 'currently open notebook' state, which could be explicitly linked to open_notebook, but it's adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage for the single parameter with a clear description. The tool description adds no new semantics beyond 'ask a question'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Ask', the resource 'currently open notebook', and the outcome 'AI-generated answer grounded in sources'. It effectively distinguishes from siblings like open_notebook or add_source.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies the notebook must be open first but does not explicitly state this prerequisite or contrast with alternatives like open_notebook. Some guidance is present but insufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv1.0.0Jun 25, 2026
- First observedadd_source
- First observedcreate_notebook
- First observeddelete_notebook
- First observedget_notebook_info
- First observedlist_notebooks
- First observedopen_notebook
- First observedquery_notebook

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct action: creating, deleting, opening, listing notebooks; adding sources; querying; getting info. No overlap in functionality, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., create_notebook, add_source, query_notebook), making the interface predictable.

Tool Count5/5

With 7 tools, the set covers the core operations for NotebookLM management without being overly large or too sparse, perfectly scoped for the domain.

Completeness4/5

The tools cover CRUD-like operations for notebooks and basic source management and querying. Minor gaps like the inability to remove a source or rename a notebook exist but do not severely hinder the main workflow.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214

Related MCP Servers

notebooklm-mcp
Note Taking Research & Data Audio Processing
gracelee087
A
license
A
quality
C
maintenance
An unofficial MCP server for Google NotebookLM that enables users to manage notebooks, add sources, ask questions with citations, and generate audio podcasts via a Playwright-based automation layer.
Updated 5 months ago (2026-04-22 22:49 UTC)
19
MIT
notebooklm-mcp-2026
Note Taking Research & Data
Faxtom
A
license
Not graded
quality
C
maintenance
MCP server for querying Google NotebookLM notebooks, enabling AI assistants to list notebooks, read sources, and ask questions about them.
Updated 2 months ago (2026-07-22 04:12 UTC)
MIT
notebooklm-mcp
AI & Machine Learning Education & Learning Tools Research & Data
mulyg
A
license
Not graded
quality
D
maintenance
An MCP server that gives Claude (and any MCP-compatible agent) full access to Google NotebookLM — create notebooks, upload sources, ask questions, and generate audio overviews, quizzes, flashcards, mind maps, slide decks, videos, and reports.
Updated 5 months ago (2026-03-31 07:48 UTC)
1
MIT
notebooklm-mcp
Note Taking Search Knowledge & Memory
rinaldops
A
license
Not graded
quality
A
maintenance
MCP server for Google NotebookLM that allows asking questions to notebooks and managing notebook libraries via browser automation (Patchright). Designed for use with Claude Code and any MCP client.
Updated 2 months ago (2026-06-27 03:38 UTC)
4,624
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Agustinfacu01/npx-notebooklm-mcp-latest'

If you have feedback or need assistance with the MCP directory API, please join our Discord server