NotebookLM MCP Server (Security Hardened)

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide key behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false), covering safety and idempotency. The description adds valuable context beyond this: it specifies the return format ('query entries with question, answer, notebook, session, and timing info') and implies search functionality ('Search through question and answer content'), which helps the agent understand output structure and capabilities. No contradictions with annotations are present.

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 front-loaded with the core purpose in the first sentence, followed by a bulleted list for usage guidelines and a final sentence on return values. Every sentence earns its place by adding clarity or utility without redundancy. It is appropriately sized for a tool with multiple parameters and clear use cases, avoiding unnecessary verbosity.

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 moderate complexity (5 parameters, no output schema), the description is largely complete: it explains purpose, usage, and return format. However, it lacks details on pagination or ordering of results, which could be relevant for the 'limit' parameter. Annotations cover safety aspects, but without an output schema, the description could benefit from more specifics on result structure (e.g., pagination 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 100%, with all 5 parameters well-documented in the input schema (e.g., 'session_id' for filtering by session, 'search' for pattern matching). The description does not add significant parameter semantics beyond the schema, as it only mentions 'Search through question and answer content' which aligns with the 'search' parameter. Given the high schema coverage, a baseline score of 3 is appropriate, as the description provides minimal extra parameter insight.

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 tool's purpose: 'Retrieve past NotebookLM queries and answers for reviewing research sessions.' It specifies the verb ('Retrieve'), resource ('past NotebookLM queries and answers'), and context ('reviewing research sessions'), distinguishing it from siblings like 'get_notebook_chat_history' or 'list_sessions' by focusing on query-level history rather than broader chat or session listings.

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 provides usage guidelines with a bulleted list: 'Use this tool to: - Review past research conversations - Find specific information from previous queries - Track which notebooks and sessions you've used - Search through question and answer content.' This clearly indicates when to use this tool versus alternatives like 'get_notebook_chat_history' (for chat-level history) or 'list_sessions' (for session metadata), offering practical scenarios without misleading exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.