Connect AI agents to Google NotebookLM, enabling querying notebooks, adding sources, generating reports, podcasts, slide decks, and more.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@notebooklm-py-diet-mcp Generate a slide deck from my research notes using the corporate template."
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.
Connect your AI agent to Google NotebookLM. Query your notebooks, add sources, generate reports, podcasts, slide decks, and more -- directly from Cursor, Claude Code, or any MCP-compatible client.
Workflow-orientated MCP toolset for IDE level interaction with NotebookLM. Designed as a smart and lightweight MCP server to enable AI code assist-native multi-step workflows (research, generate artifacts, download and convert). Packaged as single tool calls so the agent gets more done with less messing around and without losing capability.
Built on notebooklm-py by Teng Lin.
Unofficial -- Uses undocumented Google APIs via notebooklm-py. Not affiliated with Google. APIs may change without notice.
Need granular control over every SDK method? See the full-fat notebooklm-py-MCP (72 individual tools exposed - designed primarily for testing).
This server is not just a thin wrapper. It adds capabilities that the underlying API does not provide:
Templated slide generation -- Three bundled design templates (Corporate, Educational, Creative) in templates/slide_styles.md. Pass any template as the instructions parameter to generate_and_download and NotebookLM will follow the specified tone, colour palette, typography, and layout rules. Create your own templates using the same structure.
PDF / PNG round-trip editing -- pdf_to_png splits a downloaded slide deck (or any PDF) into individual page images that an LLM can review, critique, or annotate. png_to_pdf reassembles edited pages back into a single document. This enables a generate-review-refine loop that is not possible through the NotebookLM interface alone.
Inline persona control -- ask_question accepts optional persona and response_length parameters, configuring the chat persona in the same call rather than requiring a separate configuration step.
Related MCP server: notebooklm-mcp-server
Tool | Description |
| List all notebooks with IDs and titles |
| Create a new notebook |
| List all sources in a notebook |
| Add multiple sources (URL, text, file) in a single call |
| Query a notebook with optional persona, source filtering, and threading |
| Generate and download an artifact in one step (report, audio, slide deck, quiz, infographic) |
| List artifacts in a notebook |
| Export an artifact to a file |
| Research a topic and import results as sources automatically |
| Show the active account and available profiles |
| Switch to a different Google account profile |
| Create a new account profile and launch browser sign-in |
| Convert a PDF to individual PNG images (one per page) |
| Combine PNG images into a single PDF document |
URI | Description |
| List all notebooks (read-only) |
| Notebook details including sources |
Prompt | Description |
| Template for analysing notebook sources by theme |
| Guided research workflow using NotebookLM tools |
| Generate a slide deck using a bundled design template (corporate, educational, creative) |
Python 3.10 or later
A Google account with access to NotebookLM
Cursor or another MCP-compatible client
git clone https://github.com/earlyprototype/notebooklm-py-diet-mcp.git
cd notebooklm-py-diet-mcppython -m venv venv
# Windows (PowerShell)
.\venv\Scripts\Activate.ps1
# macOS / Linux
source venv/bin/activate
pip install -e ".[dev]"Alternatively, install from requirements.txt:
pip install -r requirements.txtplaywright install chromium# Set the account profile directory
# Windows (PowerShell)
$env:NOTEBOOKLM_HOME = "$HOME\.notebooklm-work"
# macOS / Linux
export NOTEBOOKLM_HOME=~/.notebooklm-work
# Login (opens a browser window -- select your Google account)
notebooklm login
# Verify
notebooklm listAdd the following to your .cursor/mcp.json file:
{
"mcpServers": {
"notebooklm": {
"command": "<path-to-venv>/python",
"args": [
"<path-to-repo>/notebooklm_mcp_server.py"
]
}
}
}Replace the placeholder paths with your actual paths. The server manages account profiles internally -- no NOTEBOOKLM_HOME environment variable is needed. Use switch_account and get_account_info to manage profiles at runtime.
Restart Cursor after saving the configuration.
The repository ships a project-scoped .mcp.json, so opening this folder in Claude Code is enough -- it will prompt you to approve the notebooklm server on first launch. It defaults to the venv/ created in step 2; on Windows, or if your interpreter lives elsewhere, point NOTEBOOKLM_MCP_PYTHON at it:
# Windows (PowerShell)
$env:NOTEBOOKLM_MCP_PYTHON = "venv\Scripts\python.exe"To register the server globally instead (available in every project), pass the absolute path to the virtual environment's interpreter -- not a bare python, which will not have the dependencies installed:
claude mcp add notebooklm -- /path/to/repo/venv/bin/python /path/to/repo/notebooklm_mcp_server.pyVerify with claude mcp list.
python notebooklm_mcp_server.py --httpThen connect your client to http://localhost:8000/mcp.
Each Google account is stored in a separate directory. Set NOTEBOOKLM_HOME to switch between them:
# Authenticate different accounts
NOTEBOOKLM_HOME=~/.notebooklm-work notebooklm login # Work account
NOTEBOOKLM_HOME=~/.notebooklm notebooklm login # Personal account
NOTEBOOKLM_HOME=~/.notebooklm-design notebooklm login # Another accountThe get_account_info tool shows the currently active profile and available alternatives. Use switch_account to change at runtime without restarting.
Once configured, you can interact with NotebookLM directly from your AI agent:
List notebooks:
"List my NotebookLM notebooks"
Query a knowledge base:
"Ask the Strategy notebook: what are our key objectives for 2026?"
Set a persona and ask:
"As a strategy analyst, summarise the key risks in my Research notebook"
Add multiple sources at once:
"Add these URLs to my Research notebook: https://example.com/article1, https://example.com/article2"
Generate and download content:
"Generate a podcast overview for the Project notebook and save it" "Generate a report from the Strategy notebook and download it as PDF" "Create an infographic from the Training notebook"
Research and import:
"Research 'digital fabrication trends' and import the top results into my Research notebook"
Generate a styled slide deck:
"Generate a slide deck for the Strategy notebook using the Corporate template"
The three bundled templates produce distinctly different output from the same workflow. Each example below was generated from a subsection of an innovation literacy training programme.
Strategy consulting style -- serif headings, blue accent, data-dense layouts with charts, tables, and evidence callouts.
Workshop and training style -- warm cream background, teal/amber accents, illustrated concepts, generous whitespace.
Pitch deck style -- dark backgrounds, lime accent, bold typography, minimal text, visually striking layouts.
See templates/slide_styles.md for the full template definitions or create your own following the same structure.
notebooklm-py-diet-mcp/
notebooklm_mcp_server.py # MCP server (14 tools, resources, prompts)
.mcp.json # Project-scoped MCP registration for Claude Code
pyproject.toml # Python packaging and tool configuration
requirements.txt # Convenience dependency file
INSTRUCTIONS.md # Context injected into the LLM when loaded
LICENSE # MIT licence
README.md # This file
tests/
conftest.py # Shared test fixtures and mocks
test_helpers.py # Unit tests for helper functions
test_tools.py # Mock-based tool tests
test_lifespan.py # Server startup scenario tests
templates/
slide_styles.md # Bundled slide design templates
docs/
setup.md # Detailed setup guide
demos/selected/ # Curated slide demo images (README gallery)
demos/corporate/ # Full corporate template example set
demos/educational/ # Full educational template example set
demos/creative/ # Full creative template example setpip install -e ".[dev]"
pytestruff check .
ruff format .The INSTRUCTIONS.md file is loaded by MCP clients alongside the server and provides the LLM with usage context -- workflow patterns, error handling guidance, and tool conventions. Place it next to notebooklm_mcp_server.py or in the MCP server metadata directory used by your client.
This project would not exist without notebooklm-py by Teng Lin and contributors. It provides the complete Python API for Google NotebookLM that this MCP server wraps.
The MCP server is built using the Model Context Protocol Python SDK by Anthropic.
MIT -- see LICENSE for details.
This is an unofficial project. It is not affiliated with, endorsed by, or supported by Google. It relies on undocumented APIs that may change at any time. Use at your own risk. See the notebooklm-py security policy for credential handling guidance.
Add multiple sources to a notebook in a single call.
Each source is a dictionary with a "type" and "value" field. Supported types: "url", "text", "file". Text sources also require a "title" field.
Args: notebook_id: ID of the notebook sources: JSON array of sources, e.g. [{"type": "url", "value": "https://example.com"}, {"type": "text", "value": "Content here", "title": "My Notes"}, {"type": "file", "value": "/path/to/document.pdf"}] wait: Whether to wait for processing to complete
Returns: Dictionary with results for each source
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | ||
| sources | Yes | ||
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that sources are added, that a 'wait' parameter controls synchronous behavior, and that results are returned. However, it does not describe potential side effects (e.g., overwriting, idempotency), authentication needs, rate limits, or error handling. The behavioral profile is partially clear but lacks important safety and operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, a list of supported types, and an argument section with examples. It is front-loaded with the main action. The 'Args' section adds some redundancy but is helpful for readability. It is slightly verbose but every part serves a purpose, earning a high score without being perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions 'Dictionary with results for each source' but omits details on error handling, idempotency, or whether sources are appended or replace existing ones. Parameters are well-covered, but the tool's overall behavior (e.g., required notebook existence, limits on number of sources) is not addressed. Siblings are not cross-referenced. Adequate but lacking for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate entirely. It does so excellently: each parameter is explained with types and examples. 'sources' is detailed with a JSON array example showing structure ('type', 'value', 'title' for text). 'wait' is clarified as a boolean for processing. This adds significant meaning beyond the bare schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add multiple sources to a notebook in a single call.' It specifies the verb 'add', the resource 'sources to a notebook', and highlights batching with 'single call'. This distinguishes it from sibling tools like 'list_sources' (read-only) or 'research_and_import' (different function). Supported types are listed, adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no explicit guidance on when to use it versus alternatives. It does not mention when not to use it, prerequisites (e.g., notebook must exist), or compare with related tools. The context of adding multiple sources is implied but not framed against single-add options or other import methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a question to a NotebookLM notebook and get an AI-generated answer.
Args: notebook_id: ID of the notebook to query question: The question to ask source_ids: Comma-separated source IDs to restrict the query (optional) conversation_id: Continue an existing conversation thread (optional) persona: Set chat persona before asking (optional). Use a descriptive role like "tutor", "analyst", "concise summariser". Cleared if empty. response_length: Set response length before asking (optional). One of: short, medium, long. Cleared if empty.
Returns: Dictionary with the answer and citation information
| Name | Required | Description | Default |
|---|---|---|---|
| persona | No | ||
| question | Yes | ||
| source_ids | No | ||
| notebook_id | Yes | ||
| conversation_id | No | ||
| response_length | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only notes that 'persona' and 'response_length' are cleared if empty, but omits side effects (e.g., state changes), authentication needs, rate limits, or costs. The impact of asking a question on the notebook or account is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring of about 10 lines. It immediately states the purpose, then lists parameters with clear explanations, and finally mentions the return type. Every sentence adds value, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description covers inputs adequately but lacks details on return structure beyond 'Dictionary with the answer and citation information'. It does not explain possible errors, response format specifics, or how to interpret citations, which would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains all 6 parameters: notebook_id, question, source_ids (comma-separated), conversation_id (thread continuation), persona (descriptive role), and response_length (short/medium/long). It adds semantics missing from the schema, such as format and behavior when empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear statement: 'Ask a question to a NotebookLM notebook and get an AI-generated answer.' It specifies the action (ask), the resource (NotebookLM notebook), and the result (AI-generated answer). This is distinct from sibling tools that perform other operations like listing, creating, or exporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or when not to use it. Sibling tools like research_and_import or list_sources are not differentiated, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new NotebookLM notebook.
Args: title: Title for the new notebook
Returns: Dictionary with notebook ID and title
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as side effects, permissions, idempotency, or constraints (e.g., title uniqueness). Only states creation action and return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured, with a clear purpose line followed by args and returns in a clean format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers basic purpose and return. Could add more on constraints like title length or uniqueness, but is adequate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by explaining the parameter's purpose ('Title for the new notebook'), which helps beyond the schema's type and title alone. However, no details on format or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new NotebookLM notebook with a specific verb and resource. Distinguishes from sibling list_notebooks_tool by nature of operation (creation vs listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for creating a notebook, but no explicit guidance on when to use this vs alternatives like list_notebooks_tool or other tools. No exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new NotebookLM account profile and launch the Google login.
This opens a browser window for the user to sign into their Google account. Once authentication is complete, the profile is ready to use via switch_account.
Args: profile: Name for the new profile (e.g. 'work', 'design', 'testing'). Will be stored at ~/.notebooklm-.
Returns: Dictionary with the profile status and next steps.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors: it opens a browser for Google sign-in, stores the profile at a specific path, and requires authentication. No annotations exist, so the description carries full burden; it provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded main action, followed by a clear Args section and a Returns note. Every sentence is informative without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, parameter, process, and outcome. However, the return format is vague ('status and next steps') and prerequisites (like whether a user can have multiple profiles) are not mentioned. It is mostly complete for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by giving examples ('work', 'design', 'testing') and explaining the storage path. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new NotebookLM account profile and launches Google login. The verb 'create' and resource 'profile' are specific, and it distinguishes from sibling tools like 'switch_account' which assumes an existing profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used for setting up a new profile before switching, but it does not explicitly state when not to use it or compare with alternatives. The mention of 'use via switch_account' provides some workflow guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export an artifact to a file in the requested format.
Uses the appropriate export method based on the artifact type.
Args: notebook_id: ID of the notebook artifact_id: ID of the artifact to export output_path: Path where to save the exported file export_format: Desired format (pdf, csv, json, etc.). Leave empty for default.
Returns: Dictionary with export status
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_id | Yes | ||
| notebook_id | Yes | ||
| output_path | Yes | ||
| export_format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions behavioral adaptation ('Uses the appropriate export method based on the artifact type') and default format handling, but lacks depth on permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence, bullet-pointed Args, and Returns section. Every sentence is informative and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations or output schema, the description covers purpose, parameters, and return type. It lacks mention of file overwrite behavior or async nature, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains each parameter (notebook_id, artifact_id, output_path, export_format) with clear purpose and examples (pdf, csv, json). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export an artifact to a file in the requested format.' It uses specific verb+resource and distinguishes from siblings like list_notebooks or create_notebook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that the tool uses the appropriate export method based on artifact type, providing clear context. However, it does not explicitly exclude alternatives or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an artifact and download it in a single call.
Supports: report, audio, slide_deck, quiz, infographic.
Args: notebook_id: ID of the notebook artifact_type: One of: report, audio, slide_deck, quiz, infographic output_path: Path where to save the downloaded file. Use the correct extension: .pdf (report, slide_deck, infographic), .wav (audio), .json/.md/.html (quiz, based on quiz_output_format) instructions: Custom instructions for generation (optional). For slide decks, pass a design template here to control visual style. audio_format: Audio format: deep-dive, brief, critique, debate audio_length: Audio length: short, medium, long quiz_quantity: Quiz quantity: few, standard, more quiz_difficulty: Quiz difficulty: easy, medium, hard quiz_output_format: Quiz download format: json, markdown, html
Returns: Dictionary with generation and download status
| Name | Required | Description | Default |
|---|---|---|---|
| notebook_id | Yes | ||
| output_path | Yes | ||
| audio_format | No | deep-dive | |
| audio_length | No | medium | |
| instructions | No | ||
| artifact_type | Yes | ||
| quiz_quantity | No | standard | |
| quiz_difficulty | No | medium | |
| quiz_output_format | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It explains that the tool performs both generation and download atomically, and details parameter behaviors (e.g., extension requirements, optional instructions for slide decks). However, it omits key traits like error handling, network dependency, file overwrite behavior, or authentication requirements, leaving the agent with gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first line states purpose, followed by supported types, then parameter details in a clear bullet-like list. It is sufficiently detailed without being redundant, though some parameter descriptions could be slightly tightened (e.g., repeating 'audio' for format/length).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, no output schema), the description covers all parameters, return type (dictionary with status), and supported types with extension guidance. It lacks details on error conditions and the exact structure of the return dictionary, but for a generation + download tool, it provides adequate information for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does so by providing detailed explanations for all 9 parameters, including extension mappings for output_path, the purpose of instructions (especially for slide decks), and options for audio and quiz parameters. This adds significant meaning beyond the bare parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb+resource: 'Generate an artifact and download it in a single call.' It lists supported artifact types (report, audio, slide_deck, quiz, infographic), clearly distinguishing from siblings like 'list_artifacts' (which just lists) and 'export_artifact' (which likely exports existing artifacts without generation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'export_artifact'). It does not mention prerequisites, edge cases, or scenarios where this tool is preferred over others. The usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current NotebookLM account and available profiles.
Returns: Dictionary with current account, config path, available profiles, and instructions for switching or adding accounts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return value but does not explicitly state that the tool has no side effects (read-only). For a simple info tool, this is adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, and front-loaded. Every word adds value, and it efficiently communicates the tool's output without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a simple read-only purpose, the description fully explains what the tool does and returns. It is sufficient for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description needs to add no additional meaning. The baseline for 0 parameters is 4, and the description correctly focuses on the tool's purpose and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the current account and available profiles. It uses a specific verb 'Show' and identifies the resource (account info), which distinguishes it from siblings like switch_account and create_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for viewing info but provides no explicit guidance on when to use this tool versus siblings or when not to use it. For a tool in a set with many action-oriented siblings, additional context would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List artifacts in a notebook, optionally filtered by type.
Args: notebook_id: ID of the notebook artifact_type: Filter by type (audio, video, report, quiz, flashcards, slide_deck, infographic, data_table, mind_map). Leave empty for all types.
Returns: Dictionary with the list of artifacts
| Name | Required | Description | Default |
|---|---|---|---|
| notebook_id | Yes | ||
| artifact_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states return type ('dictionary'). Lacks details on authorization, rate limits, side effects, or performance. Bare minimum behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single-sentence purpose followed by structured parameter docs. No redundancy, front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description only says 'dictionary with list of artifacts'. Missing details on response structure, pagination, ordering, or error cases. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description explains notebook_id as ID and artifact_type with concrete allowed values. Adds useful meaning beyond property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action ('List artifacts') and resource ('in a notebook') with optional filtering. Distinguishes from sibling tools like list_notebooks and list_sources by specifying artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for listing artifacts filtered by type, but no explicit when-to-use, when-not-to-use, or alternative tools. User must infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all NotebookLM notebooks.
Returns a dictionary with notebook titles and IDs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the return format but does not disclose potential limitations, pagination, or required permissions. For a list operation, minimal behavioral info is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters, the description adequately states the resource and return format. It could mention ordering or if the list is complete, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description does not need to add parameter semantics, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and specifies the resource 'all NotebookLM notebooks', making it distinct from sibling tools like create_notebook or list_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It is implied that this is for retrieving all notebooks, but no explicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sources in a notebook.
Args: notebook_id: ID of the notebook
Returns: Dictionary with source count and source details
| Name | Required | Description | Default |
|---|---|---|---|
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the action 'list all sources' without disclosing if it's read-only, rate limits, or any side effects. The behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action. The docstring format is somewhat redundant with the schema, but overall it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter, the description covers the basic purpose and parameter. However, it lacks details about the return format (no output schema) and any behavioral aspects like sorting or filtering. It is minimally complete but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should add meaning. The docstring says 'notebook_id: ID of the notebook' which adds basic text but no format, constraints, or examples. This is redundant with the schema title 'Notebook Id', adding very little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all sources in a notebook. It uses a specific verb 'list' and resource 'sources' with clear scope. This distinguishes it from sibling tools like list_notebooks_tool and add_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context for usage. The description only states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a PDF file to individual PNG images (one per page).
Useful for making slide deck pages visible to LLMs for review or editing.
Args: pdf_path: Path to the source PDF file output_directory: Directory to write PNGs into. Defaults to a folder beside the PDF named _pages/ dpi: Render resolution (default 200 -- good balance of quality and size)
Returns: Dictionary with output directory, list of page image paths, and page count
| Name | Required | Description | Default |
|---|---|---|---|
| dpi | No | ||
| pdf_path | Yes | ||
| output_directory | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden for behavioral disclosure. It explains the conversion process, default output directory naming, and return value structure. It could mention side effects like file overwriting or required permissions, but the current level is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 6 sentences plus structured Args and Returns. It is front-loaded with the purpose and every sentence serves a clear function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description covers purpose, use case, parameter details, and return format completely. An agent can understand when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that pdf_path is the source file, output_directory defaults to a folder beside the PDF named <filename>_pages/, and dpi defaults to 200 with a quality-size balance, adding significant meaning beyond the schema's type and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Convert a PDF file to individual PNG images (one per page).' This is a specific verb+resource combination that differentiates it from the sibling tool 'png_to_pdf' which performs the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for making slide deck pages visible to LLMs for review or editing.' This provides clear context for when to use the tool. No explicit when-not or alternative tools are mentioned, but the sibling list implies the reverse operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combine PNG images into a single PDF document.
Provide either a list of image paths or a directory containing PNGs. When using a directory, images are sorted alphabetically (the naming convention from pdf_to_png -- page_001.png, page_002.png, etc. -- preserves correct order automatically).
Args: image_paths: Comma-separated image file paths, or a JSON array of paths image_directory: Directory of PNG files to combine (alternative to image_paths) output_path: Path for the output PDF. Defaults to /combined.pdf
Returns: Dictionary with the output PDF path and page count
| Name | Required | Description | Default |
|---|---|---|---|
| image_paths | No | ||
| output_path | No | ||
| image_directory | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses default output path, sorting, and return dictionary. Does not mention potential overwriting, supported image sizes, or error conditions. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with clear sections (args, returns). Uses bullet points for readability. Every sentence adds value without redundancy. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input options, output default, sorting, and return value. With 3 parameters and no output schema, description is mostly complete. Minor gaps: no mention of file size limits, overwrite behavior, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains all three parameters: image_paths (comma-separated or JSON array), image_directory (alternative input), output_path (default behavior). Adds concrete formatting and usage details absent from schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Combine), resource (PNG images), and output (single PDF). Distinguishes from sibling tool pdf_to_png by specifying input format and output format. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on using image_paths vs image_directory, including sorting behavior and naming convention. Lacks explicit when-not-to-use but covers main usage scenarios. No direct comparison with siblings beyond context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research a topic and import the results as notebook sources in a single call.
Starts a research task, polls until completion, and automatically imports the top results.
Args: notebook_id: ID of the notebook query: Research query source: Where to search: "web" or "drive" max_results: Maximum number of results to import
Returns: Dictionary with research results and import status
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| source | No | web | |
| max_results | No | ||
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. Mentions starting a research task, polling, and auto-importing, but does not detail side effects, error handling, or what 'top results' means. Lacks depth for a multi-step tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two paragraphs; first clearly states purpose, then args/returns listed. No fluff, but could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers workflow and basic parameter explanations, but lacks details on failure modes, timeout behavior, and full return structure. With no output schema, agents may need more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It lists parameters with brief meanings (e.g., 'Where to search: web or drive' for source, 'Maximum number of results' for max_results). Useful but not highly detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it research a topic and imports results as notebook sources in a single call. It distinguishes from siblings like 'ask_question' (answer without import) and 'add_sources' (import only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when wanting to combine research and import in one step, but no explicit when-to-use, when-not, or alternatives mentioned. Sibling tools hint at alternatives but description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch the active NotebookLM account to a different Google profile.
The change takes effect immediately and is persisted across server restarts. Use get_account_info to see available profiles.
Args: profile: Profile name to switch to (e.g. 'work', 'personal', 'design', or any custom name matching ~/.notebooklm-)
Returns: Dictionary confirming the switch with the new profile details.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the change takes effect immediately and is persisted across server restarts. While no annotations are provided, this covers key behavioral aspects. It does not mention potential side effects like losing unsaved work or requiring re-authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate paragraphs for purpose, usage, and argument details. Every sentence is informative, and there is no redundancy or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description adequately explains what the tool does, how to use it, and what to expect in return (dictionary confirming switch). Minor gaps exist (e.g., error handling for invalid profile), but overall it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential meaning. It provides examples (e.g., 'work', 'personal', 'design') and explains the naming convention (~/.notebooklm-<name>), going beyond the schema's simple string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Switch' and the resource 'active NotebookLM account to a different Google profile.' It distinguishes from siblings like get_account_info (which shows profiles) and create_profile (which creates new profiles).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using get_account_info to see available profiles before switching, providing clear context. However, it does not explicitly state when not to use the tool or list all alternative actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_sourcesask_questioncreate_notebookcreate_profileexport_artifactgenerate_and_downloadget_account_infolist_artifactslist_notebooks_toollist_sourcespdf_to_pngpng_to_pdfresearch_and_importswitch_accountTools generally have distinct purposes, but generate_and_download and export_artifact both deal with artifacts, and list_sources vs list_artifacts could be confused. Most tools are clearly separated.
Most tools follow a verb_noun pattern, but there are inconsistencies like 'list_notebooks_tool' with a '_tool' suffix, 'research_and_import' uses 'and', and 'pdf_to_png' lacks a verb. Overall patterns are mixed.
14 tools is well-scoped for a NotebookLM server, covering notebook management, sources, Q&A, artifacts, accounts, and PDF utilities. No obvious bloat or deficiency.
Core workflows (create/list notebooks, add sources, ask questions, generate/export artifacts, account management) are covered. Minor gaps like missing delete/update operations do not significantly hinder typical use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Google NotebookLM via natural language: create notebooks, add sources (PDF, URL, YouTube) and ask gr
Shared memory for coding agents. Stop re-explaining your codebase every session.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/earlyprototype/notebooklm-py-diet-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
