Which integrations are available for this server?

Allows interaction with Google NotebookLM, including listing, querying, and creating notebooks, as well as managing sources. Allows adding YouTube videos as sources to NotebookLM notebooks.

How do I use OneClickLM?

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., "@OneClickLM List my NotebookLM notebooks" 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.

OneClickLM

by CRtheHILLS

Overview Schema Related Servers Score Discussions

TypeScript

Local

Hi! I'm CR 👋

I built OneClickLM because I was tired of every NotebookLM MCP server breaking on me every few days.

After connecting NotebookLM to a 6-domain AI chatbot platform (BEYOND HUMAN), I hit literally every failure mode — expired tokens, Chrome crashes, concurrent query timeouts, you name it. So I built the tool I wished existed.

OneClickLM just works. Login once, forget about it forever.

Related MCP server: notebooklm-mcp-2026

💥 The Problem

Every NotebookLM MCP server on GitHub shares the same fatal flaw: they break within days.

Google silently rotates auth tokens, and no one handles it.

What happens	What you see
`build_label` expires (every 1-2 weeks)	🔴 400 Bad Request, zero explanation
CSRF token goes stale	🔴 Queries silently fail
Chrome already running	🔴 Login crashes with CDP conflict
Two queries at once	🔴 Timeout cascade, server dies
Python + pipx + virtualenv	🔴 30 minutes just to install
Connection drops	🔴 Queries hang forever

Sound familiar? Yeah, I went through all of this. So you don't have to.

✅ The Solution

Feature	How it works
Auto-healing auth	Detects expired tokens → refreshes automatically → you never notice
Zero config	`npx oneclicklm login` once, then it just works. Forever.
No Chrome conflicts	Uses system Chrome for login, then pure HTTP. No CDP, no conflicts.
Smart queue	Serializes concurrent calls. No timeouts, no crashes.
6 powerful tools	List, query, create notebooks + add sources. Everything you need.
TypeScript native	No Python, no virtualenv, no pipx. Just Node.js.

🚀 Quick Start

Step 1: Login (one time only)

npx oneclicklm login

A browser opens → sign in with Google → done. Your cookies are saved locally (~/.oneclicklm/).

Step 2: Add to your MCP client

{
  "mcpServers": {
    "notebooklm": {
      "command": "npx",
      "args": ["oneclicklm"]
    }
  }
}

Step 3: Start talking to your notebooks!

"List my NotebookLM notebooks"
"What are the key findings in my Research notebook?"
"Create a new notebook called 'Project Alpha'"
"Add this URL to my notebook: https://example.com/paper.pdf"

That's it. No API keys, no profiles, no metadata.json, no build_label hunting.

🛠 Available Tools

Tool	What it does	Example prompt
`notebook_list`	List all your notebooks	"Show me my NotebookLM notebooks"
`notebook_get`	Get notebook details + sources	"What sources are in my Research notebook?"
`notebook_query`	Ask questions, get cited answers	"What does my notebook say about X?"
`notebook_create`	Create a new notebook	"Create a notebook called 'Q1 Report'"
`source_add`	Add URL, YouTube, or text sources	"Add this article to my notebook"
`source_list`	List all sources + their status	"Show sources in my Project notebook"

Pro tip: notebook_query uses the same AI (Gemini) as the NotebookLM web app — your answers are grounded in your actual sources with zero hallucination.

💻 IDE Setup

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "notebooklm": {
      "command": "npx",
      "args": ["oneclicklm"]
    }
  }
}

claude mcp add notebooklm -- npx oneclicklm

Add to .vscode/mcp.json:

{
  "servers": {
    "notebooklm": {
      "command": "npx",
      "args": ["oneclicklm"]
    }
  }
}

Add to ~/.windsurf/mcp.json:

{
  "mcpServers": {
    "notebooklm": {
      "command": "npx",
      "args": ["oneclicklm"]
    }
  }
}

🔍 How OneClickLM Compares

Feature	OneClickLM	notebooklm-mcp (Python)	notebooklm-mcp-cli
Auto token refresh	✅	❌	❌
Auto build_label update	✅	❌	❌
Auto-reconnect on failure	✅	❌	❌
Request queue (no crashes)	✅	❌	❌
Zero-config install	✅ `npx`	❌ pipx + profiles	❌ pipx + profiles
Language	TypeScript	Python	Python
Chrome conflicts	None	Common	Common
Human-readable errors	✅	❌	❌
Create notebooks via MCP	✅	❌	✅
Add sources via MCP	✅	❌	✅

