NotebookLM MCP Server (Security Hardened)

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2026.2.3
Disambiguation3/5
The tool set has clear distinct purposes for core operations like notebook management (add_notebook, create_notebook, list_notebooks) and media generation (generate_audio_overview, generate_video_overview), but there is significant overlap between tools like ask_question, get_notebook_chat_history, and get_query_history, which all involve querying or retrieving chat data, potentially causing confusion. Additionally, cleanup_data and re_auth both handle authentication/session cleanup with overlapping functions.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as add_notebook, create_notebook, list_notebooks, generate_audio_overview, get_health, and sync_library. All tools use snake_case without deviation, making them predictable and easy to parse for agents.
Tool Count2/5
With 31 tools, the count is excessive for the server's purpose of managing NotebookLM notebooks and media. Many tools could be consolidated (e.g., multiple chat history tools, overlapping cleanup/auth tools), leading to a bloated interface that may overwhelm agents and increase misselection risk.
Completeness4/5
The tool surface provides comprehensive coverage for NotebookLM operations, including CRUD for notebooks and sources, media generation (audio, video, data tables), session management, authentication, and library syncing. Minor gaps exist, such as no direct tool for editing source content or managing sharing settings, but agents can work around these with existing tools.
Average 4.3/5 across 31 of 31 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on June 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds minimal context beyond this, only specifying that it retrieves 'detailed information'. It doesn't disclose additional aspects like rate limits, authentication needs, or what 'detailed information' entails, but doesn't contradict annotations either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get detailed information about a specific notebook by ID'). There's no wasted language or redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks details on return format, error handling, or integration with sibling tools. For a read-only retrieval tool, this is acceptable but leaves room for more contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter fully documented. The description adds no additional meaning beyond the schema, merely restating that it's 'by ID'. This meets the baseline of 3 for high schema coverage, but doesn't enhance parameter understanding with examples or contextual details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'notebook' with specificity 'detailed information about a specific notebook by ID'. It distinguishes from siblings like 'list_notebooks' by focusing on single-item retrieval rather than listing. However, it doesn't explicitly contrast with 'search_notebooks' or 'select_notebook', which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 doesn't mention when to choose 'get_notebook' over 'list_notebooks' for browsing, 'search_notebooks' for filtering, or 'select_notebook' for selection contexts. There's no indication of prerequisites or exclusions, leaving usage entirely implicit.
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 cover key behavioral traits (read-only, non-destructive, idempotent, closed-world), so the bar is lower. The description adds some context about the search scope (name, description, topics, tags) and a suggested workflow, but it doesn't disclose additional behavioral aspects like rate limits, auth needs, or result format. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that efficiently convey the search functionality and usage suggestion. It's front-loaded with the core purpose, though the second sentence could be more tightly integrated. Overall, it avoids waste but isn't perfectly structured for maximum clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), rich annotations, and no output schema, the description is adequate but incomplete. It covers the search scope and a usage hint, but lacks details on result format, pagination, or error handling, which could aid the agent in interpreting outcomes. It meets minimum viability but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'query' parameter fully documented in the schema. The description adds minimal semantic value by listing searchable fields (name, description, topics, tags), but this doesn't significantly enhance understanding beyond the schema's 'Search query' description. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching a library by query across multiple fields (name, description, topics, tags), which is specific and distinguishes it from siblings like 'list_notebooks' or 'get_notebook'. However, it doesn't explicitly differentiate from 'list_notebooks' in terms of filtering scope or output format, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating 'Use to propose relevant notebooks for the task and then ask which to use', which suggests a workflow context. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to 'list_notebooks' or 'get_notebook'), and no exclusions or prerequisites are mentioned, making it only moderately helpful.
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 readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering basic safety and idempotency. The description adds valuable context beyond this: it specifies permission requirements ('PERMISSION REQUIRED'), outlines a multi-step interactive process, and includes implementation details like how to obtain a NotebookLM share link. This enriches behavioral understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and poorly structured for a tool definition, including extensive conversational workflows, rules, examples, and external instructions (e.g., 'How to Get a NotebookLM Share Link'). While some content is useful, much of it (like step-by-step login instructions) is extraneous and not front-loaded, reducing efficiency for an AI agent parsing the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given 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, no output schema) and rich annotations, the description is mostly complete. It covers usage context, behavioral traits, and workflow integration thoroughly. However, it lacks details on error handling or response format, which could be helpful since there's no output schema, slightly limiting completeness for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear descriptions for all 7 parameters. The description adds minimal parameter semantics beyond the schema, mainly implying that parameters like 'url', 'name', 'description', 'topics', and 'use_cases' are collected through the conversational workflow. However, it doesn't explain parameter relationships or usage nuances, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: adding a notebook to a library when the user explicitly requests it. It specifies the verb 'add' and resource 'notebook', distinguishing it from siblings like 'create_notebook' or 'update_notebook' by focusing on user-permission-driven addition. However, it doesn't explicitly differentiate from 'batch_create_notebooks' or 'sync_library', which slightly limits sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit and detailed guidelines on when to use this tool, including a mandatory conversation workflow with six steps, rules (e.g., 'Do not add without user permission'), and an example. It clearly defines prerequisites (user permission, metadata collection) and alternatives (implied by the workflow's questioning phase), leaving no ambiguity about usage context.
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 readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds valuable context beyond this: it discloses that the tool uses browser automation (not API), mentions auth requirements and setup steps, and provides debugging options (e.g., 'show_browser' and 'browser_options'). This enriches the behavioral understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and poorly structured, with markdown formatting, multiple sections, and tips that could be condensed. It includes redundant information (e.g., repeating 'NO API KEY REQUIRED') and workflow details that might be better suited for general documentation. Sentences like 'Tip: Tell the user you can manage NotebookLM library' are extraneous and reduce focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects, no output schema) and rich annotations, the description is mostly complete. It covers usage context, prerequisites, and behavioral aspects, though it lacks details on return values or error handling. With annotations providing safety and idempotency hints, and schema covering parameters well, the description adds sufficient contextual value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 thoroughly. The description does not add significant meaning beyond the schema, as it focuses on usage workflow and behavioral context rather than parameter details. For example, it doesn't explain how 'question' interacts with NotebookLM or clarify parameter interdependencies beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask NotebookLM' in the title and 'This tool uses browser automation' in the description, indicating it submits queries to NotebookLM. However, it doesn't explicitly distinguish this from sibling tools like 'search_notebooks' or 'get_notebook_chat_history', which might have overlapping query functionality. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does 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, including prerequisites (e.g., 'No Active Notebook' section with steps like using 'add_notebook' and 'select_notebook'), alternatives (e.g., using 'list_notebooks' to see available sources), and context-specific tips (e.g., auth setup with 'notebooklm.auth-setup' and 'get_health'). It clearly outlines the workflow and when this tool fits in.
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 provide hints (e.g., readOnlyHint=false, destructiveHint=false), but the description adds valuable behavioral context beyond this: it discloses that the tool 'Opens the Studio panel in NotebookLM', 'Generation typically takes 1-3 minutes', and 'Returns immediately with status (check with get_data_table)'. This includes UI effects, timing, and output behavior, which are not covered by annotations. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections ('What This Tool Does', 'Requirements', 'Example'), front-loading key actions. It is appropriately sized, but includes some redundancy (e.g., repeating 'Generate' in multiple points) and could be slightly more streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involves UI interaction, async processing, and authentication) and lack of output schema, the description is mostly complete: it covers purpose, requirements, behavioral traits, and usage context. However, it does not detail error conditions or what 'status' entails, leaving minor gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (notebook_id and notebook_url) with descriptions. The description does not add meaning beyond the schema, such as explaining parameter interactions or usage nuances. With high schema coverage, the baseline score of 3 is appropriate as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'generates a structured tabular extraction from notebook content' and 'tables organize key information from sources into rows and columns', specifying both the verb (generate) and resource (data table from notebook sources). It distinguishes from siblings like 'get_data_table' (which checks status) and 'add_source' (which adds content rather than extracting it).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool: 'Notebook must have at least one source' and 'Authentication required (run setup_auth first)'. It also implies an alternative by noting 'Returns immediately with status (check with get_data_table)', but does not explicitly state when not to use it or compare to other extraction tools like 'generate_audio_overview'.
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 readOnlyHint=false (mutation), destructiveHint=false (non-destructive), and idempotentHint=true (safe to retry). The description adds valuable behavioral context beyond annotations by specifying a confirmation workflow ('After explicit confirmation, call this tool'), which is a critical safety measure for mutations. It doesn't contradict annotations, and the added context about user confirmation enhances transparency for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear pattern, examples, and a tip, all in a concise format. Each sentence serves a purpose: the first states the goal, the pattern outlines the workflow, examples illustrate usage, and the tip adds efficiency. It's front-loaded with key information, though slightly longer than minimal, it avoids waste and is easy to follow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, mutation operation) and rich annotations (covering safety and idempotency), the description is largely complete. It adds crucial usage workflow and examples, compensating for the lack of output schema. However, it could mention error handling or response format, which is a minor gap in an otherwise comprehensive description for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 8 parameters thoroughly. The description lists fields (topics, description, use_cases, tags, url) in step 1, but this merely repeats what's in the schema without adding deeper meaning or usage nuances. With high schema coverage, the baseline is 3, as the description doesn't significantly enhance parameter understanding beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as updating notebook metadata based on user intent, specifying the verb 'update' and resource 'notebook metadata'. It distinguishes from siblings like 'create_notebook' or 'remove_notebook' by focusing on updates rather than creation or deletion. However, it doesn't explicitly contrast with tools like 'get_notebook' or 'list_notebooks', which is why it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines with a three-step pattern: identify target and fields, propose change to user, and call after confirmation. It includes examples illustrating when to use the tool and mentions updating multiple fields if requested. This gives clear context on when and how to invoke the tool, with no misleading information.
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 non-read-only, non-destructive, non-idempotent, and open-world hints. The description adds valuable behavioral context beyond annotations: it explains progress reporting, error handling options (stop_on_error), auto-addition to library, delays for rate limiting, and return summary structure. This enriches understanding without contradicting 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (What This Tool Does, Example Usage, Limits, Returns), each sentence adds value (e.g., explaining batch limits, error handling, returns), and it avoids redundancy. It is appropriately sized and front-loaded with key information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch creation with multiple parameters) and lack of output schema, the description does a good job covering behavior, limits, and return values. However, it could improve by explicitly mentioning authentication needs or linking to sibling tools for context, slightly reducing completeness for a mutation tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 thoroughly. The description adds minimal parameter semantics beyond the schema, such as implying 'notebooks' array structure through the example and mentioning 'stop_on_error' behavior. This meets the baseline for high schema coverage but doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'creates multiple NotebookLM notebooks in one operation,' clearly specifying the verb (create) and resource (notebooks). It distinguishes from sibling tools like 'create_notebook' by emphasizing batch capability and up to 10 notebooks, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (creating multiple notebooks efficiently) and mentions limits like maximum 10 notebooks, which implies when not to use it for larger batches. However, it does not explicitly name alternatives (e.g., 'create_notebook' for single creation) or detail prerequisites, keeping it from a perfect score.
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 valuable behavioral context beyond annotations by warning about potential user impact ('Ask before closing if the user might still need it'). Annotations already indicate destructiveHint=true and idempotentHint=true, but the description provides practical usage advice that enhances understanding of the tool's consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two clear sentences that each serve distinct purposes: the first states the core functionality, the second provides crucial usage guidance. There's no wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with good annotation coverage (destructiveHint, idempotentHint) but no output schema, the description provides adequate context about the action and important usage considerations. The main gap is lack of information about what 'closing' actually means behaviorally or what happens after closure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents the single 'session_id' parameter. The description doesn't add any additional parameter information beyond what's in the schema, so it meets the baseline expectation without providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Close') and target resource ('a specific session by session ID'), distinguishing it from sibling tools like 'list_sessions' or 'reset_session'. It provides a precise verb+resource combination that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance with 'Ask before closing if the user might still need it', which helps determine when to use this tool. However, it doesn't explicitly mention alternatives like 'reset_session' or specify when-not-to-use scenarios, preventing a perfect score.
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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating safe, repeatable operations. The description adds valuable behavioral context beyond this: it specifies the output location (default path with timestamp) and the prerequisite status check, which aren't covered by annotations. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Description, Requirements, Output, Example), front-loaded with the core purpose. Each sentence serves a specific purpose—stating the action, outlining prerequisites, specifying output behavior, and providing an example—with no wasted words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (download operation with prerequisites), rich annotations (covering safety and idempotency), and full schema coverage, the description is largely complete. It adds useful context like status requirements and default output path. However, without an output schema, it could briefly mention the return type (e.g., success confirmation or error), though the annotations help mitigate this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters (notebook_id, notebook_url, output_path). The description adds minimal parameter semantics: it mentions 'output_path' in the 'Output' section and includes it in the example, but doesn't provide additional meaning beyond what the schema already states. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a generated audio overview file, specifying the resource (audio overview file) and action (download). It distinguishes from siblings like 'generate_audio_overview' (which creates the audio) and 'get_audio_status' (which checks status), but doesn't explicitly contrast with all possible alternatives. The purpose is specific but could be slightly more differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines in the 'Requirements' section: audio must be in 'ready' status, and it instructs to use 'get_audio_status' to check before downloading. This clearly states when to use (after status check) and references a specific sibling tool as a prerequisite, offering strong 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 adds valuable behavioral context beyond annotations: it specifies that generation 'takes 2-5 minutes typically' and 'returns immediately with status (check with get_audio_status)', which are not covered by annotations (e.g., readOnlyHint=false only indicates it's not read-only). It does not contradict annotations, and while it could mention more about error handling or permissions, it provides useful operational 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections ('What This Tool Does', 'Requirements', 'Example'), front-loaded with key information, and every sentence adds value without redundancy. It efficiently covers purpose, behavior, prerequisites, and an example in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (asynchronous generation with status checks), no output schema, and rich annotations, the description is mostly complete: it explains the process, timing, and follow-up action. However, it could benefit from mentioning the output format or error cases, but it adequately covers core usage for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (notebook_id and notebook_url) with descriptions. The description does not add meaning beyond the schema, such as explaining parameter interactions or usage nuances, but the baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'triggers NotebookLM's audio overview generation' for a notebook, specifying it creates '~5-15 minute podcast-style summaries'. This is a specific verb (generate) + resource (audio overview) + distinguishing detail (podcast-style for notebooks), and it differentiates from siblings like 'generate_video_overview' by focusing on audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for generating audio overviews of notebooks, with requirements like 'notebook must have at least one source' and notes that 'audio generation may not be available on all notebooks'. However, it does not explicitly state when not to use it or name alternatives (e.g., 'generate_video_overview' for video summaries), which prevents a score of 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 valuable behavioral context beyond annotations: it details the return values (status, progress, duration) and their semantics (e.g., progress only applies if generating). Annotations already cover read-only, idempotent, and non-destructive traits, so the description appropriately focuses on output behavior, though it could mention rate limits or auth needs for a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by organized sections for returns and an example. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (status checking with two parameters), rich annotations (e.g., readOnlyHint), and no output schema, the description provides good completeness by explaining return values and including an example. It could be a 5 if it explicitly linked to sibling tools like 'generate_audio_overview' for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters (notebook_id and notebook_url). The description does not add any parameter-specific information beyond what's in the schema, such as clarifying the relationship between the two parameters. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Check') and resource ('audio overview generation status for a notebook'), distinguishing it from siblings like 'generate_audio_overview' (which initiates generation) and 'download_audio' (which retrieves audio). It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it checks status for audio generation, suggesting it should be used after initiating generation (e.g., with 'generate_audio_overview'). However, it does not explicitly state when not to use it or name alternatives, such as noting that 'get_video_status' is for video instead of audio, which would have made it 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds value by detailing the return structure (array with id, title, type, status) and linking 'id' to 'remove_source', which is useful context beyond annotations. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, returns, example) and uses bullet points efficiently. It is appropriately sized, but the example section could be slightly condensed. Most sentences earn their place, with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation), rich annotations (covering safety and behavior), and 100% schema coverage, the description is complete. It adds necessary context like return structure and parameter examples, compensating for the lack of an output schema. No significant gaps remain for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents parameters. The description adds minimal semantics by providing example usage and noting that 'notebook_url' overrides 'notebook_id', but this is redundant with the schema's description. Baseline 3 is appropriate as the schema handles most documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all sources') and resource ('in a NotebookLM notebook'), distinguishing it from siblings like 'list_notebooks' (which lists notebooks) and 'add_source' (which adds sources). It precisely defines the scope and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the context ('in a NotebookLM notebook') and provides examples for input parameters, but it does not explicitly state when to use this tool versus alternatives like 'get_notebook' or 'search_notebooks'. The guidance is clear but lacks explicit exclusions or comparisons.
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 provide hints (readOnlyHint: false, destructiveHint: true, idempotentHint: true, openWorldHint: true), but the description adds valuable context beyond this. It specifies that source IDs come from 'list_sources' and includes an example with parameter details, enhancing understanding of the tool's behavior and prerequisites without contradicting 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a 'Usage' section for guidelines, and an 'Example' section with JSON. It is front-loaded and every sentence earns its place, avoiding redundancy and maintaining efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with 3 parameters), annotations cover key behavioral traits, and schema coverage is high. The description adds usage guidelines and an example, making it fairly complete. However, without an output schema, it doesn't describe return values, leaving a minor gap in full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 (notebook_id, notebook_url, source_id). The description adds minimal semantics by mentioning 'source ID from list_sources' in the usage section and showing an example, but this doesn't significantly enhance the schema's information. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Remove a source from a NotebookLM notebook,' specifying the verb ('Remove') and resource ('source from a NotebookLM notebook'). It distinguishes from siblings like 'add_source' or 'remove_notebook' by focusing on sources within notebooks, though it doesn't explicitly compare to them in the description text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines in a 'Usage' section, stating 'First call list_sources to get source IDs' and 'Then call remove_source with the source ID.' This clearly indicates when to use this tool (after obtaining IDs from list_sources) and implies an alternative (list_sources) for prerequisite steps.
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 valuable behavioral context beyond annotations: it discloses the typical generation time (3-10 minutes), the immediate return with status, and authentication requirements. While annotations cover basic hints (e.g., not read-only, open-world), the description enriches this with practical details, though it could mention potential side effects like resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (What This Tool Does, Visual Styles, Formats, Requirements, Example) and uses bullet points efficiently. It's appropriately sized, though some sections like the style list are lengthy but necessary. Every sentence adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, rich annotations), the description is mostly complete. It covers purpose, usage, parameters, and behavioral traits. However, it lacks details on error handling or output format, which could be helpful for an agent. The absence of an output schema makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents all parameters. The description adds minimal extra meaning (e.g., listing visual styles and formats with brief explanations), but doesn't provide significant additional semantics beyond what's in the schema. This meets 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generate an AI-powered Video Overview for a notebook') and distinguishes it from siblings like generate_audio_overview and get_video_status. It specifies the exact resource (notebook) and outcome (visual video summary), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Generate an AI-powered Video Overview for a notebook') and provides clear alternatives (e.g., 'check with get_video_status' for status updates). It also lists prerequisites ('Notebook must have at least one source', 'Authentication required'), guiding proper usage.
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=true, idempotentHint=true, and destructiveHint=false, covering basic safety. The description adds valuable behavioral context beyond annotations: the deep_check mode's performance impact ('slower (~5s)'), reliability benefits ('more reliable'), and specific return field ('chat_ui_accessible: true/false'). It also mentions authentication troubleshooting workflows, though it doesn't detail rate limits or exact error 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose and usage. The deep_check section and troubleshooting advice are relevant but slightly verbose. Most sentences earn their place by providing actionable guidance, though the troubleshooting paragraph could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (health check with optional deep verification), rich annotations (readOnly, idempotent, non-destructive), and 100% schema coverage, the description is largely complete. It explains the tool's role in workflows, deep check behavior, and troubleshooting steps. The main gap is lack of output schema, but the description partially compensates by mentioning specific return fields like chat_ui_accessible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema. The description adds some context for deep_check ('actually navigates to NotebookLM and verifies the chat UI loads') and notebook_id ('Defaults to active notebook or first available'), but doesn't provide significant additional semantic meaning beyond what's already in the schema descriptions. This meets 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get server health status') and resources ('authentication state, active sessions, and configuration'), distinguishing it from sibling tools like get_audio_status or get_video_status. It explicitly identifies what health information is returned, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does 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 ('to verify the server is ready before starting research workflows') and when to use alternatives (e.g., cleanup_data + setup_auth for authentication issues). It also distinguishes between normal and deep check modes, offering clear usage contexts.
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 key behavioral hints (readOnlyHint: true, idempotentHint: true, destructiveHint: false), but the description adds valuable context by detailing the return values (status, progress, duration) and their conditions, which are not covered by annotations. This enhances transparency without contradicting 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by clear sections for returns and an example. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations (e.g., readOnlyHint, idempotentHint), and no output schema, the description is complete. It explains the tool's purpose, return values, and provides an example, compensating for the lack of output schema and ensuring the agent has all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents the two parameters (notebook_id and notebook_url). The description does not add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for adequate but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('Video Overview generation status for a notebook'), distinguishing it from siblings like 'generate_video_overview' (which creates videos) and 'get_audio_status' (which checks audio status). It precisely defines what status is being checked.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it's for checking status after video generation, but it does not explicitly state when to use this tool versus alternatives like 'get_audio_status' or provide exclusions. It offers clear guidance on the tool's role without naming specific alternatives or when-not scenarios.
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 valuable behavioral context beyond annotations: it explains the sync process (e.g., 'Navigates to NotebookLM', 'Compares with local library'), details output structure, and mentions optional auto-removal of stale entries. Annotations cover safety (non-destructive, idempotent) and openness, but the description enriches this with operational specifics without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (What This Tool Does, When To Use, Output, Example Usage) and uses bullet points for readability. It's appropriately sized but could be slightly more concise by integrating the example into the parameter section, as some redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema), the description is mostly complete: it explains purpose, usage, process, and output details. However, it lacks explicit mention of authentication needs or rate limits, which could be relevant given the 'navigates to NotebookLM' action, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds minimal param semantics through example usage showing 'auto_fix' values, but doesn't explain 'show_browser' or provide additional meaning beyond the schema's descriptions. This meets 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('sync', 'navigates', 'extracts', 'compares', 'detects', 'identifies') and resources ('local library', 'NotebookLM notebooks'). It distinguishes from siblings by focusing on synchronization rather than creation, listing, or removal operations, making its unique role evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When To Use' section explicitly lists four scenarios for using this tool (e.g., 'Library seems out of sync', 'After deleting notebooks'), providing clear context. It implicitly distinguishes from alternatives by focusing on sync tasks rather than direct notebook management, though it doesn't name specific sibling tools as 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 provide hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), but the description adds valuable context by listing source types (url, text, file) with examples, clarifying what can be added. It does not contradict annotations—'Add' aligns with non-readOnly and non-destructive hints—and supplements with practical behavioral details not covered by 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a structured list of source types and a clear JSON example. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to scan for key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, nested objects, no output schema) and rich annotations, the description is largely complete. It covers purpose, source types, and usage example, but lacks details on error handling, response format, or prerequisites (e.g., authentication), which could enhance completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with parameters like 'notebook_id' and 'source.type' well-described in the schema. The description compensates by detailing source types (url, text, file) and providing an example that illustrates parameter usage and structure, adding meaning beyond the schema's enum and object definitions, though it doesn't cover all parameters exhaustively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add a source') and resource ('to an existing NotebookLM notebook'), distinguishing it from sibling tools like 'add_notebook' or 'create_notebook' which create notebooks rather than adding sources to existing ones. The verb 'Add' is precise and the scope 'existing NotebookLM notebook' sets clear boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'to an existing NotebookLM notebook,' which suggests it should not be used for creating new notebooks (use 'add_notebook' or 'create_notebook' instead). However, it lacks explicit when-not-to-use guidance or named alternatives for source management (e.g., vs. 'remove_source' or 'list_sources'), leaving some ambiguity in sibling differentiation.
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 indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description adds valuable behavioral context beyond annotations: it discloses authentication requirements, rate limits (NotebookLM Free Tier limits), default privacy settings, processing time for large files, and that it returns a notebook URL. This significantly enhances the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (What This Tool Does, Supported Source Types, Example Usage, Limits, Notes) and uses bullet points efficiently. However, it includes extensive example JSON blocks that could be considered verbose, though they are informative. Overall, it's front-loaded 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema) and rich annotations, the description is highly complete. It covers purpose, usage, behavioral traits, limits, prerequisites, and provides examples, compensating well for the lack of output schema. No significant gaps remain for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all 7 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, mainly through the example usage which illustrates practical combinations. It does not explain parameter interactions or constraints not in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool creates a new NotebookLM notebook with sources programmatically, clearly distinguishing it from siblings like 'add_notebook' (likely adds to existing) or 'batch_create_notebooks' (multiple). It specifies the verb 'creates' and resource 'notebook' with source uploading functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (creating new notebooks with sources) and mentions authentication prerequisites. However, it does not explicitly contrast with alternatives like 'batch_create_notebooks' or 'update_notebook', leaving some ambiguity about sibling differentiation.
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 key behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false), covering safety and idempotency. The description adds valuable context beyond this: it specifies the return format ('query entries with question, answer, notebook, session, and timing info') and implies search functionality ('Search through question and answer content'), which helps the agent understand output structure and capabilities. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a bulleted list for usage guidelines and a final sentence on return values. Every sentence earns its place by adding clarity or utility without redundancy. It is appropriately sized for a tool with multiple parameters and clear use cases, avoiding unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema), the description is largely complete: it explains purpose, usage, and return format. However, it lacks details on pagination or ordering of results, which could be relevant for the 'limit' parameter. Annotations cover safety aspects, but without an output schema, the description could benefit from more specifics on result structure (e.g., pagination behavior).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters well-documented in the input schema (e.g., 'session_id' for filtering by session, 'search' for pattern matching). The description does not add significant parameter semantics beyond the schema, as it only mentions 'Search through question and answer content' which aligns with the 'search' parameter. Given the high schema coverage, a baseline score of 3 is appropriate, as the description provides minimal extra parameter insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve past NotebookLM queries and answers for reviewing research sessions.' It specifies the verb ('Retrieve'), resource ('past NotebookLM queries and answers'), and context ('reviewing research sessions'), distinguishing it from siblings like 'get_notebook_chat_history' or 'list_sessions' by focusing on query-level history rather than broader chat or session listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidelines with a bulleted list: 'Use this tool to: - Review past research conversations - Find specific information from previous queries - Track which notebooks and sessions you've used - Search through question and answer content.' This clearly indicates when to use this tool versus alternatives like 'get_notebook_chat_history' (for chat-level history) or 'list_sessions' (for session metadata), offering practical scenarios without misleading exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it details the three-step process (closing sessions, deleting auth data, opening browser), mentions post-completion verification with 'get_health', and provides troubleshooting steps. While annotations already indicate destructiveHint=true and readOnlyHint=false, the description enriches this with specific destructive actions and operational consequences, though it doesn't fully cover all behavioral aspects like error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage cases, process steps, troubleshooting) and uses bullet points for readability. However, the troubleshooting section is quite detailed and could be considered slightly verbose, though all content is relevant and earns its place by providing actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive authentication reset with nested parameters) and lack of output schema, the description is highly complete. It covers purpose, usage scenarios, step-by-step behavior, post-action verification, and extensive troubleshooting, compensating for the absence of structured output documentation and providing all necessary context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents the two parameters and their nested properties. The description adds no additional parameter semantics, focusing instead on usage and behavior. This meets the baseline score of 3, as the schema carries the parameter documentation burden effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('switch to a different Google account or re-authenticate') and distinguishes it from siblings by focusing exclusively on authentication management. It explicitly names the target resource (Google account) and the action (re-authenticate), making it distinct from tools like 'setup_auth' or 'get_health'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, bulleted guidance on when to use this tool (rate limit reached, switching accounts, broken authentication) and includes a troubleshooting section with step-by-step alternatives for persistent issues. It also references sibling tools like 'cleanup_data' and 'get_health' for related actions, offering comprehensive usage context.
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 behavioral context beyond annotations. While annotations indicate destructiveHint=true and idempotentHint=true, the description elaborates on the confirmation workflow, clarifies that removal is from the library (not deletion of the actual NotebookLM notebook), and specifies the dangerous nature requiring explicit user permission. This provides crucial implementation guidance not captured in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (warning, workflow steps, example) and every sentence serves a purpose. While slightly longer than minimal, the content is front-loaded with the critical warning and workflow, and the example provides valuable clarification without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with comprehensive annotations and full schema coverage, the description provides excellent contextual completeness. It covers the dangerous nature, confirmation requirements, workflow details, and clarifies what 'remove' actually means (library removal vs. notebook deletion). The lack of output schema is compensated by the clear behavioral description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (the single 'id' parameter is fully documented in the schema), the description adds no additional parameter information. It doesn't explain what notebook IDs look like, how to obtain them, or provide examples. The baseline score of 3 reflects adequate coverage through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a notebook from the user's library with 'Remove Notebook' as the title and 'remove_notebook' as the name. It specifies the action (remove) and resource (notebook), but doesn't explicitly differentiate from sibling 'remove_source' which removes a different resource type. The purpose is clear but sibling differentiation is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, step-by-step guidelines on when to use this tool: only after user confirmation following a specific workflow. It states 'Never remove without permission or based on assumptions' and gives a concrete example with dialogue flow. This clearly defines the required context and preconditions for invocation.
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 and idempotentHint=true, but the description adds valuable context: it clarifies that resetting only affects chat history (not the session ID) and emphasizes user confirmation. It doesn't contradict annotations (destructive=true aligns with 'reset'), though it could mention rate limits or auth needs for a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first clause, followed by usage guidance and a critical behavioral note. Every sentence earns its place with no wasted words, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with one parameter), annotations cover key behavioral traits, and the description adds practical context like user confirmation. However, without an output schema, it could briefly mention what happens post-reset (e.g., confirmation message) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'session_id' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, so it meets the baseline of 3 without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Reset a session's chat history') and resource ('session'), with explicit distinction from siblings by noting it 'keep[s] same session ID' (unlike close_session which likely ends the session). It avoids tautology by explaining what resetting entails beyond just the name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use ('for a clean slate when the task changes') and includes a crucial behavioral directive ('ask the user before resetting'), which distinguishes it from alternatives like close_session or other session management tools. This covers both context and exclusions effectively.
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 valuable behavioral context beyond annotations: it discloses that the tool 'returns immediately after opening the browser' (asynchronous behavior), gives a time constraint ('up to 10 minutes to complete the login'), and provides troubleshooting steps for persistent auth issues. While annotations cover basic hints (readOnlyHint=false, etc.), the description adds practical implementation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: main purpose, usage instructions, and troubleshooting. While slightly longer than minimal, every sentence serves a purpose. The troubleshooting section could be considered somewhat verbose but provides valuable operational guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's authentication complexity and lack of output schema, the description provides comprehensive context: it explains the authentication flow, success verification method ('get_health'), time constraints, troubleshooting procedures, and differentiation from sibling tools. This adequately compensates for the absence of output schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully documents both parameters and their properties. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. The description focuses on tool usage rather than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Google authentication for NotebookLM access - opens a browser window for manual login to your Google account.' It specifies the exact action (opens browser for manual login) and resource (Google account for NotebookLM), and distinguishes it from sibling 're_auth' tool for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does 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 ('first-time authentication or when auto-login credentials are not available') and when to use alternatives ('For switching accounts or rate-limit workarounds, use re_auth tool instead'). It also instructs to use 'get_health' afterwards to verify success.
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=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable context beyond this: it specifies the tool navigates to a Studio panel, extracts structured JSON, and returns specific table properties (headers, rows, totals). It also mentions error behavior when the table isn't ready. No contradictions 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ('What This Tool Does', 'Returns', 'Requirements', 'Example'), each sentence adds value, and it's front-loaded with the core purpose. No redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with rich annotations and no output schema, the description is complete: it explains the action, prerequisites, return structure, and error conditions. It compensates for the lack of output schema by detailing the return format, making it sufficient for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (notebook_id and notebook_url) fully documented in the schema. The description provides an example showing notebook_id usage but adds no new semantic details about parameters beyond what the schema already states. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Extract'), target resource ('Data Table content from a notebook'), and mechanism ('navigates to notebook's Studio panel, extracts table data as structured JSON'). It distinguishes from sibling tools like 'generate_data_table' by focusing on extraction rather than generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Requirements' section explicitly states when to use this tool ('Data table must be generated first') and when not to ('Returns error if table is not yet ready'), naming the alternative tool ('use generate_data_table'). This provides clear guidance on prerequisites and 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?
The description adds valuable behavioral context beyond annotations: it explains that this sets a default for 'ask_question', provides auto-switching guidelines with safety considerations (e.g., 'announce it', 'ask if ambiguous'), and includes an example of user-agent interaction. Annotations cover idempotency and non-destructive aspects, but the description enriches this with practical usage patterns 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ('When To Use', 'Auto-Switching', 'Example'), front-loading the core purpose. Each sentence earns its place by providing actionable guidance or examples, with no redundant or verbose content, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema) and rich annotations, the description is complete: it covers purpose, usage scenarios, behavioral nuances like auto-switching, and ties into sibling tools ('ask_question'). It provides all necessary context for an agent to use the tool effectively without needing output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'id' fully documented in the schema as 'The notebook ID to activate'. The description does not add any additional semantic details about the parameter beyond what the schema provides, such as format or sourcing, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Set a notebook as the active default') and the resource ('notebook'), distinguishing it from siblings like 'create_notebook', 'update_notebook', or 'list_notebooks'. It explicitly explains the functional purpose: to determine which notebook is used when 'ask_question' has no notebook_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance in a dedicated 'When To Use' section with three concrete scenarios (user switches context, asks explicitly, or task change requires another notebook). It also includes 'Auto-Switching' rules with clear conditions for when to auto-switch versus ask for clarification, and references the sibling tool 'ask_question' as context.
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=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it reveals the tool uses browser automation (implying potential latency and UI interaction), mentions context overflow risks with large histories, and provides practical guidance on managing output size. While it doesn't specify rate limits or authentication requirements, it adds meaningful operational context that annotations don't cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections: a purpose statement, bulleted use cases, a 'Context Management' section with parameter guidance, and practical examples. Every sentence earns its place by providing operational guidance or clarifying semantics. The information is front-loaded with the core purpose, followed by progressively detailed guidance. No redundant or verbose content exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and rich annotations, the description provides excellent contextual coverage. It explains the tool's operational context (browser automation), use cases, parameter interactions, and practical considerations like context overflow. The main gap is the lack of information about return format (though examples imply JSON), but given the annotations cover safety and the description covers usage patterns well, this is a minor omission in an otherwise comprehensive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the semantic purpose of key parameters: it clarifies that preview_only gives 'a quick count before extracting full content', output_file 'exports to JSON instead of returning to context' to avoid overflow, and offset/limit enable 'pagination through large histories'. It also provides concrete usage examples showing how these parameters work together. This goes well beyond the schema's technical descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Extract conversation history from a NotebookLM notebook's chat interface' using 'browser automation to navigate to a notebook and extract all Q&A pairs'. It clearly distinguishes this from sibling tools like get_query_history (which might be for different query types) or get_notebook (which retrieves notebook metadata rather than chat content). The verb 'extract' is specific and the resource 'conversation history/Q&A pairs' is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does 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: for 'recovering previous research conversations', 'auditing what queries were made', 'understanding quota usage', and 'resuming context from previous sessions'. It also offers practical usage patterns through the 'Context Management' section and examples, showing how to use preview_only for quick audits, output_file to avoid context overflow, and offset/limit for pagination. This gives clear operational context beyond basic invocation.
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 valuable behavioral context beyond annotations: it explains the sync parameter's impact on data accuracy, mentions browser automation requirements, describes query count reset timing, and provides detailed tier-based quota limits. While annotations cover read-only/idempotent aspects, the description enriches understanding of real-world behavior without contradicting 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Returns, Quota Limits, Usage notes) and every sentence adds value. It could be slightly more concise by integrating the quota limits into the returns section, but overall it's efficiently organized and front-loaded with core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations, and lack of output schema, the description provides excellent completeness. It details return values, tier-specific limits, parameter behavior implications, and timing considerations. This compensates fully for the missing output schema and aligns well with the structured annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3, but the description adds meaningful context about the sync parameter's implications ('fetch actual quota from Google's UI', 'locally tracked counts may differ'). It doesn't just repeat the schema but explains the practical consequences of the parameter choice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('current quota status'), and it distinguishes itself from siblings by focusing exclusively on quota retrieval rather than notebook/source management or query execution. It explicitly lists what information is returned, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use sync=true vs. false, explaining the trade-offs between accuracy and browser automation requirements. It also implicitly distinguishes this tool from siblings by focusing on quota status rather than operations like adding notebooks or executing queries, though it doesn't explicitly name 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 read-only, non-destructive, and idempotent behavior, but the description adds useful context about the purpose (continuing sessions) and the stats included (age, message count, last activity). It doesn't contradict annotations and enhances understanding beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core functionality and followed by usage guidance. Every word earns its place, with no redundancy or fluff, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is largely complete. It covers purpose, usage, and key stats. A minor gap is the lack of detail on output format or pagination, but this is mitigated by the straightforward nature of listing sessions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is high. The description doesn't need to explain parameters, but it implicitly clarifies that no filtering or input is required for listing all active sessions, which aligns with the empty schema. This adds slight value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all active sessions'), specifies the scope ('with stats (age, message count, last activity)'), and distinguishes from siblings by emphasizing continuation of existing sessions rather than starting new ones. This is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('to continue the most relevant session instead of starting from scratch'), providing clear context and distinguishing it from alternatives like creating new sessions or notebooks. This helps the agent choose appropriately among sibling tools.
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 cover key traits (read-only, non-destructive, idempotent, closed-world), but the description adds valuable context: it returns metadata fields (name, topics, use cases, URL) and implies a use case for selection workflows. No contradictions with annotations, and it enhances understanding beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with core functionality and followed by usage guidance. Every word earns its place—no redundancy or fluff—making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is complete: it explains what it does, when to use it, output details, and distinguishes from siblings. No gaps remain for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is high. The description adds no parameter details (as there are none), but it clarifies the output scope (metadata fields) and purpose, which compensates for the lack of an output schema, providing useful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all library notebooks'), specifies the metadata included (name, topics, use cases, URL), and distinguishes it from siblings like 'search_notebooks' by emphasizing comprehensive listing without filtering. This provides specific, actionable intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('to present options') and provides a clear workflow ('then ask which notebook to use for the task'), distinguishing it from alternatives like 'search_notebooks' for filtered queries. This gives strong guidance on context and next steps.
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?
While annotations already indicate destructiveHint=true and idempotentHint=true, the description adds significant behavioral context beyond annotations: the critical browser-closing requirement, cross-platform compatibility, safety mechanisms (preview before deletion, explicit confirmation), library preservation option, and detailed workflow guidance. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (warning, categories, platform info, preservation option, workflow, use cases). While comprehensive, some sentences could be more concise (e.g., the category list is detailed but necessary). The critical information is front-loaded with the warning and purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description provides complete context: clear purpose, detailed behavioral guidance, parameter usage examples, platform compatibility, safety mechanisms, prerequisites, and specific use cases. It compensates for the lack of output schema by explaining what happens during execution (preview then deletion).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds meaningful context about parameter usage: it explains the two-step confirmation workflow, provides specific recommended values (preserve_library=true), and clarifies the library preservation behavior. However, it doesn't add syntax or format details beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: scanning and cleaning NotebookLM MCP data files across 8 specific categories. It uses specific verbs ('scans entire system', 'shows categorized preview before deletion') and distinguishes itself from sibling tools by focusing on data cleanup rather than notebook/source management, authentication, or content generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines including when to use ('Clean reinstall, troubleshooting auth issues, removing all traces before uninstall'), prerequisites ('Close ALL Chrome/Chromium instances BEFORE running'), a recommended workflow with specific parameter values, and clear alternatives (preserve_library=true option). It also distinguishes when NOT to use it (when browsers are open).
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:

[![notebooklm-mcp-secure MCP server](https://glama.ai/mcp/servers/Pantheon-Security/notebooklm-mcp-secure/badges/card.svg)](https://glama.ai/mcp/servers/Pantheon-Security/notebooklm-mcp-secure)

Score Badge

Copy to your README.md:

[![notebooklm-mcp-secure MCP server](https://glama.ai/mcp/servers/Pantheon-Security/notebooklm-mcp-secure/badges/score.svg)](https://glama.ai/mcp/servers/Pantheon-Security/notebooklm-mcp-secure)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Pantheon-Security/notebooklm-mcp-secure'

If you have feedback or need assistance with the MCP directory API, please join our Discord server