notebooklm-mcp
Server Quality Checklist
Latest release: v3.1.2
- Disambiguation4/5
Most tools have distinct purposes, but some overlap exists (e.g., library_list vs notebook_list, library_discover vs library_add, and several note-related tools could be confused without careful reading). Descriptions are detailed enough to help agents differentiate.
Naming Consistency3/5The naming pattern is mostly noun_verb (e.g., notebook_list, source_add), but several tools break this pattern with verb_noun (e.g., generate_study_aid, research_sources, share_notebook), creating inconsistency. The server also mixes different verb styles (e.g., delete vs remove).
Tool Count3/537 tools is on the high side for a single service like NotebookLM. While each tool has a specific function, some are redundant or niche (e.g., vault_batch, server_cleanup, library_discover vs library_add), making the surface feel over-engineered.
Completeness4/5The tool set covers the main workflows: library and notebook CRUD, source management, content generation, notes, and auth. Minor gaps exist (e.g., no source update tool, no notebook rename tool, no collaborator management), but the core lifecycle is well-covered.
Average 4.3/5 across 37 of 37 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 8 community issues answered or closed in the last 6 months
- 83 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states the tool retrieves content, which implies read-only, but does not disclose error behavior (e.g., if note_title not found), idempotency, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous information. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, it lacks details on parameter relationships (e.g., note_id vs note_title precedence) and does not clarify the tool's behavior in edge cases, making it minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions, which are already clear. No value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieve), the resource (a specific note), and the content (title and text content). It distinguishes itself from sibling tools like note_list (which lists notes) and note_create (creates notes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, parameter priority (e.g., note_id vs note_title), or scenarios where session_id or notebook_url should be specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the output fields but does not disclose behavioral traits like read-only nature, authentication requirements, or any side effects. The phrase 'e.g. details' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical example, no wasted words. Could be slightly more structured, but it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail return values. However, it lacks information on prerequisites, side effects, or limitations. It is minimally complete for a simple listing tool but could be better.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all user notes and specifies the returned data (titles, IDs, timestamps). This distinguishes it from sibling tools like note_create or note_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all notes but does not explicitly state when to use this tool versus alternatives such as note_get (single note) or note_save_chat. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions that the tool returns sources and can import them via the `import` parameter, which covers the core behavior. However, it does not discuss authentication, rate limits, or side effects beyond importing, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. It front-loads the primary purpose. The phrase 'RPC-backed' is slightly jargon but not harmful. Every sentence serves a purpose, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return structure. It covers the main behavior and the import option. For a tool with 4 well-documented parameters, the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds a note about setting `import: true` to also add sources, but this is redundant with the schema's parameter description. No new semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Discover', the resource 'web sources for a notebook', and the method 'NotebookLM Fast Research'. It distinguishes itself from siblings like 'notebook_ask' or 'source_add' by specifying web research for a notebook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering and optionally importing web sources, but it does not explicitly state when to use this tool versus alternatives like 'library_discover' or 'source_add'. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds context about returned categories (sources, generated content) but no additional behavioral traits like pagination or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient bullet points, front-loaded with main action, every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return value details are not needed. Description covers the key categories returned. Adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, both parameters described. Description adds no extra meaning beyond what schema provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists sources and generated content in the current notebook, specifying categories. Verb and resource are explicit and distinct from siblings like content_download or content_generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives among siblings. Implied usage for viewing content, but no guidance on when to prefer over other list tools like library_list or notebook_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the source will be 'processed and indexed for use in conversations,' which provides some behavioral context beyond the annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true). However, it omits details about side effects like duplication on repeated calls, authentication needs, or rate limits. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using a bullet list for source types. Every sentence adds value, and it is appropriately front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, 1 required), the description provides sufficient context: it states the processing and indexing behavior. Since an output schema exists, return values need not be explained. It is well-rounded, though it could mention input size limits or processing delays.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all seven parameters with descriptions, achieving 100% coverage. The description lists supported source types but does not add deeper meaning beyond the schema (e.g., format constraints, size limits). Per the guidelines, baseline 3 is appropriate when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a source (document, URL, text, YouTube video) to the current NotebookLM notebook.' It enumerates five specific source types, making the action concrete and distinguishing it from sibling tools like source_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives. There is no mention of when not to use it or which sibling tools might be more appropriate for similar tasks (e.g., content_generate for creating content). The context of processing and indexing is helpful but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the safety and side-effect information. It clearly states the tool 'save' something, mentions the execution mode ('RPC-backed (no browser)'), and discloses the type of return value ('saved mind-map id and its JSON structure'). Permission requirements or effects on the notebook are absent, but the explicit save side effect and return description cover the core behavioral transparency needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and dense: two sentences with the primary action first, then a side-effect/return note. The 'RPC-backed (no browser)' clause is relevant and economical. The only slight awkwardness is the parenthetical, but it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 5-param schema with full descriptions and the description naming the saved id and JSON shape, the tool is largely callable. It does not state what further uses the returned JSON has, but for a generation tool that is enough. The description covers the key missing parts beyond the schema: execution side-effect and return value. A 4 seems fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions (100% coverage), so the schema already explains them. The description adds only a generic reference to 'a notebook's sources', which maps to notebook_id/notebook_url but does not disclose any extra syntactic or semantic detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action—'Generate and save a mind map'—and states the source ('a notebook's sources'), clearly distinguishing this from sibling tools like generate_study_aid or content_generate. The resource and verb are concrete and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (when you want a mind map from notebook sources) but does not explicitly state when to prefer it over sibling tools or how to choose between the two notebook identifiers. The context is inferable rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the behavioral disclosure. It adds relevant information by noting it is RPC-backed/no-browser and 'returns when generation completes', which signals synchronous, wait-for-completion behavior. It does'n detail persistence or side effects, but the key call-characteristic is surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It names the purpose, publishes constraints ('no browser'), and states completion semantics, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers returns, and the parameter schema covers individual inputs. However, the description does not clarify how the notebook is selected when both notebook_id and notebook_url are omitted, and it does not say whether a currently selected notebook context is expected. That missing routing context makes it not fully complete for anist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all five parameters with descriptions, so schema coverage is 100%. The description adds no specific parameter-level detail beyond mentioning flashcards and quiz, which matches the kind enum. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate'), names the resource ('a study aid from a notebook's sources'), and specifies the two forms it can take: flashcards or a quiz. This clearly distinguishes it from sibling tools like generate_mind_map or content_generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever the user wants flashcards or a quiz from notebook sources. However, it does not explicitly say when not to use it or mention alternatives such as generate_mind_map, leaving comparision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds 'detailed information' but no further behavioral traits (e.g., error handling, format). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words; front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id', and the description does not add meaning beyond 'The notebook ID' already in schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get detailed information') and the resource ('a specific notebook by ID'), distinguishing it from sibling tools like library_list (list all) and library_search (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you need details of a known notebook by ID) but provides no exclusions or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=false and idempotentHint=false, so the core behavioral traits are covered. The description adds that notes support markdown formatting, but does not disclose further behavioral aspects such as duplicate handling, size limits, or response structure. Given the annotation coverage, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences, with the purpose front-loaded. Every sentence adds context without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 4 parameters with 100% schema coverage, an output schema, and sibling tools, the description covers the purpose and usage context well. It lacks some behavioral details (e.g., idempotency, conflicts) and direct sibling differentiation, but remains functional for a simple create operation. Overall, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no new information beyond what the schema already provides for each parameter. It restates that content supports markdown, which is already in the schema. Therefore, no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb-resource pair: 'Create a note'. It specifies the location (NotebookLM Studio panel) and explains the role of notes as user-created annotations. This distinguishes it from sibling tools like note_save_chat and note_to_source, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that notes are for saving research findings, summaries, etc., providing context on when to use this tool. However, it does not explicitly contrast with similar sibling tools like note_save_chat or note_to_source, missing an opportunity for clearer guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it extracts all messages and saves them as a formatted note with timestamps and attribution. This adds context beyond annotations (readOnlyHint=false, indicating a write operation) and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a process paragraph, a bulleted use-case list, and a note on output content. It is concise, though the use-case list could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low parameter complexity (3 optional params) and the presence of an output schema, the description adequately covers purpose, process, use cases, and output content. It does not address edge cases like empty chats, but overall is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions, achieving 100% coverage. The description adds minimal extra context, such as the default title 'Chat Summary', but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the current chat to a note, using the verb 'Save' and specifying the resource 'current NotebookLM chat/discussion'. It distinguishes from sibling tools like note_create (which creates a blank note) by specifying it extracts messages from a chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three use cases: preserving conversations, creating summaries, and saving history. It implies when to use this tool over alternatives, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the internal method (find by title, attempt native convert, fallback to extraction) and outcome (content available for RAG queries), adding context beyond the annotations. However, it does not cover failure modes or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and structured with a list of steps. It is somewhat lengthy but each sentence adds value; the step list could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail return values. It provides a use case and mentions optional parameters, but could include more context about prerequisites like the active notebook.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already documented. The description does not add significant additional meaning beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a note to a source document in NotebookLM, using a specific verb and resource. It distinguishes from sibling tools like note_create and source_add by focusing on conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('Use this when you want your note content to be included in NotebookLM's knowledge base'), but does not list alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the tool is a write operation. The description adds context that it requires user permission and a confirmation step, but doesn't elaborate on side effects (e.g., what happens on duplicate URL) or other behavioral details. With annotations present, the description provides marginal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections (when to use, workflow, rules, example). It is front-loaded with the core purpose. While verbose, every section serves a purpose for agent guidance. Minor redundancy in the workflow steps could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary context: prerequisites (try auto-discovery first), a detailed mandatory conversation workflow, rules, an example, and even instructions on how to get a NotebookLM share link. The existence of an output schema is noted, so return values are adequately covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add new parameter semantics beyond what the schema already provides for each parameter. The workflow mentions asking for URL, content, topics, etc., but that echoes the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add notebook with manually specified metadata'. It explicitly contrasts with the sibling tool 'auto_discover_notebook', distinguishing when each should be used. The verb 'add' and resource 'notebook' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (auto-discovery failed, user prefers manual control) and when not to use (prefer auto_discover_notebook first). It includes a mandatory conversational workflow with steps and rules, such as not adding without user permission and confirming before tool call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, so behavioral traits are covered. The description adds context by specifying 'your notebook library', which is helpful but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no superfluous words. Front-loaded with the core action and resource, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only stats tool with no parameters and good annotations, the description covers the essential purpose. Could mention scope or caching but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description correctly omits parameter details as none are needed. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'statistics about your notebook library', with examples like 'total notebooks, usage', distinguishing it from listing tools like library_list or notebook_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., library_list for listing items). The description implies it's for aggregate stats, but doesn't exclude other use cases or provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions RPC-backed and the three modes, but lacks details on side effects, permissions, rate limits, or reversibility of actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The purpose is front-loaded, and every word contributes meaning. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameters are well-documented, the description covers the main use cases. It lacks discussion of edge cases like duplicate names or empty label_ids, but overall is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining how parameters relate to actions (e.g., name only for create). It goes beyond the schema by clarifying the default action and conditional requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages a notebook's source labels with three specific actions (list, create, delete). It distinguishes itself from sibling tools by focusing on labels, while other tools handle notebooks, notes, or sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the default action and required parameters for each action (name for create, label_ids for delete). However, it does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint, idempotentHint, openWorldHint. The description adds authentication requirements and scraping behavior (navigates to homepage), which supplements the annotations without contradiction. It does not detail rate limits or speed, but overall adds useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear opening sentence, bullet points, and a note on authentication. It is slightly verbose but front-loaded with the core action. Every sentence adds value, but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is read-only with an output schema (present), the description covers purpose, use cases, auth requirement, and extracted data. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (show_browser) with descriptions. Schema coverage is 100%, so the description adds no extra meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scrapes NotebookLM homepage to list notebooks with IDs and names, using specific verbs like 'scrape' and 'extract'. It distinguishes from sibling tools like library_list by focusing on real-time account state via scraping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists four use cases (discover notebooks, get IDs, verify existence, find to delete). It lacks explicit 'when not to use' guidance, but the use cases are specific and actionable, providing clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses both read and write behaviors (toggle public link), mentions what information is returned (status, owner, collaborators). But lacks details on error conditions, permission requirements, or side effects beyond toggling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. First sentence states purpose, second explains parameter usage, third provides additional context. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 optional parameters and an output schema (not shown), description explains the return values (status, owner, collaborators) and usage modes. It covers the key behavioral aspects for a read/write tool, though lacks specifics on required parameter combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining the conditional behavior of `set_public` (omit for read, set for toggle) and clarifying that `notebook_id` and `notebook_url` are alternatives. This is beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads sharing status or toggles public link, with specific verb 'Read' or 'toggle' and resource 'notebook’s sharing status'. It distinguishes between the two modes, setting it apart from sibling tools like notebook_create or notebook_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions: omit `set_public` to read, set to true/false to toggle. Also mentions 'RPC-backed (no browser)' to clarify execution context. However, it does not discuss when not to use this tool or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description complements by specifying multi-field search. No contradictions. The description adds value by clarifying the scope of search beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the action and purpose, then provides usage context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and rich annotations, the description is complete enough. It explains the search behavior and suggests a workflow, while the output schema (present) handles return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'query' parameter, the description adds no additional semantics. The schema already describes it as 'Search query', which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search', the resource 'library', and the fields queried (name, description, topics, tags). It distinguishes from sibling tools like 'library_list' and 'library_discover' by specifying a query-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance to 'propose relevant notebooks for the task and then ask which to use' provides a clear usage context. While it doesn't explicitly state when not to use or list alternatives, the sibling set offers enough distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and idempotentHint=true. Description adds that the session ID remains and the chat history is reset, plus the instruction to ask the user. No contradiction. Provides additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient and front-loaded. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (not detailed), the description covers purpose, usage, and behavioral expectations. Complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for session_id. The tool description does not add extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool resets a session's chat history while keeping the same session ID. The title 'Reset session history' reinforces the purpose. It distinguishes from sibling tools like session_close and session_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Use for a clean slate when the task changes' and instructs to ask the user before resetting. Does not directly contrast with alternatives like session_close, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds a practical behavior detail—'RPC-backed (no browser)'—which helps set execution expectations without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences capture the functionality, the return value purpose, and a relevant execution detail. There is no filler, and the core use case is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complete input schema, annotations, and an output schema. The description additionally explains why an agent would call it and what downstream tools need its result, making it fully self-contained for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both notebook_id and notebook_url. The description adds no extra parameter-level meaning beyond pointing at the source_id output, so a baseline score per schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List the sources of a NotebookLM notebook') and what is returned (IDs and titles). It also ties the output to downstream consumers (read_source and delete_source), making the tool's role unambiguous among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: to get the source_id that read_source and delete_source expect. It does not enumerate when not to use it or mention alternatives, but the primary use case is clear enough for an agent to select it over other source-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, etc.), the description details destructive actions: 'Close all active browser sessions', 'Delete all saved authentication data (cookies, Chrome profile)', and adds post-verification steps. This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullets for use cases and steps, and it front-loads the purpose. It's slightly long due to troubleshooting, but each section adds practical value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive and browser-interactive nature, the description covers when to use, what happens, side effects, verification, and troubleshooting. With an output schema present, return value explanation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, each with descriptions. The tool description adds nothing about parameters, so the baseline of 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Switch to a different Google account or re-authenticate.' It also lists three specific use cases, which distinguishes it from siblings like auth_setup and auth_logout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use this when:' with three concrete scenarios, and provides a post-condition ('use get_health to verify'). However, it doesn't explicitly name alternatives or provide 'when not' guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it specifies that presentations and data_tables return URLs rather than files, and notes that report content is text-based and returned in generation response. Annotations already indicate idempotent and non-destructive, so the description complements them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with bullet points, and front-loads the purpose. Every sentence is informative and earns its place, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, 1 required, enum) and presence of an output schema (though not detailed here), the description covers the main aspects: purpose, types, output formats, and a note about reports. It could include a brief mention of the return structure, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by clarifying that output_path is only applicable for audio, video, and infographic types, which is not evident from the schema alone. It also lists the enum values with output formats, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Download or export generated content from NotebookLM' and enumerates all supported content types with their output formats, distinguishing it from sibling tools like content_generate (creation) and content_list (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to download/export generated content) and lists supported types with output details. It implicitly guides usage by noting that 'report' content is not downloadable here, but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show idempotentHint=true and readOnlyHint=false, consistent with description. The description adds details about auto-switching behavior and how to handle ambiguity, going beyond annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections, but slightly verbose. Every sentence adds value, though some repetition could be trimmed. Still effective and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one idempotent parameter, output schema exists), the description fully covers purpose, usage, and switching logic. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage for the single 'id' parameter, so baseline is 3. Description does not add further semantic details beyond 'set as active default' and 'notebook_id' reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a notebook as active default and ties it to ask_question. It differentiates from sibling tools like library_get and library_list by focusing on state change. However, it does not explicitly contrast with every sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When To Use' and 'Auto-Switching' sections provide explicit context for use, including when to auto-switch and when to ask for clarification. This is strong guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only, not idempotent, and open-world. The description adds context about browser automation, authentication steps, and the fact that source extraction adds time but not quota. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, mixing setup instructions, auth tips, and tool usage into a single block. While structured with headings, it could be more concise by moving general instructions to sibling tool descriptions. Each sentence earns its place, but overall length reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, nested objects, external service interaction), the description covers setup, parameter behavior, auth, and even includes tips. The output schema is separate, so return values need no explanation. Everything needed for correct invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context: explains source_format options in detail, notes time impact and quota exemption, clarifies session_id and notebook_id defaults, and describes browser_options behavior. This significantly enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's role as a conversational research partner for NotebookLM, and the instructions about notebook setup distinguish it from sibling management tools. However, the purpose is mixed with extensive setup guidance, making it slightly less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly details prerequisites (create notebook via add_notebook, list/select), provides auth tips, and directs users to sibling tools when appropriate (e.g., 'Use add_notebook to add it to your library'). It gives clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and side effects (openWorldHint=true). Description adds valuable context: details about waiting for final URL, the name_applied boolean behavior, and the authentication requirement. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with purpose first, then detailed return values, then workflow. It is slightly lengthy but every part earns its place. Could be more concise but still clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (2 parameters, no nesting, output schema exists), the description is fully complete. It explains output fields, provides a usage workflow, and notes authentication prerequisites. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 is appropriate. Description reiterates some parameter info but does not add significant new meaning beyond what the schema already provides for name and show_browser.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Create a brand-new empty notebook directly in NotebookLM' with specific verb and resource. It clearly distinguishes from the sibling add_notebook by noting this tool creates vs registers an existing notebook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool ('no pre-existing URL required') vs the alternative add_notebook. Also includes a typical workflow of sequential steps to follow after creation, guiding the agent on correct invocation order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses persistence to disk, reuse of browser/session, and no HTTP server requirement. Annotations already indicate mutation; description adds file output details. Does not mention overwrite behavior or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-organized paragraphs with clear progression. Front-loaded with core purpose. Could be slightly trimmed but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for an 8-parameter tool with output schema. Covers purpose, output format, usage guidelines, and references external integration guide. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are complete (100% coverage), so baseline is 3. Description adds extra guidance on sleep_between_ms range and vault_dir confinement, improving practical usage understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool runs a list of questions against a notebook and persists answers as .md and .json artifacts. Differentiates from sibling tools by focusing on batch processing and vault ingestion, and mentions reuse of ask_question's browser/session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for one-shot ingestion and reduces round-trips. Gives specific advice on sleep_between_ms for large batches. Could be more explicit about preferring this over single-query tools when persistence is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses how generation actually happens: via real NotebookLM Studio UI buttons or the generic ContentGenerator architecture, with fallback to chat-based generation. It also documents an important error behavior about unrecognized language values. The readOnly=false/idempotent=false annotations align with the described generation behavior, so there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The structure is front-loaded with the core action, then uses bullets for concrete content types, then quickly covers language/video/alternatives and implementation notes. It is longer than average, but every sentence/line contributes decision-relevant information and the formatting makes scanning easy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the six-option enum, optional params, and availability of an output schema, the description covers all invocation-relevant information: which types work, which do not, language and style constraints, and the alternative for unsupported document-style content. Nothing critical is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline of 3 applies; the description meaningfully adds sem_antics by grouping each content_type with real user-visible outcomes, formats, dimensions, and video style options, and by clarifying BCP-47/name usage for language. This goes beyond the schema without repeating it verbatim.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb + resource: 'Generate content from your NotebookLM sources.' It enumerates the six supported content types with concrete output formats and explicitly calls out four unsupported types, making the tool's role and scope immediately distinguishable from siblings like generate_study_aid and generate_mind_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong when/not guidance: supported content types are listed, other types are explicitly marked as not implemented, and document-style content is routed elsewhere. However, the named alternative 'ask_question' does not exactly match the provided sibling 'notebook_ask', and there is no explicit contrast with other generate siblings such as generate_study_aid or generate_mind_map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds useful behavioral context by specifying the metadata fields returned (name, topics, use cases, URL) and that it lists all notebooks, going beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, the first directly stating the action and the second prescribing the usage workflow. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema (which handles return structure), the description covers all necessary context: what the tool does, what metadata is returned, and how to use it in the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the baseline is 4. The description does not need to add parameter details, and schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all library notebooks with metadata like name, topics, use cases, and URL. It distinguishes from sibling tools like library_add or library_remove that are for mutations, and library_search which likely supports filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this to present options and then ask which notebook to use, providing clear context for when to invoke the tool. It does not mention alternatives, but the sibling names imply when not to use it (e.g., for mutations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant value beyond annotations: it explains the irreversible nature, the return format with partial failures, the need for authentication, and the browser visibility option. Annotations already mark destructiveHint=true, so the description aligns and expands with concrete behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: first sentence states the main action, then return format, followed by bullet-pointed use cases and warnings. No redundant or unnecessary sentences. Each part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bulk deletion, partial failures, irreversible), the description covers all essential aspects: what it does, how to use it (via notebook IDs from list), return structure, use cases, warnings, and authentication. The presence of an output schema reduces the need to document return values, but the description still explains the format adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described in the schema. The description restates the notebook_ids parameter's source and format, and clarifies the show_browser default. This adds marginal value over the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete one or more notebooks directly from NotebookLM (UI-level deletion, not just from the local library).' It uses a specific verb and resource, and distinguishes from other deletion operations by specifying the scope. This is a clear and precise purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: bulk-cleanup, freeing quota, and removing outdated notebooks. It warns about irreversibility and suggests user confirmation. It does not explicitly state when not to use or list alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint true, but description adds the important 'ask before closing' behavior, providing extra guidance beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return info not needed. Description covers usage, parameter, and necessary behavioral guardrails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so description adds no new param info beyond what schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Close' and resource 'session by session ID' are clearly stated. It distinguishes from siblings like session_list (listing) and session_reset (resetting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Ask before closing if the user might still need it,' providing clear context for when to use and prompting confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds important context: irreversible action and permanent removal. Also details how to identify sources, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, logically organized: action, identification methods, prerequisite, warning. No wasted words, front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: what it does, how to specify the target, prerequisite action, and consequences. Output schema exists, so return values need no explanation. Complete for a deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds semantics: source_id is unique identifier, source_name supports partial match, and notes optional notebook_url and session_id. This enhances understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action: delete a source from the current NotebookLM notebook. It clearly identifies the resource (source) and the context (notebook), and distinguishes from siblings like source_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong prerequisites by advising use of list_content first to see available sources. Lacks explicit 'when not to use' but the warning and identification method give sufficient guidance for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond the annotations: 'Returns immediately after opening the browser. You have up to 10 minutes to complete the login.' It also discloses that it will skip re-authentication if already authenticated, which is important for idempotency. Annotations do not cover these temporal and conditional behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose is front-loaded and clearly stated. The troubleshooting block adds length but contains actionable and relevant information. While not as compact as ideal, the structure (purpose, usage, troubleshooting) makes it navigable, and most sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authentication tool with open-world interaction and no required params, the description is complete: it covers when to use, what to expect, post-verification, behavior when already authenticated, and a troubleshooting flow for persistent issues. The presence of an output schema means return details need not be described, and the description covers all other critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all parameters, including nested browser_options. The description does not add parameter-specific meaning beyond the schema, so baseline 3 is appropriate. Mentioning 'opens a browser window' loosely relates to show_browser but is not tied to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Google authentication for NotebookLM access - opens a browser window for manual login to your Google account.' It distinguishes itself from alternatives via explicit differentiation: 'Use this for first-time authentication...' and 'For switching accounts or rate-limit workarounds, use re_auth tool instead.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'Use this for first-time authentication or when auto-login credentials are not available.' It also states when not to use it (for switching accounts) and names the alternative 're_auth'. Post-verification guidance is included: 'Use get_health tool afterwards to verify authentication was saved successfully.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description adds critical behavioral context: it requires explicit user confirmation, does not delete the actual notebook, and outlines a step-by-step process. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, numbered steps, and an example. While it is somewhat lengthy, every sentence adds necessary information, and the critical warning is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, presence of output schema, and rich annotations, the description is complete. It explains the tool's danger, confirmation process, what it does not do, and provides an example, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single 'id' parameter with description, achieving 100% coverage. The description does not add additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action: removing a notebook from the library, and distinguishes it from deleting the actual notebook (as noted in the workflow). It clearly differentiates from sibling tools like notebook_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a detailed confirmation workflow, explicitly stating that the tool should only be called after user confirmation. It includes a concrete example and warns against using it without permission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint true and readOnlyHint false (modification). The description adds the critical behavioral trait that the tool must only be called after user confirmation, which is not in annotations. No contradictions. Minor gap: no mention of authorization or side effects beyond metadata updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, numbered pattern, and succinct examples. Every sentence earns its place, providing necessary context without fluff. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown), the description adequately covers usage flow and parameter intent. It lacks details on error handling or prerequisites (e.g., needing a valid notebook ID), but the overall picture is complete for an update tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 8 parameters. The description adds value by grouping the updatable fields and emphasizing the confirmation pattern, making it clear how parameters relate to the workflow. This goes beyond repeating schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update notebook metadata' and lists the specific fields (topics, description, use_cases, tags, url). It differentiates from sibling tools like library_add (create) and library_remove (delete), leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a precise pattern: identify target and fields, propose changes, get explicit confirmation, then call. Examples illustrate the workflow. This is explicit guidance on when and how to use the tool, with no reliance on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds that it lists 'active' sessions with specific stats, which is helpful beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences only: first states purpose and output, second provides usage guideline. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no required parameters and an output schema exists. Description covers the return fields, making it complete for an agent to understand and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters, so description doesn't need to explain them. However, it adds value by describing the output fields (age, message count, last activity), which compensates for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'list all active sessions with stats' and specifies the three stats returned. Distinguishes from sibling tools like session_close and session_reset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to continue the most relevant session instead of starting from scratch,' providing a clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint and idempotentHint, and the description adds meaningful behavior beyond those: default pagination to 20,000 characters, totalChars/nextCursor/continue semantics, the ability to pass cursor or disable pagination, the difference between text and HTML renditions, and the fact that this is RPC-backed without a browser. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: purpose first, then use cases, then pagination and rendering behavior. Each sentence contributes meaningful guidance without repetition or filler, and the key default behavior is stated early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with an output schema and rich annotations, the description covers all critical aspects: what the tool reads, why it is valuable, how to identify the source, page behavior, formatting choices, and performance considerations for large documents. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema parameters already carry detailed descriptions. The description adds further value by explaining the pagination model — first page of 20,000 characters, totalChars, nextCursor, the 'continue' instruction, and that cuts pull back to line breaks — which makes the parameter meanings more actionable than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb-resource pair: 'Read a source’s full indexed content' — the exact text NotebookLM reasons over. It clearly distinguishes this from the web UI's fragmented display and from sibling tools like source_add or source_delete by naming the read operation on existing sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage contexts: quoting verbatim, verifying what was ingested, and feeding raw material to another tool. It references list_sources for finding source_id, providing clear selection guidance, though it does not state when to prefer sibling tools such as source_list or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description details specific behaviors: closes browser sessions, deletes cookies/Chrome profile, preserves notebook data. Adds context beyond annotations (destructiveHint, idempotentHint) by explaining what is destroyed and what is kept.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points, numbered steps, and clear sections. Slightly wordy but all information is relevant and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description fully covers behavior, side effects, and post-conditions. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 is appropriate. The description clarifies the tool's operation without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'De-authenticate (logout)' and lists specific use cases (security, shutdown, clearing auth). It distinguishes from siblings like auth_setup and auth_switch by focusing on logout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (security, shutdown, clearing auth) and what it does not do (preserve notebook data). Also gives guidance on next steps: re-authentication via setup_auth or re_auth, and verification with get_health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark destructiveHint=true and readOnlyHint=false; the description goes far beyond by detailing deep mode, preview-before-deletion flow, cross-platform support, library preservation, and the critical warning about closing browsers. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with a warning, categorized list, and workflow. It is front-loaded with the purpose and critical warning. While slightly verbose, every sentence adds necessary information for a destructive tool, justifying its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all aspects: purpose, behavior, parameters, use cases, prerequisites (close browsers), workflow, and library preservation. Given complexity and existing output schema, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by explaining the two-step workflow for 'confirm' (preview then delete) and clarifying 'preserve_library' keeps library.json while deleting everything else. It also includes a workflow example, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a deep cleanup of NotebookLM MCP data files across 8 categories, with specific verb 'scans' and 'shows preview before deletion'. It distinguishes itself from sibling tools (auth, content, library tools) by its destructive cleanup nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases (clean reinstall, troubleshooting auth issues, removing all traces) and provides a recommended workflow with steps. It also warns about closing Chrome and explains when to use confirm=true/false and preserve_library. No alternative tools exist among siblings, so guidance is complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, which the description reinforces. Additionally, it explains what the tool checks (auth state, sessions, configuration) and suggests a recovery path for failures, adding context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences followed by a conditional note. Every sentence is purposeful and front-loaded with the primary use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description covers purpose, usage context, and troubleshooting guidance. It is fully complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters; the input schema is empty. With 100% schema coverage, no additional parameter info is needed. Baseline of 4 for zero parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves server health including authentication state, active sessions, and configuration. The verb 'Get' and the specific resources distinguish it from sibling tools like 'session_list' or 'auth_setup'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'verify the server is ready before starting research workflows.' It also provides an alternative recovery procedure if authenticated=false and having persistent issues, guiding the agent to use other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the complete workflow: it generates metadata from a URL and returns it for review, without persisting immediately. This aligns with annotations (readOnlyHint=false, idempotentHint=false) as the tool may trigger a side effect (API call) but does not save to library. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, emojis, and clear formatting. It is front-loaded with the most critical information (purpose and when to use) and every sentence contributes value. Despite length, it remains efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description fully covers the workflow, example, fallback, and even instructions for obtaining the URL. The output schema exists, and the description explains the return values (name, description, tags). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter 'url' described as 'The NotebookLM notebook URL'. The description adds significant value by providing detailed instructions on how to obtain the URL (share link steps), which goes beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: automatically generate notebook metadata via NotebookLM. It uses a specific verb ('auto-discover') and resource ('notebook metadata'), and distinguishes from siblings like 'library_add' by positioning it as the recommended automatic setup. The example reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides 'When to Use' scenarios and a 'Fallback' instruction to use 'add_notebook' if auto-discovery fails. It outlines a clear workflow and contrasts with manual entry, giving the AI clear guidance on when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/roomi-fields/notebooklm-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server