⚙️ Configuration

OneClickLM works with zero configuration. But if you need it:

# Custom config directory
ONECLICKLM_DIR=~/.my-config npx oneclicklm

# Debug logging (see what's happening under the hood)
ONECLICKLM_LOG=debug npx oneclicklm

# Custom request timeout (default: 30s, queries may need longer)
ONECLICKLM_TIMEOUT=60000 npx oneclicklm

# Custom Chrome path
CHROME_PATH=/path/to/chrome npx oneclicklm login

Config is stored in ~/.oneclicklm/:

~/.oneclicklm/
├── cookies.json    # Google auth cookies (auto-managed)
└── tokens.json     # CSRF + session + build_label (auto-refreshed)

🧠 How It Works (for the curious)

OneClickLM speaks the same language as the NotebookLM web app — Google's internal batchexecute RPC protocol.

Here's what happens when you ask a question:

You: "What are the key findings?"
 ↓
MCP Client (Cursor/Claude/VS Code) sends tool call
 ↓
OneClickLM checks tokens → auto-refreshes if stale
 ↓
Fetches source IDs from notebook (RPC: rLM1Ne)
 ↓
Sends query via streaming endpoint (GenerateFreeFormStreamed)
 ↓
Parses streaming response → extracts answer
 ↓
Returns grounded, cited answer to your AI

The magic is in the auto-healing auth:

On startup: loads saved cookies + cached tokens
If tokens expired (>1 hour): fetches NotebookLM page → extracts fresh SNlM0e (CSRF) + FdrFJe (session) + build_label
If cookies expired (~30 days): prompts for re-login
If API returns 400/401: auto-refreshes tokens and retries once
All requests serialized through a queue → no concurrent crash

NOTE

OneClickLM uses Google's internal web protocol, not an official API. This means it works with your existing Google account — no API keys, no billing, no quotas. Google AI Pro subscribers get full NotebookLM access.

🔧 Troubleshooting

Make sure Chrome/Chromium is installed. OneClickLM detects it automatically on macOS, Windows, and Linux.

# If using a non-standard Chrome location:
CHROME_PATH=/path/to/chrome npx oneclicklm login

OneClickLM auto-refreshes tokens, but if it persists:

# Force token refresh
npx oneclicklm refresh

# Nuclear option: re-login
npx oneclicklm login

This is normal. NotebookLM processes your query against all uploaded sources in real-time (this is the Gemini model working). The NotebookLM web app has similar response times. For faster results, use notebooks with fewer sources.

npx oneclicklm status

This verifies cookies, extracts fresh tokens, and tells you if anything is wrong.

🤝 Contributing

Contributions welcome! Bug reports, feature requests, and PRs are all appreciated.

git clone https://github.com/CRtheHILLS/OneClickLM.git
cd OneClickLM
npm install
npm run build
node dist/src/index.js  # Run locally

⭐ Star History

If OneClickLM saved you from NotebookLM auth hell, consider starring the repo!

License

MIT © CRtheHILLS

Available Tools

6 tools

notebook_createA

Create a new empty NotebookLM notebook. After creating, use source_add to add content.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title for the new notebook

TDQS

A3.7/5.0

Behavior2/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 only states 'create a new empty notebook' without disclosing side effects, permissions, limits, or what the response contains. This is insufficient for a mutation tool.

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 succinct sentences with no wasted words, front-loading the core purpose and providing actionable follow-up guidance.

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

Completeness3/5

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

The tool is simple (one param, no output schema), so the description is adequate but lacks behavioral details like return value or error conditions. Sibling tools exist but the description doesn't fully leverage context.

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% with one parameter 'title' already described. The description adds no further meaning beyond the schema's description, meeting the baseline for high coverage.

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 explicitly states the action (create) and the resource (new empty NotebookLM notebook), and distinguishes itself from sibling tools like notebook_list, notebook_get, notebook_query, and source_add by specifying the creation step.

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 provides a clear sequential usage hint: 'After creating, use source_add to add content.' This guides the agent on the next step, but lacks explicit when-not-to-use or alternatives for the creation itself.

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

notebook_getA

Get detailed information about a specific notebook, including all its sources and their status.

ParametersJSON Schema

