Skip to main content
Glama
Pantheon-Security

NotebookLM MCP Server (Security Hardened)

Create Notebook

create_notebook

Create a new NotebookLM notebook by uploading sources like URLs, text, or files programmatically. Returns the notebook URL for immediate use.

Instructions

Create a new NotebookLM notebook with sources programmatically.

What This Tool Does

  • Creates a NEW notebook in your NotebookLM account

  • Uploads sources (URLs, text, files) to the notebook

  • Returns the notebook URL for immediate use

  • Optionally adds to your local library

Supported Source Types

  • url: Web page URL (documentation, articles, etc.)

  • text: Raw text content (code, notes, etc.)

  • file: Local file path (PDF, DOCX, TXT)

Example Usage

Create a notebook from API documentation:

{
  "name": "React Docs",
  "sources": [
    { "type": "url", "value": "https://react.dev/reference/react" }
  ]
}

Create a notebook with multiple sources:

{
  "name": "Security Research",
  "sources": [
    { "type": "url", "value": "https://owasp.org/Top10" },
    { "type": "file", "value": "/path/to/security-report.pdf" },
    { "type": "text", "value": "Custom notes...", "title": "My Notes" }
  ],
  "description": "Security best practices and research",
  "topics": ["security", "owasp", "best-practices"]
}

NotebookLM Limits (Free Tier)

  • 100 notebooks maximum

  • 50 sources per notebook

  • 500k words per source

  • 50 queries per day

Notes

  • Requires authentication (run setup_auth first)

  • Creates notebook with sharing set to private by default

  • Large files may take longer to process

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name for the new notebook
sourcesYesArray of sources to add to the notebook
descriptionNoOptional description for the notebook in your library
topicsNoOptional topics for categorization in your library
auto_add_to_libraryNoWhether to automatically add the created notebook to your library (default: true)
browser_optionsNoOptional browser settings for debugging
show_browserNoShow browser window (shorthand for browser_options.show)
Behavior5/5

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

Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description adds valuable behavioral context beyond annotations: it discloses authentication requirements, rate limits (NotebookLM Free Tier limits), default privacy settings, processing time for large files, and that it returns a notebook URL. This significantly enhances the agent's understanding of the tool's behavior.

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

Conciseness4/5

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

The description is well-structured with clear sections (What This Tool Does, Supported Source Types, Example Usage, Limits, Notes) and uses bullet points efficiently. However, it includes extensive example JSON blocks that could be considered verbose, though they are informative. Overall, it's front-loaded and most sentences earn their place.

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?

Given the tool's complexity (7 parameters, nested objects, no output schema) and rich annotations, the description is highly complete. It covers purpose, usage, behavioral traits, limits, prerequisites, and provides examples, compensating well for the lack of output schema. No significant gaps remain for agent understanding.

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?

With 100% schema description coverage, the input schema already documents all 7 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, mainly through the example usage which illustrates practical combinations. It does not explain parameter interactions or constraints not in the schema, so 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 explicitly states the tool creates a new NotebookLM notebook with sources programmatically, clearly distinguishing it from siblings like 'add_notebook' (likely adds to existing) or 'batch_create_notebooks' (multiple). It specifies the verb 'creates' and resource 'notebook' with source uploading functionality.

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 for when to use this tool (creating new notebooks with sources) and mentions authentication prerequisites. However, it does not explicitly contrast with alternatives like 'batch_create_notebooks' or 'update_notebook', leaving some ambiguity about sibling differentiation.

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

Install Server

Other Tools

Latest Blog Posts

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/Pantheon-Security/notebooklm-mcp-secure'

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