Provides seamless integration with Google NotebookLM, enabling AI agents to manage notebooks, add sources (including YouTube, Google Drive, and local files), query notebook content, and generate audio overviews and mind maps.
Allows adding Google Drive files (Docs, Slides, etc.) as sources to notebooks and syncing them to keep content up-to-date.
Enables adding YouTube videos as sources to notebooks, allowing agents to query video content and use it for grounded answers.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@notebooklm-mcp-server Ask my notebook about quantum computing breakthroughs"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Google's Gemini Notebook (renamed from NotebookLM in July 2026) is the best grounded-answer engine on the market: it only answers from the sources you give it, with citations. This MCP server hands that power to your AI agents — Claude, Gemini, Antigravity, Cursor and any other MCP client — so they can build notebooks, run Deep Research, generate podcasts, videos, quizzes, flashcards, reports and mind maps, take notes, and share the results with your team. All programmatically, with zero hallucinations.
NotebookLM is now Gemini Notebook. Google renamed the product on July 16, 2026 (see notebook.google). Same product, same notebooks, same API surface — this server keeps working unchanged, and the npm package keeps its notebooklm-mcp-server name.
Related MCP server: NotebookLM MCP
npm install -g notebooklm-mcp-serverThe server checks for updates on startup and keeps itself current automatically.
npx -y notebooklm-mcp-server auth # authenticate
npx -y notebooklm-mcp-server start # run the serverRun the interactive login (opens a Chromium window):
npx notebooklm-mcp-server authSign in with your Google account. When the notebook list appears, the session cookies (including Google's rotating __Secure-1PSIDTS token) are captured and saved to ~/.notebooklm-mcp/auth.json.
Done — the server loads the session automatically and refreshes the rotating token by itself.
If the session ever expires, runnpx notebooklm-mcp-server auth again in a terminal, then call the refresh_auth MCP tool (or just restart your client) to pick up the new cookies without reconfiguring anything.
claude mcp add notebooklm -- npx -y notebooklm-mcp-server startAdd to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"notebooklm": {
"command": "npx",
"args": ["-y", "notebooklm-mcp-server", "start"]
}
}
}Antigravity's CLI manages MCP servers through a JSON config file:
Global: ~/.gemini/config/mcp_config.json
Per-workspace: .agents/mcp_config.json in your project
{
"mcpServers": {
"notebooklm": {
"command": "npx",
"args": ["-y", "notebooklm-mcp-server", "start"]
}
}
}Then type /mcp in the Antigravity prompt panel to open the MCP Manager: check the connection status ring, reload the config, or inspect logs — no restart needed. Your agents can now cite real sources in every mission.
The IDE reads the same config files as the CLI (~/.gemini/config/mcp_config.json or .agents/mcp_config.json). Alternatively, open the MCP Store panel, choose Add custom server, and paste the same JSON snippet. Reload the server list and the NotebookLM tools appear in the agent's toolbox.
gemini mcp add notebooklm --scope user -- npx -y notebooklm-mcp-server startAdd to .cursor/mcp.json in your project (or ~/.cursor/mcp.json globally):
{
"mcpServers": {
"notebooklm": {
"command": "npx",
"args": ["-y", "notebooklm-mcp-server", "start"]
}
}
}Add the same mcpServers block to ~/.codeium/windsurf/mcp_config.json.
In Cline: MCP Servers → Configure and add the same mcpServers block shown above.
47 tools, grouped by what they do. Full parameter signatures live in docs/TOOLS.md.
Tool | Description |
| List all notebooks with sources and metadata |
| Create a new notebook |
| Get one notebook's details and source IDs |
| Rename a notebook |
| Delete a notebook (requires |
| AI notebook guide: summary + suggested questions |
| AI-suggested prompts to ask about the sources |
Tool | Description |
| Toggle public link and/or manage collaborators by email |
| Read the current sharing configuration |
Tool | Description |
| Add a website or YouTube video as a source |
| Add pasted text as a source |
| Add a Google Drive document as a source |
| Upload a local PDF / TXT / Markdown file |
| AI guide for one source: summary + key topics |
| Rename a source |
| Check if a URL/Drive source has newer content |
| Re-sync a Drive source to the latest content |
| Delete a source (requires |
Tool | Description |
| Ask questions about the sources, with citations |
| Read the latest conversation's Q&A turns |
| Clear the chat history (requires |
| Set the chat persona (default / learning guide / custom) and response length |
Tool | Description |
| Launch web or Drive research (fast ≈30s / deep ≈5min) |
| Check research progress and discovered sources |
| Import the discovered sources into the notebook |
Tool | Description |
| Podcast-style Audio Overview (formats: deep dive, brief, critique, debate) |
| Video Overview (9 visual styles, from whiteboard to anime) |
| Written report from the sources |
| Flashcards (quantity and difficulty options) |
| Interactive quiz (quantity and difficulty options) |
| Infographic (landscape / portrait / square) |
| Slide deck |
| Structured data table |
| Check generation status of all artifacts |
| Delete a studio artifact |
Tool | Description |
| Fetch generated content (quiz/flashcards HTML, mind map JSON) |
| Rename an artifact |
| Export an artifact to Google Drive (Docs or Sheets) |
Tool | Description |
| Create a note |
| List all notes |
| Update a note's content/title |
| Delete a note (requires |
| Generate a mind map JSON from sources |
| Save a mind map to the notebook |
| List saved mind maps |
| Delete a mind map |
Tool | Description |
| Reload session cookies from disk after re-running |
Real prompts you can paste into any connected agent — it picks the right tools by itself.
"Research the latest on solid-state batteries with deep research, build a notebook called 'Solid State 2026' with the best sources, and generate a brief audio overview in English. Give me the link when it's done."
The agent chains notebook_create → research_start(mode: deep) → research_poll → research_import → audio_overview_create(format: brief) → studio_poll, and returns the notebook URL with the finished podcast.
"Take the three PDFs in ./lectures, put them in a new notebook, and make me a hard quiz plus flashcards on the key concepts. Show me the quiz questions here."
The agent runs notebook_add_local_file per PDF, then quiz_create(difficulty: hard) + flashcards_create, polls with studio_poll, and pulls the questions out with artifact_content_get.
"Build a briefing notebook from these five links about our competitor, write a report, export it to Google Docs, and share the notebook with ana@example.com as a viewer."
The agent chains notebook_add_url ×5 → report_create → studio_poll → artifact_export(format: docs) → notebook_share(user_email, user_role: viewer) — and your teammate finds the notebook and the Doc waiting.
Symptom | Fix |
| Your Google account enforces Device Bound Session Credentials (DBSC) — default-on for Workspace and most personal accounts. DBSC ties the session to a device-held key, so cookies exported from the browser are refused by the API. Cookie-extraction clients cannot bypass this; use a Google account without DBSC enforcement. |
| Update to ≥ 3.0.8 — older versions missed Google's rotating |
| Google sessions eventually expire. Run |
Studio generation stuck on | Long sources take a while — keep polling |
RPC errors after a Google update | Google occasionally rotates internal build labels. Update the package; if it persists, open an issue. |
git clone https://github.com/moodRobotics/notebooklm-mcp-server.git
cd notebooklm-mcp-server
npm install
npm run build
npm run typecheckArchitecture notes live in docs/ARCHITECTURE.md, the roadmap in docs/ROADMAP.md.
This README is available in English, Español, Français, Português and Deutsch. If you edit one, please keep the others in sync (npm run docs:check).
MIT — Developed with ❤️ by moodRobotics.
This is an unofficial community project. It is not affiliated with or endorsed by Google. It relies on reverse-engineered internal APIs that may change without notice; use it with a Google account you are comfortable automating.
Generate an Audio Overview (podcast) for the notebook
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code (en, es, fr, etc.) | |
| source_ids | No | Sources to include (empty for all) | |
| notebook_id | Yes | ||
| focus_prompt | No | Custom instructions for the audio |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like async/polling, auth needs, or duration, but only states 'Generate' with no further context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and resource, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks completeness for a generation tool with 4 parameters and no output schema; no mention of return value, process duration, or async nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (below 80%), but the description adds no parameter info; it does not compensate for the undocumented 'notebook_id' or add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and specifies the resource as 'Audio Overview (podcast)' for a notebook, distinguishing it from sibling tools like video_overview_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., video_overview_create, infographic_create) or any prerequisites/trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure notebook chat settings (goal, response length)
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | Chat goal mode | |
| notebook_id | Yes | ||
| custom_prompt | No | Required when goal=custom (max 10000 chars) | |
| response_length | No | Response length preference |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Does not disclose whether the tool is idempotent, what state changes occur, or if it partially updates or overwrites all settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure. Could benefit from breaking into scope and details, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, description is insufficient. Does not explain behavior when goal=custom, required custom_prompt, or return value. User needs to infer from schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description mentions goal and response length but adds no meaning beyond their names. Schema covers 75% of parameters; notebook_id and custom_prompt are not elaborated in description. Does not explain goal modes or response length impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Configure' and resource 'notebook chat settings', listing specific settings (goal, response length). Distinct from sibling tools like notebook_create or notebook_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies configuration of chat settings but does not provide context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a data table from notebook sources
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code | |
| source_ids | No | ||
| notebook_id | Yes | ||
| focus_prompt | No | Focus/instructions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention whether the tool is idempotent, destructive, requires authentication, or what side effects occur (e.g., creating a persistent resource). Only states it 'generates' without further detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It front-loads the primary action but provides no additional details or organization, making it minimally viable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool among many siblings, with no output schema and moderate schema coverage, the description is too sparse. It does not explain the output format, usage patterns, or how parameters interact, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (language and focus_prompt described, source_ids and notebook_id not). The description adds no extra meaning beyond the schema; it does not explain how 'source_ids' relate to 'notebook sources' or the impact of 'focus_prompt'. Thus, it insufficiently compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Generate' and specifies the resource 'data table', which is distinct from sibling tools like 'infographic_create' or 'slide_deck_create'. However, it lacks detail about what kind of data table (e.g., structured tabular data) and how it relates to 'from notebook sources'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other creation tools. It does not specify prerequisites, limitations, or alternatives such as when to use 'report_create' or 'infographic_create' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate flashcards from notebook sources
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code | |
| source_ids | No | ||
| notebook_id | Yes | ||
| focus_prompt | No | Focus/instructions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'generate,' omitting critical details like whether the operation is synchronous, if it creates a new resource, what happens on invalid inputs, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but it is too brief to be informative. It lacks structure and essential details, trading off completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain return values, side effects, or how to correctly use the parameters, leaving the agent with insufficient information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (two parameters have descriptions, two do not). The description adds no parameter meaning beyond the schema, failing to clarify the purpose of notebook_id and source_ids, or how focus_prompt and language relate to flashcard generation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate flashcards from notebook sources' clearly states the tool's purpose with a specific verb (generate) and resource (flashcards from notebook sources), distinguishing it from sibling creation tools like audio_overview_create or data_table_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring a notebook with sources, or exclusions like other flashcard-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an infographic from notebook sources
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code | |
| source_ids | No | ||
| notebook_id | Yes | ||
| focus_prompt | No | Focus/instructions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'generate', which implies creation but does not specify whether the operation is destructive, requires authentication, has rate limits, or what happens to existing data. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it is under-specified. It lacks structure such as a summary of parameters or usage hints. While brevity is valued, it should include more useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is very incomplete. It does not explain the return value, pagination, error handling, or how the infographic is generated. The agent would lack essential context to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (2 of 4 parameters have descriptions). The tool description adds no meaning beyond the schema; it does not explain the role of notebook_id, source_ids, or how focus_prompt and language affect the output. It fails to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate an infographic from notebook sources' clearly indicates the action (generate) and the resource (infographic from notebook sources). However, it does not distinguish this tool from similar creation tools like slide_deck_create or report_create, which also generate visual outputs from notebook data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as report_create or video_overview_create. The description lacks any context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Mind Map from a notebook
| Name | Required | Description | Default |
|---|---|---|---|
| mind_map_id | Yes | ||
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a destructive action but provides no details about consequences, permissions needed, or whether deletion is reversible. No annotations to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but lacks necessary details. Not a tautology, but too brief to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotation, output schema, or parameter descriptions, the tool definition is incomplete for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Parameters 'mind_map_id' and 'notebook_id' are not explained; description does not clarify their format, origin, or how to obtain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'a Mind Map from a notebook'. It is distinct from sibling tools like mind_map_generate or mind_map_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or constraints mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Mind Map JSON from notebook sources
| Name | Required | Description | Default |
|---|---|---|---|
| source_ids | Yes | Source IDs to include |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the function without mentioning side effects, resource usage, or any constraints. This is insufficient for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It could benefit from slightly more detail, but it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool, no output schema, and full schema coverage, the description is minimally adequate. However, it lacks usage guidelines and behavioral transparency, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and the description adds no extra meaning beyond 'Source IDs to include'. This meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate', the output 'Mind Map JSON', and the input source 'notebook sources'. This distinguishes it from sibling tools like mind_map_save or mind_map_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to generate vs. save or list). There are no prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Mind Maps in a notebook
| Name | Required | Description | Default |
|---|---|---|---|
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation but does not explicitly state safety, permissions, or any constraints (e.g., pagination, sorting).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but too minimal. It could include brief additional context without becoming verbose, such as typical use or output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description should explain both input and output. It tells input (notebook_id implied) but not what the list returns (e.g., IDs, titles). This is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the notebook_id parameter beyond what the schema provides. It does not explain format, validation, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'Mind Maps' with a scope 'in a notebook'. It distinguishes from sibling tools like mind_map_delete, mind_map_generate, etc., but does not specify what information is returned (e.g., names, IDs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it does not mention that this should be used before generating or deleting mind maps, or how it differs from other list-like tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a generated Mind Map to a notebook
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Title for the mind map | |
| source_ids | Yes | ||
| notebook_id | Yes | ||
| mind_map_json | Yes | The Mind Map JSON from mind_map_generate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description does not reveal whether saving overwrites an existing mind map, requires specific permissions, or any side effects. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is front-loaded and immediately conveys the tool's core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (3 required), no output schema, and no annotations, the description fails to provide adequate context. It does not explain how to obtain mind_map_json, what source_ids are, or required permissions. The agent lacks information to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (only mind_map_json has a description). The tool description adds no new parameter details; it only mentions 'generated Mind Map' which relates to mind_map_json but does not explain notebook_id, source_ids, or title. The agent is left guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save a generated Mind Map to a notebook' clearly states the action (save), the object (generated Mind Map), and the destination (notebook). It effectively distinguishes this tool from siblings like mind_map_generate, mind_map_delete, and mind_map_list, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used after generating a mind map via mind_map_generate. However, it does not explicitly state when not to use it or provide alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a Google Drive document as a source
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Display title for the source | |
| doc_type | No | Type of Drive document | |
| document_id | Yes | Google Drive document ID | |
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, required permissions, or potential errors. The word 'Add' implies mutation, but no further details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is concise to the point of missing necessary details, which slightly lowers the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, 1 enum) and no output schema, the description does not provide enough context about return values, prerequisites, or how the tool fits with siblings. It is insufficient for an agent to use correctly without further knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the baseline is 3. The description adds no additional meaning beyond the schema; notably, the required parameter notebook_id lacks a description in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Add' and specifies the resource 'Google Drive document as a source'. However, it does not differentiate among sibling tools like notebook_add_local_file or notebook_add_url, which also add different types of sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or context for usage. The description merely states the action without any usage directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a local PDF or text/markdown file as a source
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the file (.pdf, .txt, .md) | |
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and minimal description, the tool fails to disclose critical behavioral traits such as whether the file is uploaded or referenced, size limits, error handling, or asynchronous behavior. The description only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, front-loading the key action and resource. However, it may be overly terse for a tool with no annotations or output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no output schema, and no annotations, the description is insufficient. It lacks details on file handling, validation, or return behavior, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only path has a description). The description adds context for the path parameter by specifying absolute path and allowed extensions, but fails to explain notebook_id. This partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add', the resource 'local file', and the supported file types 'PDF or text/markdown'. It effectively distinguishes this tool from siblings like notebook_add_drive or notebook_add_url by specifying 'local file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (e.g., notebook_add_drive, notebook_add_url). There are no prerequisites, exclusions, or alternative suggestions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add pasted text as a source to a notebook
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title for the text source | |
| content | Yes | The text content to add | |
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility for revealing behavioral traits. It does not mention side effects, error conditions, authentication needs, content size limits, or whether adding text overwrites existing sources. This is insufficient for safe and correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it sacrifices necessary detail for brevity, so a 5 is not warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with 3 required parameters, no output schema, and no annotations. It does not explain return values, failure modes, or authentication context. Given the sibling tools, more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters described). The tool description adds no extra meaning beyond the schema descriptions; it does not clarify format, length limits, or encoding for the 'content' parameter. Baseline 3 is appropriate since coverage is moderate but the description adds no new value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Add') and the resource ('pasted text as a source to a notebook'). It effectively distinguishes from sibling tools like notebook_add_url, notebook_add_drive, and notebook_add_local_file by explicitly mentioning 'pasted text'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., notebook_add_url or notebook_add_local_file). The description lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a URL (website or YouTube) as a source to a notebook
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to add (website or YouTube) | |
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavior. It merely states the action without disclosing side effects, authentication needs, or whether the URL is fetched/validated. This is insufficient for a safe selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key purpose. No extraneous words. However, it could include more relevant detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only 2 parameters, the description leaves many questions unanswered (e.g., what happens after adding? Are there constraints on the URL?). For a simple tool but with no behavioral context, it's incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'url' has a description). The tool description repeats the schema's detail for 'url' but adds nothing for 'notebook_id'. With half the parameters undocumented and no extra context, the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Add), the resource (a URL), and the target (a notebook). It also specifies the types of URLs (website or YouTube). This distinguishes it from sibling tools like notebook_add_drive or notebook_add_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description only states what it does, not context or exclusions. Sibling names provide some implicit distinction but the description itself lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new notebook
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title for the new notebook |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose any behavioral traits beyond the obvious create action. Lacks details on side effects, permissions, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence. Could be slightly improved with additional context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with no output schema or annotations, the description is minimally adequate but lacks any behavioral or result context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (Create) and resource (a notebook). Distinguishes from sibling tools like notebook_add_drive that modify existing notebooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like notebook_add_text or notebook_rename. Missing context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a notebook permanently. IRREVERSIBLE.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be true to confirm deletion | |
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Emphasizes 'permanently' and 'IRREVERSIBLE', clearly conveying the destructive nature. Without annotations, this is essential. However, lacks details on permissions, cascading effects, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single sentence plus a shout-out to irreversibility. All information is front-loaded and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with a confirm parameter, the description adequately states the key effect. However, it could mention what happens if the notebook doesn't exist, confirm usage, and access requirements. Lacks output schema guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no value beyond the schema. 'notebook_id' has no schema description and is not elaborated in the tool description. 'confirm' is already described in schema. Schema coverage is 50% but description doesn't compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a notebook permanently' and distinguishes it from sibling tools like notebook_create, notebook_rename, etc. The resource and operation are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or alternative approaches (e.g., soft delete, trash). Lacks context on prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all notebooks with their sources and metadata
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It states the tool 'list[s] all notebooks' implying a read-only, non-destructive operation, but does not mention potential pagination, performance characteristics, or whether it returns all notebooks at once.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It efficiently conveys the core purpose and included data, earning its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description adequately covers what it does and what it returns ('sources and metadata'). However, without an output schema, more detail on the return format (e.g., list of notebook IDs with nested metadata) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. No parameter documentation is needed, and the description does not add any parameter-related information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List all notebooks' with a specific resource and adds context about included data ('sources and metadata'). It implicitly distinguishes from siblings like 'notebook_query' by indicating it returns all notebooks without filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'notebook_query' or 'mind_map_list'. It does not mention any exclusions or prerequisites, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask AI about EXISTING sources in a notebook. NOT for finding new sources.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Question to ask about the notebook sources | |
| source_ids | No | Specific source IDs to query (omit for all) | |
| notebook_id | Yes | ||
| conversation_id | No | For follow-up questions in same conversation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the core behavior (querying existing sources) but lacks details on side effects (read-only?), response format, or limitations like rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and a clear negative constraint. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description leaves gaps: return value format, synchronization behavior, and what 'ask AI' entails. Adequate but not fully complete for a query tool with multiple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (75%), so baseline is 3. The description adds no extra parameter meaning beyond what's in the schema; it only reinforces the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool is for querying existing sources in a notebook and clarifies it is not for finding new ones, distinguishing it clearly from sibling tools like notebook_add_* and research_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use (ask about existing sources) and a strong exclusion (not for finding new sources), implying alternatives exist. Missing explicit naming of alternative tools, but the negative clause suffices for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a notebook
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | New title | |
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist and the description discloses no behavioral traits such as permissions, side effects, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single under-specific sentence, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two required parameters and no output schema, the description fails to provide necessary context for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the tool description adds no extra meaning beyond the schema for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Rename a notebook' is a tautology, simply restating the tool name without adding specificity or distinguishing from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool vs alternatives like notebook_add_text or notebook_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload authentication cookies from disk. Run 'notebooklm-mcp-server auth' in a terminal first if cookies are expired, then call this tool to pick up the new cookies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses that the tool reloads cookies from disk, implying a read-only refresh operation with no destructive side effects. It does not detail error handling (e.g., missing file) but for a simple state refresh, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states the action, second provides usage context. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully covers what the tool does and how to use it. The external prerequisite is noted, ensuring the agent understands the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is fully covered. The description does not need to add parameter details. It adds value by explaining the context of the reload (disk-based cookies).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reloads authentication cookies from disk. The verb 'reload' and resource 'authentication cookies' make the purpose unambiguous. Sibling tools are unrelated to auth, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: after running the terminal command if cookies are expired. It also provides an alternative action (run the command) if cookies need renewing, which helps the agent decide when not to call this tool alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a written report from notebook sources
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code | |
| source_ids | No | ||
| notebook_id | Yes | ||
| focus_prompt | No | Focus/instructions for the report |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states it generates a report, but does not disclose behavioral traits like synchronous/asynchronous nature, required permissions, rate limits, or what happens to the report after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. However, it is front-loaded with key info but lacks structure (e.g., bullet points or sections) and could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and many sibling tools, the description is insufficient. It does not explain what a 'written report' entails, how the notebook sources are used, or what the return value looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (language and focus_prompt have descriptions; notebook_id and source_ids lack descriptions). The description does not provide any additional meaning beyond the schema, so for undocumented parameters, the agent has no guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and clearly identifies the resource ('written report from notebook sources'). It distinguishes from sibling tools like slide_deck_create or infographic_create by specifying 'written report', but does not explicitly differentiate from similar report tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as slide_deck_create or infographic_create. There is no mention of prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import discovered research sources into a notebook
| Name | Required | Description | Default |
|---|---|---|---|
| sources | Yes | Sources array from research_poll results | |
| task_id | Yes | Research task ID from research_poll | |
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Import... into a notebook', which implies a write operation, but does not describe side effects, idempotency, error states, or what happens to existing data. This is insufficient for an agent to understand the tool's behavior fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with 7 words, containing no redundant or irrelevant information. It is optimally concise for a simple import operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required parameters, no output schema, and no annotations, the description is too brief. It lacks details on return values, error conditions, prerequisites (e.g., research must be started and poll completed), and the behavior of the 'sources' array. A more complete description would include these aspects for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema coverage, the schema already documents two parameters. The description adds no additional meaning or context for any parameter, including the undocumented 'notebook_id'. It fails to compensate for the missing schema description or provide usage constraints (e.g., format of sources array).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Import' with a clear resource 'discovered research sources' and destination 'into a notebook'. It clearly distinguishes from sibling tools like research_start and research_poll, which handle different stages of the research workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as part of a research workflow after polls, but provides no explicit guidance on when to use or avoid it, nor does it mention prerequisites or alternatives. The context from sibling tools helps, but the description alone lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll for research status and results
| Name | Required | Description | Default |
|---|---|---|---|
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions polling for status and results, omitting side effects, rate limits, or behavior when research is not in progress. This is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at one sentence, but this conciseness sacrifices substance. It is under-specified and does not earn its place with sufficient information, so the score is low.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one parameter, no output schema), the description is incomplete. It fails to explain what the return value is, how to interpret poll results, or whether polling is blocking. This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'notebook_id' has no description in the schema or in the tool description. The description does not explain what it refers to or how to use it, providing no added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'poll' and the resource 'research status and results', giving a basic idea of the tool's purpose. However, it does not differentiate from sibling tools like research_start or research_import, resulting in moderate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives, such as research_start or other polling tools. The description lacks context for proper usage, earning a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start web or Drive research to find NEW sources. Workflow: research_start → research_poll → research_import
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | fast (~30s, ~10 sources) or deep (~5min, ~40 sources, web only) | |
| query | Yes | What to search for | |
| source | No | Where to search | |
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions starting research but doesn't disclose that this is an asynchronous operation returning a research ID, or any auth or rate limit considerations. The behavior beyond initiation is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a workflow hint, front-loading the key action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value (likely a research ID for polling), the asynchronous nature, and does not compensate for the missing parameter description (notebook_id). Given no annotations or output schema, the description is incomplete for a tool with 4 parameters and a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters have descriptions). The tool description adds context about seeking 'NEW sources' but does not add parameter-specific semantics beyond what the schema already provides. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'start', the resource ('web or Drive research'), and the purpose ('find NEW sources'). It also provides a workflow sequence (research_start → research_poll → research_import), distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as the first step in a research workflow. It provides explicit next steps (poll, import), giving clear context. However, it doesn't state when not to use it or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a slide deck from notebook sources
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code | |
| source_ids | No | ||
| notebook_id | Yes | ||
| focus_prompt | No | Focus/instructions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'generate', implying creation, but lacks details on side effects, permissions, or asynchronous behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is compact but omits necessary detail. It is front-loaded but insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description fails to cover key aspects like parameter relationships, return behavior, or result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% but description adds no parameter-level explanation. It does not elaborate on source_ids or focus_prompt beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'generate' and resource 'slide deck' with source 'notebook sources'. It clearly distinguishes from sibling tools like infographic_create or report_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a source permanently. IRREVERSIBLE.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be true to confirm deletion | |
| source_id | Yes | Source ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses permanence and irreversibility, which are critical for a destructive operation. However, lacks details on cascading effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and front-loaded: 'Delete a source permanently. IRREVERSIBLE.' Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a simple destructive tool with two well-documented parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions; the description reinforces the irreversibility context but adds no new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a source' and the resource, distinguishing it from sibling tools like notebook_delete or mind_map_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives. The required 'confirm' parameter implies caution but is not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync a Google Drive source to get the latest content
| Name | Required | Description | Default |
|---|---|---|---|
| source_id | Yes | Source ID to sync |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It fails to mention potential side effects (e.g., overwriting local content) or prerequisites (e.g., authentication). The term 'sync' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, efficiently conveying the essential purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple sync tool with one parameter and no output schema, the description provides the bare minimum. It lacks details on what 'latest content' entails, the nature of the sync (e.g., incremental or full), and error states, but it is not severely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the parameter 'source_id' having a clear description. The tool description adds no extra meaning beyond confirming the source is from Google Drive. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (sync) and the resource (Google Drive source) and the outcome (get latest content). However, it does not explicitly differentiate from sibling tools like 'research_import' or 'source_delete', which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when needing latest content from a Google Drive source) but provides no explicit guidance on when not to use it or alternatives. No comparison to other sync-like tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a studio artifact
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_id | Yes | ||
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Delete' without disclosing side effects (e.g., permanence, authorization needs, cascading deletions). The agent cannot infer behavioral traits beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the action. It is concise but could benefit from a brief note on what constitutes a studio artifact without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two required parameters and no output schema, the description is incomplete. It lacks information on how to obtain the IDs, whether deletion is reversible, or any return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what 'artifact_id' or 'notebook_id' represent. It adds no meaning to the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a studio artifact'). It distinguishes from sibling tools like 'studio_poll' and 'mind_map_delete' by specifying the general resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'source_delete' or 'mind_map_delete'. No context on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check status of studio artifacts (Audio, Video, Report, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| notebook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states it's a read-only check but lacks details on polling behavior (e.g., expected statuses, update frequency, side effects). No annotations provided to fill gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one short phrase) but under-specified—critical information like parameter details and usage context is missing, so conciseness does not serve completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool with one parameter, the description omits return value format, possible statuses, and usage patterns (e.g., polling interval), making it insufficient for autonomous agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'notebook_id' parameter's meaning or format beyond the schema, which only lists it as required string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check status') and the resource ('studio artifacts') with concrete examples like Audio, Video, Report. This distinguishes it from sibling tools which are creation or management operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like research_poll. No when-to-use or when-not-to-use conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Video Overview for the notebook
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code (en, es, fr, etc.) | |
| source_ids | No | Sources to include (empty for all) | |
| notebook_id | Yes | ||
| focus_prompt | No | Custom instructions for the video |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It does not mention authentication requirements, side effects on the notebook, or whether the operation is synchronous or asynchronous. For a generative tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is efficient and front-loaded. It contains no fluff, though it could benefit from a bit more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, generative nature), the description is too sparse. It does not describe the output format, processing time, or how it differs from similar tools like 'audio_overview_create'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (three of four parameters have descriptions), but the description adds no context beyond the schema. The required parameter 'notebook_id' lacks a schema description, and the tool description does not explain parameter roles or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate a Video Overview for the notebook' uses a specific verb ('Generate') and resource ('Video Overview'), clearly distinguishing it from sibling tools like audio_overview_create or infographic_create. However, it does not elaborate on what a 'Video Overview' entails, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as audio_overview_create or report_create. There is no mention of prerequisites or preferred scenarios, forcing the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v3.0.7audio_overview_createchat_configuredata_table_createflashcards_createinfographic_createmind_map_deletemind_map_generatemind_map_listmind_map_savenotebook_add_drivenotebook_add_local_filenotebook_add_textnotebook_add_urlnotebook_createnotebook_deletenotebook_listnotebook_querynotebook_renamerefresh_authreport_createresearch_importresearch_pollresearch_startslide_deck_createsource_deletesource_syncstudio_deletestudio_pollvideo_overview_createEach tool targets a distinct operation or resource. Overlaps exist (e.g., multiple 'create' tools) but are disambiguated by their specific output types (audio, video, flashcards, etc.) and clear descriptions.
Most tools follow a <resource>_<action> pattern (e.g., notebook_create, mind_map_delete). The outlier 'refresh_auth' uses verb_noun instead, which is a minor inconsistency.
29 tools cover a wide range of NotebookLM features (notebooks, sources, multiple outputs, research, mind maps, studio). While slightly high, each tool serves a distinct purpose within the scope.
The tool surface covers the full lifecycle: CRUD for notebooks and sources, generation of various outputs, research workflow, and studio management. No obvious gaps for the intended use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Google NotebookLM via natural language: create notebooks, add sources (PDF, URL, YouTube) and ask gr
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Persistent docs and memory for AI agents — read, write, organize & search a shared workspace.
Create and improve live, shared interactive documents with your agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/moodRobotics/notebooklm-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