Name	Required	Description	Default
`notebook_id`	Yes	The notebook ID (get this from notebook_list)

TDQS

A3.5/5.0

Behavior3/5

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

The description states it returns 'detailed information' including sources and status, but does not expand on what 'detailed' entails, how the data is structured, or any side effects. Since no annotations exist, the description carries full burden ; it is adequate but not rich.

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, front-loaded sentence with no wasted words. It efficiently communicates the main purpose and key deliverables.

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

Completeness3/5

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

Given the tool's simplicity (one parameter, no output schema), the description provides the essential information. However, it could be more complete by elaborating on what 'detailed information' includes besides sources and status, especially since there is no output schema to guide the agent.

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 additional meaning beyond what the schema provides. The schema already describes the parameter as 'The notebook ID (get this from notebook_list)', which is sufficient. 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?

Clearly states the tool gets detailed information about a specific notebook including sources and their status. The verb 'get' and resource 'notebook' are specific, and the inclusion of 'all its sources' distinguishes it from sibling tools like 'notebook_list' which likely only lists summaries.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives. While it's implied that one should use it when needing detailed info on a single notebook, there is no mention of when not to use it or which sibling tool might be more appropriate for filtering or listing.

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

notebook_listA

List all your NotebookLM notebooks. Returns notebook IDs, titles, and source counts. Use this first to discover available notebooks.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior2/5

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

No annotations provided, so description must convey behavioral traits. It mentions the output but does not disclose read-only nature, permissions, side effects, or rate limits. Only basic listing behavior is implied.

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 with no wasted words. Purpose, return content, and usage order are front-loaded and clear.

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?

For a simple list tool with no parameters or output schema, the description covers purpose, return fields, and usage order. Missing details like pagination or ordering, but likely not needed given no params.

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?

No parameters exist (schema coverage 100%), so baseline is 4. Description adds value by explaining what the returned data includes, which aids interpretation despite no params.

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?

Description clearly states verb 'List', resource 'all your NotebookLM notebooks', and specifies return fields (IDs, titles, source counts). It also suggests usage order, distinguishing it from siblings like notebook_get (single) and notebook_create (creation).

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?

Explicitly says 'Use this first to discover available notebooks', providing clear context for when to use. Does not explicitly exclude scenarios, but the implication of first-use is sufficient.

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

notebook_queryA

Ask a natural language question to a NotebookLM notebook. The AI will analyze all sources in the notebook and return a grounded, cited answer. This is the main tool for getting information from your notebooks.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Your question in natural language
`notebook_id`	Yes	The notebook ID to query

TDQS

A4.2/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 discloses that the AI analyzes all sources and returns a grounded, cited answer. This is useful behavioral context beyond the schema, though it could mention response format or limitations.

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 only two sentences, front-loaded with the action, and every word earns its place. No unnecessary elaboration.

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 two-parameter schema (both well-described) and no output schema, the description adequately covers what the tool does and its output nature (grounded, cited). It could mention that it works across all sources, but this is implied.

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 description coverage is 100%, so baseline is 3. The description adds 'in natural language' for query, which aligns with the schema, but does not provide additional meaning beyond what the schema already states.

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's purpose: asking natural language questions to a NotebookLM notebook and receiving grounded, cited answers. It distinguishes itself from sibling tools (e.g., notebook_list, source_add) by explicitly calling it 'the main tool for getting information from your notebooks.'

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 provides clear context that this tool is for querying notebooks to get answers, but does not explicitly state when not to use it or list alternatives. Given the sibling tools cover other actions, the usage context is clear enough, though exclusions would improve it.

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

source_addA

Add a source to a NotebookLM notebook. Supports URLs (web pages, articles), YouTube videos, and plain text content. The source will be processed and made available for queries.

ParametersJSON Schema

Name	Required	Description
`url`	No	URL to add (for type='url'). Supports web pages and YouTube links.
`type`	Yes	Source type: 'url' for web links/YouTube, 'text' for plain text
`title`	No	Title for text sources (for type='text')
`content`	No	Text content to add (for type='text')
`notebook_id`	Yes	The notebook ID to add the source to

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided. Description only states the source will be processed and made available, but does not mention mutation, side effects, or permission requirements, leaving significant behavioral gaps.

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 that front-load the core purpose. No unnecessary words.

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

Completeness3/5

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

