notebooklm-mcp-cli

Label

label

Create, rename, delete, and manage source labels in NotebookLM notebooks. Auto-label sources into thematic categories, assign sources to labels, and control label emojis.

Instructions

Manage source labels in a notebook. Unified tool for all label operations.

Labels let you organize sources into thematic categories. Requires 5+ sources for auto-labeling. Sources can belong to multiple labels simultaneously.

Supports: auto, list, reorganize, create, rename, set_emoji, move_source, delete

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Label display name (required for create and rename)
`emoji`	No	Emoji character for set_emoji (e.g. "📊"), or "" to clear
`action`	Yes	Operation to perform: - auto: AI auto-labels all sources into thematic categories - list: List current labels (triggers AI if none exist) - reorganize: Force AI re-categorization (requires confirm=True unless unlabeled_only=True) - create: Create a new empty label (requires name) - rename: Rename a label (requires label_id, name) - set_emoji: Set or clear emoji on a label (requires label_id, emoji) - move_source: Assign a source to a label (requires label_id, source_id) - delete: Delete label(s) permanently (requires label_id or label_ids, confirm=True)
`confirm`	No	Must be True for delete action and for reorganize with unlabeled_only=False
`label_id`	No	Label UUID (required for rename, set_emoji, move_source, delete)
`label_ids`	No	List of label UUIDs for batch delete (alternative to label_id)
`source_id`	No	Source UUID to assign (required for move_source)
`notebook_id`	Yes	Notebook UUID
`unlabeled_only`	No	For reorganize: if True, only label sources not yet in any label. If False (default), replaces ALL existing labels from scratch (requires confirm=True).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.11.5Sep 18, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description must carry behavioral context. It does disclose the 5+ source threshold for auto-labeling and that sources can belong to multiple labels simultaneously. However, the description itself does not surface that delete is permanent or that reorganize can replace all labels; those warnings live only in schema action text.

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 compact: a purpose line, two domain facts, and a bullet-style action list. It front-loads the key purpose and avoids verbose prose. The only minor redundancy is echoing the operation list that also appears in the action schema.

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 9 parameters and 8 actions, the description is appropriately high-level while the schema and output schema carry the detailed parameter and return contract. It supplies essential domain constraints, such as the 5+ source requirement and multi-label membership, needed for selection. A short warning about destructive operations would improve it, but the overall definition is mostly complete.

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 baseline is 3. The description lists operation names, but the input schema already explains each operation and its required parameters with more detail. No additional parameter-level meaning is added.

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 opens with 'Manage source labels in a notebook,' naming a specific resource and a management verb, and positions itself as the 'Unified tool for all label operations.' The supported action list concretely scopes the tool. It doesn't explicitly differentiate from related siblings like 'tag,' so it stops short of a 5.

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 tells the agent this is the central tool for label work ('Unified tool for all label operations') and gives a concrete condition: auto-labeling requires 5+ sources. It doesn't name exclusion cases or alternatives such as 'tag,' but the instruction to use this for label operations is clear.

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