MCP server for NotebookLM that enables creating notebooks, managing sources, performing deep web research, generating AI artifacts, and querying notebook contents via Google's NotebookLM API
Server defines 7 tools with explicit schemas and descriptions visible in src/index.ts. All tools have names, descriptions, and input schemas registered via ListToolsRequestSchema handler. However, quality is inconsistent: descriptions are present but often generic (40-80 chars), parameter descriptions are minimal, output schemas are undocumented (critical gap), and error handling guidance is absent. Many parameters lack meaningful constraints or relationship documentation. The server follows the minimum viable pattern registration but falls short of production-grade tool design. No output schemas are documented, agents cannot reason about response fields for downstream chaining. This is typical of community servers that expose raw API capabilities without careful LLM optimization.
Update authentication tokens. Use method='browser' to open a browser for Google login, or method='manual' to provide cookies directly.
Generate AI artifacts (Audio Overview, Video, Quiz, Slides, etc.).
Create, rename, delete, list, get details, or configure chat for a notebook.
Add, rename, delete, sync, or check freshness of sources in a notebook.
List or delete studio artifacts (Audio Overviews, Mind Maps, etc.).
Perform deep web research and automatically import findings into a notebook.
No output schemas documented for any tool. Agents cannot reason about response fields, requiring guesswork about what data is returned and how to chain tools.
Multiple tools use generic action-enum pattern (manage_notebook, manage_source, manage_studio) instead of splitting into single-action tools. This violates the single-responsibility principle and forces agents to reason about which action to select rather than selecting the right tool.
Parameter descriptions are missing or trivial (5-20 chars) for most parameters. 'query', 'type', 'content', 'source_id', 'conversation_id', 'config' lack meaningful guidance on format, expected values, or constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Ask questions about the notebook sources.
Conditional parameter requirements are documented in text but not enforced in schema. E.g., 'custom_prompt required if goal=custom' is mentioned but schema allows custom_prompt without enforcing dependency. Similarly, 'artifact_id required for delete' is not in the required array.
No error recovery guidance. Tool descriptions do not tell agents what to do if a call fails: 'Is this retryable? Should I ask the user? Are there alternative approaches?'
Credentials (cookies, csrfToken) are exposed as tool parameters. This violates secret injection pattern: agent traces will log these sensitive values. Should use server-side secret injection via environment variables or file-based config (which the code does support via ~/.notebooklm-mcp/auth.json, but authenticate() tool still accepts raw credentials as params).
'config' parameter in generate_artifact is type 'object' with no properties defined. Agents cannot know what keys to pass (language? format? custom_voice_id?). Should define nested schema with explicit fields per artifact type.
No pagination support documented. If manage_notebook list or manage_studio list return many items, agents have no way to paginate. Tools should include limit and offset/cursor parameters and return total count.