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[];
        }
      );

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose the mutating nature and the need for explicit user permission, which is important. However, it does not mention what happens on success or failure, whether duplicates are possible, or whether API authentication is required, leaving 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.

Conciseness2/5

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

The description is overlong and repetitive, restating the permission requirement multiple times ('Only when user explicitly asks', 'Do not add without user permission', 'Only after explicit Yes'). The 'How to Get a NotebookLM Share Link' section, including quota details, is auxiliary and not necessary for tool invocation.

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?

It provides enough workflow detail for an agent to successfully call the tool, including how to obtain a share link and how to confirm metadata. However, there is no output schema and no description of return values, error handling, or authentication requirements, especially given the presence of setup_auth and re_auth among siblings.

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?

The schema already documents all seven parameters, so the baseline is 3. The description adds meaning by explaining how parameter values should be elicited from the user (URL first, then content, topics, use cases) and how metadata should be proposed and confirmed before calling.

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 identifies the verb 'add' and resource 'notebook', and narrows invocation to explicit user requests. This distinguishes it from sibling tools like list_notebooks, update_notebook, and remove_notebook without needing to inspect their schemas.

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?

It explicitly states when to use the tool ('Only when user explicitly asks to add a notebook'), when not to ('Do not add without user permission'), and provides a mandatory conversational workflow. The example further reinforces the correct timing and confirmation step.

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