While the description covers the basic operation and supported types, it does not explain the return value or what happens after processing. With no output schema, this leaves the agent guessing about the result.

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?

Schema already documents all 5 parameters. Description adds value by clarifying that URLs support web pages and YouTube, and that the tool accepts text content, which is not fully captured in schema.

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 adds a source to a NotebookLM notebook and lists supported types (URLs, web pages, articles, YouTube videos, plain text). This distinguishes it from sibling tools like notebook_list or source_list.

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?

No explicit guidance on when to use vs alternatives, but the verb 'add' and resource 'source' make it clear. However, description lacks exclusions or prerequisites.

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

source_listA

List all sources in a NotebookLM notebook, including their titles and processing status (ready, processing, error).

ParametersJSON Schema

Name	Required	Description	Default
`notebook_id`	Yes	The notebook ID to list sources for

TDQS

A3.5/5.0

Behavior2/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 mentions listing sources with status but does not disclose potential side effects, pagination, rate limits, or behavior on invalid notebook IDs. For a read operation, it lacks transparency.

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, well-structured sentence (16 words) that front-loads the core information. Every word adds value; no redundancy.

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

Completeness3/5

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 and no output schema, the description covers basic functionality. However, it lacks details on error handling (e.g., invalid notebook_id) or confirmation of complete results.

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%, with the parameter well-described. The description adds context about return fields but does not enhance parameter meaning beyond the schema. Baseline 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 action ('list') and the resource ('sources in a notebook'), and specifies the output includes titles and processing status. It effectively distinguishes from sibling tools like 'notebook_list' and 'source_add'.

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 when you need to list sources for a notebook, but does not provide explicit when-to-use or when-not-to-use guidance, nor alternatives. It is adequate but lacks coverage of usage conditions.

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

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing, getting, querying, creating notebooks, and adding/listening to sources. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent noun_verb pattern (e.g., notebook_list, source_add), with snake_case throughout.

Tool Count5/5

6 tools is well-scoped for managing NotebookLM notebooks, covering creation, querying, and source management without being excessive or insufficient.

Completeness4/5

Covers core workflows well but lacks delete or update operations for notebooks and sources, which may be needed for full lifecycle management.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

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

jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13
Google Compute Engine A
com.googleapis.compute
The Google Compute Engine MCP server is a fully-managed Model Context Protocol server that provides tools to manage Google Compute Engine resources through AI agents. It enables capabilities including instance management (creating, starting, stopping, resetting, listing), disk management, handling instance templates and group managers, viewing machine and accelerator types, managing images, and accessing reservation and commitment information. The server operates as a zero-deployment, enterprise-grade endpoint at https://compute.googleapis.com/mcp with built-in IAM-based security.
Cloud Platforms Virtualization Agent Orchestration
292
SupabaseOAuth
com.supabase
MCP server for interacting with the Supabase platform
Cloud Platforms Databases Developer Tools
32,886

Related MCP Servers

notebooklm-mcp-2026
Note Taking Knowledge & Memory
julianoczkowski
A
license
Not graded
quality
A
maintenance
Secure MCP server for querying Google NotebookLM notebooks. Enables AI assistants to list notebooks, read sources, and ask the NotebookLM AI questions about your sources.
Updated a month ago (2026-07-26 05:12 UTC)
16
MIT
notebooklm-mcp-2026
Note Taking Research & Data
Faxtom
A
license
Not graded
quality
A
maintenance
MCP server for querying Google NotebookLM notebooks, enabling AI assistants to list notebooks, read sources, and ask questions about them.
Updated a month ago (2026-07-22 04:12 UTC)
MIT
NotebookLM MCP Server
Note Taking AI & Machine Learning Education & Learning Tools
Vetal711
F
license
B
quality
B
maintenance
A production-ready, fully asynchronous MCP server that bridges AI agents with Google NotebookLM, enabling notebook creation, source management, audio generation, and more through natural language.
Updated 2 months ago (2026-06-26 06:56 UTC)
12
notebooklm-mcp
Note Taking AI & Machine Learning Knowledge & Memory
matheusbrios32004-lgtm
A
license
Not graded
quality
D
maintenance
MCP server that connects AI agents to Google NotebookLM, enabling natural language interaction with notebooks, including Q&A, source ingestion, and audio overview generation.
Updated 2 months ago (2026-07-15 14:32 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/CRtheHILLS/OneClickLM'

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