Loading ToolBench
The NotebookLM MCP server that actually works. Auto-healing auth, zero config, one command.
OneClickLM provides 6 tools with clear, present descriptions and explicit JSON Schema definitions. All tools have actionable descriptions (100-200 chars range) and well-typed parameters. However, there are gaps: no output schemas documented, missing parameter descriptions for conditional parameters (e.g., when source_add type='url' vs type='text'), no error recovery guidance, and no tool annotations (readOnlyHint/destructiveHint). The source_add tool has a confusing optional parameter pattern where 'url', 'title', and 'content' are conditionally required based on 'type' but this dependency is only weakly documented in descriptions. Parameter validation and error messages are generic. Overall, definitions are above-average for community servers but lack polish expected in production tools.
Create a new empty NotebookLM notebook. After creating, use source_add to add content.
Get detailed information about a specific notebook, including all its sources and their status.
List all your NotebookLM notebooks. Returns notebook IDs, titles, and source counts. Use this first to discover available notebooks.
Ask a natural language question to a NotebookLM notebook. The AI will analyze all sources in the notebook and return a grounded, cited answer. This is the main tool for getting information from your notebooks.
Add a source to a NotebookLM notebook. Supports URLs (web pages, articles), YouTube videos, and plain text content. The source will be processed and made available for queries.
source_add has conditional required parameters (url required if type='url', title+content required if type='text') but this constraint is not formally expressed in the schema. The schema shows url, title, and content as optional siblings, forcing the LLM to understand the dependency from description text alone. This violates the constrained-input pattern.
No output schemas documented for any tool. The handleToolCall function returns text-wrapped results, but the structure of returned objects (e.g., what fields are in a notebook object, what format the query answer takes) is never formally specified. LLMs cannot plan downstream chaining without seeing response schemas.
Error messages in handleToolCall are generic ('Error: notebook_id is required') and provide no recovery guidance. When a notebook is not found, the code returns a bare 'Notebook not found: {id}' with no suggestions for discovering valid IDs. This violates the recovery-guide pattern.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 59 | - | v1 |
List all sources in a NotebookLM notebook, including their titles and processing status (ready, processing, error).
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing from all tool definitions. The risk metadata (READ_ONLY vs WRITE) is documented in the rubric but not exposed in the schema. This prevents clients from automatically restricting dangerous tools or optimizing read-only execution.
Large result sets (e.g., notebook_list returning all notebooks, source_list returning all sources) have no pagination mechanism. If a user has hundreds of notebooks or sources, the entire list will be returned. The descriptions do not mention limits or pagination parameters.
The source_add tool returns text like 'Source added to notebook!' but does not return the ID or full details of the added source. This breaks the tool-chain pattern: downstream tools (like notebook_query) need the source ID to reference it, but source_add doesn't provide it.