NotebookLM MCP

Import research results

research_import

Import web results from a completed research task into a notebook as sources. Optionally select specific sources; unreachable URLs are skipped, and it reports the count added.

Instructions

Add results of a finished research task to the notebook as sources. Only web results can be imported: without source_indices it imports every web result and skips Drive ones. NotebookLM fetches each URL and skips any it can't reach, so it returns "Imported X of Y research sources". If none could be fetched the call fails and the task shows import_failed; a retry may succeed.

Input Schema

Name	Required	Description
`task_id`	Yes	task_id from research_start
`notebook_id`	Yes	Notebook ID, as returned by notebook_list or notebook_create
`source_indices`	No	Indices into the task's sources as listed by research_status (omit to import every web result)

Output Schema

Name	Required	Description	Default
`status`	Yes
`message`	No	Human-readable outcome or next step

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.0Oct 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "message": {
+      "description": "Human-readable outcome or next step",
+      "type": "string"
+    },
+    "status": {
+      "const": "success",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedv0.4.0Oct 20, 2026

changedInput schema / properties / notebook_id / description

Previous value: -"The notebook ID"New value: +"Notebook ID, as returned by notebook_list or notebook_create"

changedInput schema / properties / task_id / description

Previous value: -"Research task ID"New value: +"task_id from research_start"

Changed1 schema field changedv0.3.2Oct 20, 2026

changedInput schema / properties / source_indices / description

Previous value: -"Specific source indices to import (omit for all)"New value: +"Indices into the task's sources as listed by research_status (omit to import every web result)"

First observedv0.3.1Aug 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations cover safety (readOnly=false, destructive=false, openWorld=true, idempotent=false); the description goes further by disclosing partial-success semantics ('fetches each URL and skips any it can't reach'), the return message shape, the import_failed error state, and that a retry may succeed. The one notable gap is that it never states whether re-importing the same results creates duplicate sources, which matters given idempotentHint=false.

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?

Four tight sentences, front-loaded with the action and the importable-scope constraint before the failure/retry details. No filler and each sentence carries distinct information (scope, filtering, partial success, failure).

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 3-parameter mutating tool with full schema coverage, annotations, and an output schema, the description covers scope, filtering, partial failure, and retry well. The only meaningful omission is duplicate-import behavior on repeated calls.

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%, including the meaning of source_indices and its omit behavior, so the baseline is 3. The description largely restates the same omit rule and adds only the Drive-skip detail, which is a modest gain rather than compensating for any missing schema information.

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 states a specific verb and resource ('Add results of a finished research task to the notebook as sources') and scopes it to a completed research task, which cleanly separates it from research_start and research_status in the sibling list. An agent can tell what this does without reading the schema.

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?

It gives a clear precondition ('a finished research task') and an explicit rule for when to pass source_indices versus omitting it, plus the constraint that only web results are importable. It stops short of naming what to do if the task is not yet finished (e.g., poll research_status) or of pointing at an alternative tool.

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