Skip to main content
Glama
Sign In
m4yk3ldev

NotebookLM MCP

by m4yk3ldev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get source text

source_get_content
Read-onlyIdempotent

Retrieves the full extracted text of a NotebookLM source, flattening tables into cell | cell rows. Use it when you need verbatim source content instead of a query-based answer.

Instructions

Get the full text NotebookLM extracted from a source, with tables flattened to "cell | cell" rows. Returns { text }, which can be long: a long Wikipedia article came to about 100,000 characters. Prefer notebook_query to answer questions; use this when the user needs the verbatim text.

Input Schema

NameRequiredDescriptionDefault
source_idYesSource ID, as listed in the notebook's sources by notebook_get
notebook_idYesNotebook ID, as returned by notebook_list or notebook_create

Output Schema

NameRequiredDescriptionDefault
textYesThe extracted text; null if NotebookLM returned none
statusYes
messageNoHuman-readable outcome or next step

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"
+    },
+    "text": {
+      "description": "The extracted text; null if NotebookLM returned none",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "status",
+    "text"
+  ],
+  "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 / source_id / description
      Previous value: -"The document ID to retrieve"New value: +"Source ID, as listed in the notebook's sources by notebook_get"
  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 already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the return shape { text }, the fact that tables are flattened to 'cell | cell' rows, and a concrete size warning (~100,000 chars for a long Wikipedia article).

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 tightly packed sentences, front-loaded with the core purpose, then output format/size, then routing guidance. No filler; every clause carries information an agent needs.

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?

Despite an output schema existing, the description still communicates the practically important return characteristics (shape, table flattening, potential length) that an agent needs for context-window planning. Combined with the routing advice, nothing material is missing.

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 both notebook_id and source_id are already documented in the schema with their provenance (notebook_get, notebook_list/create). The description adds no further parameter meaning, so baseline 3 applies.

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 (get) and resource (full source text extracted by NotebookLM), and immediately distinguishes itself from source_get by clarifying it returns the extracted text rather than metadata. The table-flattening detail makes the output format unmistakable.

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?

Explicitly routes the agent: prefer notebook_query for answering questions, and use this only when the user needs verbatim text. Both the when and the when-not are named with the alternative tool.

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