Skip to main content
Glama

add_notebook

Add a NotebookLM notebook to your library by providing its URL, content description, topics, and use cases for AI-powered document querying.

Instructions

PERMISSION REQUIRED — Only when user explicitly asks to add a notebook.

Conversation Workflow (Mandatory)

When the user says: "I have a NotebookLM with X"

  1. Ask URL: "What is the NotebookLM URL?"

  2. Ask content: "What knowledge is inside?" (1–2 sentences)

  3. Ask topics: "Which topics does it cover?" (3–5)

  4. Ask use cases: "When should we consult it?"

  5. Propose metadata and confirm:

    • Name: [suggested]

    • Description: [from user]

    • Topics: [list]

    • Use cases: [list] "Add it to your library now?"

  6. Only after explicit "Yes" → call this tool

Rules

  • Do not add without user permission

  • Do not guess metadata — ask concisely

  • Confirm summary before calling the tool

Example

User: "I have a notebook with n8n docs" You: Ask URL → content → topics → use cases; propose summary User: "Yes" You: Call add_notebook

Visit https://notebooklm.google/ → Login (free: 100 notebooks, 50 sources each, 500k words, 50 daily queries)

  1. Click "+ New" (top right) → Upload sources (docs, knowledge)

  2. Click "Share" (top right) → Select "Anyone with the link"

  3. Click "Copy link" (bottom left) → Give this link to Claude

(Upgraded: Google AI Pro/Ultra gives 5x higher limits)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe NotebookLM notebook URL
nameYesDisplay name for the notebook (e.g., 'n8n Documentation')
descriptionYesWhat knowledge/content is in this notebook
topicsYesTopics covered in this notebook
content_typesNoTypes of content (e.g., ['documentation', 'examples', 'best practices'])
use_casesNoWhen should Claude use this notebook (e.g., ['Implementing n8n workflows'])
tagsNoOptional tags for organization

