Source Search

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

With no annotations, the description carries the full burden and does well: it declares read-only behavior, caps results at 20, notes that native source UUIDs and titles are returned, and discloses the auth posture ("No Gemini or Opal credentials are used") plus the feature-flag requirement. The one soft tension is that max_results defaults to 8 while the text advertises a 20-passage ceiling without explaining that relationship.

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?

Five short lines, front-loaded with the core action and scope, then constraints, then the enable step. Nothing is padded; the one weak line is the credentials note, which is server-internal trivia rather than caller-relevant behavior.

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?

An output schema exists, so return-value detail is optional and the excerpt/UUID mention is a bonus rather than a necessity. Still, for a 5-parameter tool at 0% schema coverage, leaving snippet_chars and the max_results ceiling relationship unexplained, plus no failure mode when the flag is off, keeps it from being complete.

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%, so the description must compensate and only partly does. It adds real meaning for source_ids (must belong to this notebook) and implies a hard 20 cap on max_results, but query and snippet_chars get no explanation at all, leaving two of five parameters entirely undocumented.

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?

States a specific verb+resource pair ("Search relevant indexed passages") and scopes it to "within one NotebookLM notebook," which implicitly separates it from cross_notebook_query and notebook_query. It does not name either sibling explicitly, so the differentiation requires a small inference.

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 experimental/off-by-default note plus the NOTEBOOKLM_ENABLE_NATIVE_SOURCE_SEARCH=1 setup instruction is genuinely useful operational context. However, there is no guidance on when to choose this over notebook_query or cross_notebook_query, and no statement of what to expect when the feature flag is disabled (error vs. empty result).

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