Skip to main content
Glama
Sign In
m4yk3ldev

NotebookLM MCP

by m4yk3ldev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Start research

research_start

Start a web or Google Drive research task on a topic in NotebookLM, then poll its status and import chosen sources into your notebook.

Instructions

Start a NotebookLM research task that searches the web, or the user's Google Drive, for sources on a topic. Deep mode is more thorough and slower than the default fast mode. Returns a task_id: poll research_status with it, then import the results you want with research_import.

Input Schema

NameRequiredDescriptionDefault
modeNoMode: deep, fast (default: fast)
queryYesTopic or question to research
sourceNoSource: drive, web (default: web)
notebook_idYesNotebook ID, as returned by notebook_list or notebook_create

Output Schema

NameRequiredDescriptionDefault
statusYes
messageNoHuman-readable outcome or next step
task_idYesPass to research_status and research_import

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • 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"
+    },
+    "task_id": {
+      "description": "Pass to research_status and research_import",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "task_id"
+  ],
+  "type": "object"
+}
  2. Changed2 schema fields changedv0.4.0
    • 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 / query / description
      Previous value: -"Research query"New value: +"Topic or question to research"
  3. First observedv0.3.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false) already signal a non-idempotent, open-world write; the description adds genuinely new behavior — that the task runs asynchronously and must be polled via research_status, and that deep mode is slower but more thorough. It does not mention rate limits or cost, keeping it below a 5.

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?

Three tight sentences, each carrying distinct information: what the tool does, the mode tradeoff, and the follow-up workflow. Nothing is redundant and the core purpose is front-loaded.

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?

An output schema exists, so return-value detail is unnecessary, and the description covers what an agent still needs: the returned task_id, the required polling step, and the import step. For a 4-parameter async research tool, nothing critical is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning about the mode parameter (deep is more thorough and slower than the default fast mode) rather than merely restating the enum values. The source distinction (web vs the user's Drive) and the query's role as topic/question are also clarified.

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?

States a specific verb+resource — 'Start a NotebookLM research task' — and names the scope (web or Google Drive sources on a topic). It is clearly distinguishable from the sibling research_status (polling) and research_import (ingest) tools, which it explicitly routes to.

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?

Provides explicit downstream routing: poll with research_status using the returned task_id, then import with research_import. It also explains the deep/fast tradeoff so the agent can pick a mode. It does not state conditions under which not to start research, or prerequisites like notebook existence, so it stops short of full when/when-not coverage.

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

Deploy Server

Other Tools