Implementation Reference

  • Main MCP tool handler for 'add_notebook'. Logs the call, delegates to NotebookLibrary.addNotebook, handles errors, and returns ToolResult.
    async handleAddNotebook(args: AddNotebookInput): Promise<ToolResult<{ notebook: any }>> {
      log.info(`🔧 [TOOL] add_notebook called`);
      log.info(`  Name: ${args.name}`);
    
      try {
        const notebook = this.library.addNotebook(args);
        log.success(`✅ [TOOL] add_notebook completed: ${notebook.id}`);
        return {
          success: true,
          data: { notebook },
        };
      } catch (error) {
        const errorMessage = error instanceof Error ? error.message : String(error);
        log.error(`❌ [TOOL] add_notebook failed: ${errorMessage}`);
        return {
          success: false,
          error: errorMessage,
        };
      }
    }
  • Core implementation of adding a notebook: generates unique ID, creates NotebookEntry with defaults, appends to library, persists to JSON file.
    addNotebook(input: AddNotebookInput): NotebookEntry {
      log.info(`📝 Adding notebook: ${input.name}`);
    
      // Generate ID
      const id = this.generateId(input.name);
    
      // Create entry
      const notebook: NotebookEntry = {
        id,
        url: input.url,
        name: input.name,
        description: input.description,
        topics: input.topics,
        content_types: input.content_types || ["documentation", "examples"],
        use_cases: input.use_cases || [
          `Learning about ${input.name}`,
          `Implementing features with ${input.name}`,
        ],
        added_at: new Date().toISOString(),
        last_used: new Date().toISOString(),
        use_count: 0,
        tags: input.tags || [],
      };
    
      // Add to library
      const updated = { ...this.library };
      updated.notebooks.push(notebook);
    
      // Set as active if it's the first notebook
      if (updated.notebooks.length === 1) {
        updated.active_notebook_id = id;
      }
    
      this.saveLibrary(updated);
      log.success(`✅ Notebook added: ${id}`);
    
      return notebook;
    }
  • TypeScript interface defining the input parameters for add_notebook, used by handler and library method.
    export interface AddNotebookInput {
      url: string; // Required: NotebookLM URL
      name: string; // Required: Display name
      description: string; // Required: What's in it
      topics: string[]; // Required: Topics covered
      content_types?: string[]; // Optional: defaults to ["documentation", "examples"]
      use_cases?: string[]; // Optional: defaults based on description
      tags?: string[]; // Optional: custom tags
    }
  • MCP Tool definition object for 'add_notebook' including detailed description, input schema, and usage instructions. Part of notebookManagementTools array.
        name: "add_notebook",
        description:
          `PERMISSION REQUIRED — Only when user explicitly asks to add a notebook.
    
    ## Conversation Workflow (Mandatory)
    When the user says: "I have a NotebookLM with X"
    
    1) Ask URL: "What is the NotebookLM URL?"
    2) Ask content: "What knowledge is inside?" (1–2 sentences)
    3) Ask topics: "Which topics does it cover?" (3–5)
    4) Ask use cases: "When should we consult it?"
    5) Propose metadata and confirm:
       - Name: [suggested]
       - Description: [from user]
       - Topics: [list]
       - Use cases: [list]
       "Add it to your library now?"
    6) Only after explicit "Yes" → call this tool
    
    ## Rules
    - Do not add without user permission
    - Do not guess metadata — ask concisely
    - Confirm summary before calling the tool
    
    ## Example
    User: "I have a notebook with n8n docs"
    You: Ask URL → content → topics → use cases; propose summary
    User: "Yes"
    You: Call add_notebook
    
    ## How to Get a NotebookLM Share Link
    
    Visit https://notebooklm.google/ → Login (free: 100 notebooks, 50 sources each, 500k words, 50 daily queries)
    1) Click "+ New" (top right) → Upload sources (docs, knowledge)
    2) Click "Share" (top right) → Select "Anyone with the link"
    3) Click "Copy link" (bottom left) → Give this link to Claude
    
    (Upgraded: Google AI Pro/Ultra gives 5x higher limits)`,
        inputSchema: {
          type: "object",
          properties: {
            url: {
              type: "string",
              description: "The NotebookLM notebook URL",
            },
            name: {
              type: "string",
              description: "Display name for the notebook (e.g., 'n8n Documentation')",
            },
            description: {
              type: "string",
              description: "What knowledge/content is in this notebook",
            },
            topics: {
              type: "array",
              items: { type: "string" },
              description: "Topics covered in this notebook",
            },
            content_types: {
              type: "array",
              items: { type: "string" },
              description:
                "Types of content (e.g., ['documentation', 'examples', 'best practices'])",
            },
            use_cases: {
              type: "array",
              items: { type: "string" },
              description: "When should Claude use this notebook (e.g., ['Implementing n8n workflows'])",
            },
            tags: {
              type: "array",
              items: { type: "string" },
              description: "Optional tags for organization",
            },
          },
          required: ["url", "name", "description", "topics"],
        },
      },
  • src/index.ts:171-182 (registration)
    Dispatch logic in main MCP server that routes 'add_notebook' tool calls to the appropriate handler method.
    case "add_notebook":
      result = await this.toolHandlers.handleAddNotebook(
        args as {
          url: string;
          name: string;
          description: string;
          topics: string[];
          content_types?: string[];
          use_cases?: string[];
          tags?: string[];
        }
      );
Behavior4/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It effectively describes the tool's behavior: it requires explicit user permission, follows a mandatory multi-step conversation workflow, requires specific metadata collection, and only executes after confirmation. It also provides context about NotebookLM limits (free vs upgraded tiers), though it doesn't mention error handling or response format.

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

Conciseness2/5

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

The description is excessively long (over 300 words) with significant redundancy. While the workflow details are valuable, they could be more concise. The 'How to Get a NotebookLM Share Link' section, while helpful, is overly detailed for a tool description. The core purpose gets buried among procedural details and platform documentation.

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 7-parameter mutation tool with no annotations and no output schema, the description provides substantial context about the tool's behavior, prerequisites, and usage workflow. It covers the conversational approach, permission requirements, and NotebookLM platform context. The main gap is the lack of information about return values or error conditions, which would be helpful given the absence of an output schema.

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 the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. However, it provides context about how to obtain the 'url' parameter (via NotebookLM share link process) and gives examples of metadata values throughout the workflow description.

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

Purpose4/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 notebook to a library, with the phrase 'add a notebook' appearing multiple times. It distinguishes from siblings like 'remove_notebook' and 'update_notebook' by focusing on creation rather than modification or deletion. However, it doesn't explicitly contrast with 'get_notebook' or 'list_notebooks', which are read operations.

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

Usage Guidelines5/5

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

The description provides explicit, detailed guidance on when to use this tool: only when the user explicitly asks to add a notebook, after completing a specific 6-step workflow (asking for URL, content, topics, use cases, proposing metadata, and getting explicit 'Yes' confirmation). It also specifies when NOT to use it ('Do not add without user permission', 'Do not guess metadata'), making alternatives clear.

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/inventra/notebooklm-mcp'

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