Loading ToolBench
Enhanced MCP server for NotebookLM with structured prompts and source fidelity controls. Enables chat with Gemini 2.5 through NotebookLM via MCP with session-based contextual conversations, human-like browser automation, and persistent browser fingerprinting.
16 tools with inconsistent quality. Most have basic descriptions (50-150 chars) and visible schemas in handlers.ts, but several lack depth in parameter documentation. Naming is verb-driven and clear (ask_question, add_notebook, list_notebooks). Schemas are present but parameter descriptions are sparse or generic. Error handling guidance is minimal. The server exposes internal session management and browser control details that could be simplified for LLM reasoning. No tool annotations (readOnlyHint, destructiveHint) present despite clear write/destructive risk classifications in metadata.
Add a new notebook to the library with metadata (name, description, topics, content types, use cases, tags)
Ask a question to NotebookLM about a notebook. Requires authenticated session and notebook URL. Supports progress notifications and browser control options.
Reset browser state including cookies and browser profile. Requires explicit confirmation. Preserves the notebook library.
Close and terminate a specific session
Get system health status including authentication state, browser status, and service availability
Get aggregated statistics about the notebook library (total notebooks, total queries, etc.)
Get detailed information about a specific notebook by ID
Parameter descriptions are sparse or generic. Parameters like 'notebook_url', 'session_id', 'browser_options' lack guidance on expected format, constraints, or when to use them. LLMs cannot infer whether notebook_url accepts partial URLs, requires authentication, or specific domain patterns.
No tool annotations present despite clear risk classifications in metadata. Tools marked DESTRUCTIVE (remove_notebook, cleanup_data) and WRITE operations lack readOnlyHint, destructiveHint, or idempotentHint attributes in schema. LLMs cannot distinguish safe (read-only) tools from dangerous ones without explicit annotation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List all notebooks in the library with their metadata and usage statistics
List all active sessions with metadata and statistics
Re-authenticate with a different Google account when the current authentication is invalid or expired
Remove a notebook from the library
Reset a session to clear message history while maintaining the browser context and notebook URL
Search notebooks by query across name, description, and topics
Set a notebook as the active/default notebook for subsequent operations
Perform interactive Google login for NotebookLM access. Opens a browser window for manual login with a 10-minute timeout.
Update metadata of an existing notebook in the library
Output schemas are not documented in tool definitions. List tools (list_notebooks, list_sessions) do not specify returned field names, types, or structure. Agents cannot plan downstream tool calls or extract the right data without knowing what fields are available.
Error handling provides no recovery guidance. Tool descriptions do not explain what errors might occur, what they mean, or what the LLM should do next. For example, ask_question may fail due to invalid notebook_url, expired session, or authentication state, but none are documented with recovery steps.
Internal session/browser management parameters (session_id, browser_options, show_browser) leak implementation details into the tool interface. Users say 'ask a question' not 'ask_question with session_id and browser_options'. These should be abstracted away or automatically managed, not exposed as required/optional parameters that confuse LLM decision-making.
Confirmation pattern not implemented for destructive operations. remove_notebook and cleanup_data lack dry-run or explicit confirmation mechanisms. An LLM could accidentally delete all notebooks or wipe browser state on a misunderstanding.
Multiple tools operate on notebooks but lack clear output chaining. If add_notebook returns, what ID does select_notebook expect? Does get_notebook's 'id' parameter match the returned field name? Mismatched naming forces discovery detours.
Tool descriptions are under typical baselines (baseline 194 chars; many here are 40-70 chars). list_notebooks (50 chars), get_notebook (50 chars), get_health (55 chars) provide minimal context for when or why to call them vs similar tools. Descriptions should be 50-200 chars per Arcade baseline.