NotebookLM MCP Server

Server Quality Checklist

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

Latest release: v0.7.8
Disambiguation5/5
Each tool has a clear, distinct purpose with no overlapping functionality. Detailed descriptions clarify any potential confusion, such as the separation between synchronous and asynchronous queries or between research steps.
Naming Consistency4/5
Most tools follow a verb_noun snake_case pattern (e.g., notebook_create, studio_create). However, a few tools are single word nouns (label, note, tag, batch), breaking the pattern slightly, but the overall convention is consistent enough.
Tool Count2/5
With 39 tools, the count is well above the typical well-scoped range. Several tools could be consolidated (e.g., notebook_query and notebook_query_start/status, or batch tool with sub-actions), making the surface too heavy for simple agents.
Completeness5/5
The tool surface covers all major NotebookLM operations: full CRUD for notebooks, sources, notes, labels, studio artifacts, research, sharing, authentication, and batch operations. No obvious gaps are present.
Average 4.1/5 across 39 of 39 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 24 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as whether the notebook is created in the current context, whether it returns an identifier, or what happens if the title is empty. The description is insufficient for an agent to understand the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single line and a brief parameter documentation. Every word is necessary, and there is no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter) and the existence of an output schema, the description is somewhat complete in terms of what it covers, but it fails to explain the creation behavior, such as where the notebook is created, what the response contains, or any side effects. This is inadequate for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema: it states 'title: Optional title for the notebook', which restates the schema's type (string) and default (''). The schema coverage is 0%, but the description does not compensate by providing format or constraints.
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 action 'Create a new notebook', which specifies the verb and resource. It distinguishes from sibling tools like notebook_delete or notebook_rename. However, it lacks detail about the creation context or scope.
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?
No guidance is provided on when to use this tool versus alternatives like notebook_rename or notebook_delete. There is no mention of prerequisites, such as requiring a parent notebook or workspace, nor any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It simply says 'Rename a notebook' but does not mention that it overwrites the existing title, what happens if the notebook doesn't exist, or any side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with no wasted words. It uses a standard docstring format and front-loads the action. However, it could be slightly more concise if the 'Args' section were integrated into prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 params, no annotations, output schema exists but not described), the description is too minimal. It does not explain return values, error cases, or integration with other notebook tools. The agent may lack context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds a brief hint ('Notebook UUID' and 'New title') beyond the parameter names. This provides minimal additional meaning; more detail on expected formats or constraints would be helpful.
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 'Rename a notebook', which is a specific verb and resource. This clearly distinguishes it from sibling tools like notebook_create, notebook_delete, notebook_describe, etc., which serve different purposes.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., notebook_update or notebook_set_title). The description lacks context about prerequisites, such as requiring an existing notebook, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the action (get) without revealing read-only nature, required permissions, or side effects. The meaning of 'sources' is unclear.
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 extremely concise with two sentences, no fluff, and front-loads the purpose. Every word contributes value.
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 simple one-parameter tool with an output schema, the description is nearly complete. It covers the basic purpose and the single parameter. Minor ambiguity remains about 'sources' and what 'details' include, but the output schema likely fills these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal value by labeling notebook_id as 'Notebook UUID'. It does not explain format, constraints, or how to obtain this ID, leaving the agent with limited semantic understanding beyond the schema's type.
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 the resource 'notebook details with sources', making the purpose straightforward. However, it does not explicitly differentiate from the sibling tool 'notebook_describe', which may have overlapping functionality.
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 (e.g., notebook_describe, notebook_list). No prerequisites, exclusions, or context for choosing this tool are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. 'AI-generated' hints at potential latency or cost, but it doesn't explicitly confirm read-only status, required permissions, or whether the source is modified. More transparency is needed.
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 and uses a clear structure with a purpose line and separate Args/Returns sections. It avoids waste but the format (docstring style) is slightly non-standard for MCP. Still, it's efficient and easy to parse.
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?
For a simple tool with one parameter, the description covers purpose and parameters adequately. However, it lacks behavioral context (e.g., read-only, cost implications) and does not reference the output schema. It is complete enough for basic use but has gaps.
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?
The description adds an Args section explaining source_id as 'Source UUID' and details the return format (summary with **bold** keywords, keywords list). With 0% schema coverage, this provides meaningful context beyond the raw schema, compensating well.
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 states 'Get AI-generated source summary with keyword chips,' which clearly identifies the verb (Get) and resource (source summary). It distinguishes from siblings like source_get_content but doesn't explicitly differentiate from similar 'describe' tools. The purpose is clear but could be sharper.
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?
No guidance on when to use this tool versus alternatives like source_get_content or source_list_drive. There is no discussion of prerequisites, usage context, or exclusions. The description only explains what it does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action and return type. It does not disclose important behaviors like idempotency, email sending, or what happens if the collaborator already has access.
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?
Extremely concise: one-sentence purpose followed by bullet-style parameter descriptions. Every part earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (inviting a collaborator), the description lacks completeness: no mention of permissions, output schema details, error conditions, or whether the invite is sent asynchronously. The existence of an output schema is not leveraged.
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 has 0% description coverage, but the description provides clear semantics for all three parameters: notebook_id (UUID), email (address), role (viewer/editor with default). This compensates well for the missing schema 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?
Clearly states the action: 'Invite a collaborator by email.' The verb 'invite' and resource 'collaborator' are specific, and the description distinguishes from sibling tools like notebook_share_batch or notebook_share_public by focusing on single email invites.
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?
No guidance on when to use this tool versus alternatives such as notebook_share_batch for bulk invites. No prerequisites or context about required permissions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It does not disclose pagination, sorting, or the actual behavior when max_results is omitted (default 100, not 'all'). The phrase 'list all notebooks' conflicts with the max_results parameter, causing ambiguity.
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?
Extremely concise: two lines with no redundant words. Every sentence is essential.
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 simplicity (1 param, output schema exists), the description covers the core action but lacks clarity on pagination and the exact meaning of 'all' with respect to max_results. Somewhat incomplete for an agent to fully understand behavior.
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 coverage is 0%, but the description explains the only parameter max_results, including its default value. This adds meaning beyond the schema's type and default.
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 'List all notebooks,' specifying the verb (list) and resource (notebooks). It distinguishes from siblings like notebook_get (get specific) and notebook_create (create).
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?
No guidance on when to use this vs alternatives like notebook_query. No mention of filtering, ordering, or limitations beyond max_results. The description does not help an agent decide between listing all vs querying with filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'rename' but does not mention if it is destructive, reversible, or requires specific permissions.
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 extremely concise, using a single sentence and a clear Args block. Every element is relevant, with no wasted words.
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?
The description lacks any mention of the output or return value, despite there being an output schema. For a straightforward rename tool, this is adequate but not complete; additional details about successful rename confirmation could be helpful.
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 coverage is 0%, so the description must compensate. It lists each parameter with a brief explanation ('Notebook UUID containing the source', 'Source UUID to rename', 'New display title'), which adds meaning beyond the bare 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 explicitly states 'Rename a source in a notebook,' using a specific verb and resource. It clearly distinguishes from sibling tools like source_add, source_delete, and source_describe.
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?
No guidance on when to use this tool versus alternatives or any prerequisites. The description lacks context about required permissions or conditions (e.g., source must exist, notebook accessible).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately explains the three actions and the return format for the 'status' action. However, it does not disclose potential side effects of 'rename' (e.g., whether it is reversible or requires specific permissions) or mention rate limits or error handling. The lack of contradiction with annotations is noted.
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 for arguments and returns. It is front-loaded with the core purpose. While informative, it could be slightly more concise by consolidating some details. Overall, it is organized and readable.
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 complexity with multiple actions and parameters, the description covers the 'status' action return format in detail but omits return structures for 'rename' and 'list_types'. Error handling and edge cases are not addressed. The presence of an output schema (not shown) may mitigate this, but the description alone is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains all four parameters: notebook_id (required, UUID), action (with options and defaults), and conditional requirements for artifact_id and new_title when rename is chosen. Each parameter's purpose and usage are clearly elucidated, going well beyond the schema.
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 dual purpose: checking studio content generation status and renaming artifacts. It uses specific verbs ('check', 'rename') and resource ('studio content generation', 'artifact'). While it distinguishes from siblings like 'studio_create' and 'studio_delete', it does not explicitly contrast with 'notebook_query' which also fetches status, though the scope differs.
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 does not provide guidance on when to use this tool versus sibling tools. It explains internal action options but does not specify when not to use this tool or suggest alternatives for different tasks (e.g., use 'studio_create' for new artifacts). The usage context is only implied by the actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only mentions parameter constraints (custom_prompt max length) but does not disclose if this is a read or mutation, prerequisites, or side effects. 'Configure' implies mutation but lacks detail.
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 line of purpose followed by an args list. It is highly concise, with no wasted words, and front-loads the main action.
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 presence of an output schema (which covers return values), the description is complete enough. It covers all parameters and constraints. Minor omission: no mention of persistence or side effects, but acceptable for a configuration 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?
Despite 0% schema coverage, the description explains all four parameters, including conditional requirements (custom_prompt required when goal=custom) and constraints (max 10000 chars). This adds significant 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 it configures notebook chat settings, with specific parameters listed. Among sibling tools, none overlap with chat configuration, so it is distinct.
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?
No explicit when-to-use or when-not-to-use guidance is given. The purpose implies it is for configuring chat, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must stand alone. It indicates a read operation ('Get') and outlines the return format (summary, suggested_topics), but does not explicitly state safety, auth requirements, or error behavior. Adequate but not fully transparent.
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 extremely concise: one opening sentence plus a compact args/returns section. Every element provides value without redundancy, and the key action is front-loaded.
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 (single parameter, read operation, output schema provided), the description fully covers purpose, parameter meaning, and return structure. No gaps remain for the agent's invocation needs.
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?
The schema has 0% description coverage, but the description explains the sole parameter 'notebook_id' as 'Notebook UUID,' adding format context beyond the schema's type string. This is meaningful and sufficient for a single parameter.
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 'Get AI-generated notebook summary with suggested topics,' specifying a unique verb-resource combination (Get + AI-generated summary) that distinguishes it from sibling tools like notebook_get or notebook_query.
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, such as notebook_get or notebook_query. No exclusions or conditions are mentioned, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return behavior (public_link if enabled, None if disabled) but does not mention permissions, side effects, or error conditions. Adequate but not comprehensive.
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 concise, using a clear docstring format with Args and Returns. Every sentence adds value, no fluff.
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 simple nature (2 params, boolean toggle) and the description covering input, behavior, and output, it is complete. No output schema needed as return is clearly specified.
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 0%, but the description clearly explains both parameters: notebook_id as UUID and is_public as boolean with default True. This compensates well for missing schema 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 clearly states 'Enable or disable public link access,' providing a specific verb and resource. It distinguishes from sibling tools like notebook_share_invite (user invitation) and notebook_share_batch (batch sharing).
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 lacks guidance on when to use this tool versus alternatives like notebook_share_invite or notebook_share_batch. No when/why information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It states creation of Google Docs/Sheets and returns a URL, but does not disclose potential side effects (overwriting, duplicate handling), authentication requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points for supported exports and a clear args list. Every sentence adds value without redundancy. Front-loaded with 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 presence of an output schema (though not shown), the description covers return format (URL). It addresses the key parameters and export behavior, but could include error scenarios or permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds full meaning: explains notebook_id, artifact_id, export_type (docs/sheets mapping), and title as optional. The export_type values are explicitly linked to artifact types.
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?
Clearly states the tool exports NotebookLM artifacts to Google Docs or Sheets, with specific mapping (Data Tables → Sheets, Reports → Docs). Distinguishes from sibling tools like download_artifact which implies local download.
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?
Describes supported export types but does not provide guidance on when to use this tool versus alternatives (e.g., download_artifact, notebook_query). No explicit when-not-to-use or prerequisite 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?
With no annotations provided, the description carries the full burden. It explains actions' behaviors, side effects (e.g., delete is permanent, reorganize replaces labels), and constraints (unlabeled_only). It does not cover rate limits or auth needs, but it provides sufficient operational transparency for the agent to avoid misuse.
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 an intro, action list, arg details, returns, and examples. It is slightly lengthy but every sentence adds value. Content is front-loaded with purpose. Minor efficiency improvements possible (e.g., tabular format for args), but solid overall.
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 (9 parameters, 8 actions) and that an output schema exists, the description is thorough. It covers all actions, parameter usage, and includes examples. It does not explicitly address error cases or edge conditions, but it is sufficient for an agent to use the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so excellently by explaining each parameter's purpose, when it is required, and its expected format (e.g., emoji example, label_id vs label_ids). This adds critical context beyond the raw schema, fully enabling correct invocation.
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 it manages source labels in a notebook and lists all supported actions (auto, list, etc.), providing strong specificity. However, it does not explicitly distinguish from the sibling tool 'tag', which might perform similar metadata operations, so a slight deduction for missing differentiation.
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 detailed usage context for each action, including prerequisites (5+ sources for auto-labeling) and conditional requirements (confirm for delete/reorganize). It lacks explicit comparison to sibling tools or scenarios where this tool should not be used, but the provided guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the return format (invited_count, recipients list, message) and the confirm requirement. However, it does not discuss side effects, permissions needed, or error cases when confirm is false.
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 and front-loaded with the main purpose. It efficiently covers parameters and returns. Could be improved with bullet points for better structure, but overall no unnecessary text.
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 complexity and absence of annotations, the description covers purpose, parameter details, and return values. It is mostly complete, though it lacks details on error handling, permissions, or prerequisites like ownership.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed semantics for all three parameters: notebook_id (UUID), recipients (list of dicts with email and optional role, default viewer, with example), and confirm (must be True after approval). This significantly adds meaning 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 'Invite multiple collaborators in a single request', specifying the action and resource. This distinguishes it from sibling tools like notebook_share_invite which invites a single collaborator.
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 usage context for batch invitations and notes that confirm must be True after user approval. However, it does not explicitly mention when to use alternatives like notebook_share_invite for single invitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the action and return values but does not disclose any behavioral traits such as required permissions, side effects, or whether the operation is idempotent. Being a 'get' operation, it's likely safe, but transparency is minimal.
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 extremely concise: two lines covering purpose and parameters. No extraneous text, and the key information is front-loaded.
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 that an output schema exists, the description does not need to detail return values, but it does provide a useful summary (is_public, access_level, collaborators, public_link). This makes the tool easy to understand without consulting the schema. Missing any context about when this should be used is the only gap.
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 coverage is 0%, so the description must compensate. It explicitly documents 'notebook_id' as 'Notebook UUID,' adding meaning beyond the schema's basic type. For a single parameter, this is helpful and clear.
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 'Get current sharing settings and collaborators,' which is a specific verb-resource pair. It distinguishes from sibling tools like notebook_share_invite, notebook_share_batch, and notebook_share_public that are for modification, not reading.
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 this is for reading sharing status, but does not explicitly state when to use versus alternative share tools. The context from sibling names helps, but the description lacks explicit guidance on exclusions or prerequisites.
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?
Describes source (disk or headless re-auth) and return status, but lacks detail on error handling or what happens if re-auth fails.
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?
Three clear sentences, front-loaded purpose, no fluff.
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?
Complete for a zero-parameter tool with output schema; could mention output schema details but not essential.
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?
No parameters, schema coverage 100%; description adds context but baseline is high due to empty 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?
Description clearly states it reloads auth tokens or runs headless re-authentication, distinguishing it from save_auth_tokens which saves tokens.
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?
Explicitly says call after `nlm login` or for automatic re-authentication; no direct exclusion for alternatives but sibling context provides clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states the action is irreversible and requires confirmation, effectively disclosing destructive behavior. However, it omits potential side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with a prominent warning, followed by a clear Args list. Every sentence adds value without 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?
Given no annotations and an output schema, the description covers the essential behavior and parameter semantics. It is adequate for a delete operation, though could mention return value or exact confirmation flow.
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 0%, but the description compensates by explaining each parameter's role: source_id for single deletion, source_ids for bulk, confirm as safety flag. This adds value beyond the bare 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?
Description clearly states the verb 'Delete' and the resource 'source(s)' with emphasis on permanence. It distinguishes from sibling tools like source_add, source_describe, etc.
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 implies when to use (to permanently delete sources) and mentions requirement for confirm=True, but does not provide explicit when-not-to-use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the tool returns a dict with status and saved path, but does not disclose potential side effects, required permissions, error handling, or concurrency limits. This is adequate but not thorough.
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-organized with sections for args, returns, and examples. It is slightly verbose but all content is relevant and aids understanding. No wasted sentences.
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 has 6 parameters, multiple artifact types, and an output schema, the description covers all necessary aspects: what inputs are required, optional, and format-specific details. The examples provide clear invocation patterns. Output schema exists, so return values need no further explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by explaining each parameter: artifact_type values with formats, artifact_id as optional, output_format and slide_deck_format defaults and options. This adds significant meaning 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 tool's purpose: 'Download any NotebookLM artifact to a file.' It specifies all artifact types and presents itself as a unified replacement for 9 separate tools, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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 specific parameters (e.g., output_format for quiz/flashcards only, slide_deck_format for slide_deck) and includes three diverse examples. However, it does not directly compare with the sibling 'export_artifact' or state when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It explicitly states that delete requires confirm=True, and that update/delete require note_id. This provides key behavioral context, though it omits details on idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for args, returns, and examples, but the example block is somewhat verbose. Overall, it is efficient and front-loaded with essential information.
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?
The description covers all 6 parameters with usage conditions, mentions return values, and includes examples for each action. Given the presence of an output schema, no gaps remain for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's role and conditionality (e.g., 'note_id required for update/delete', 'confirm Must be True for delete action'), adding rich meaning beyond the raw 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 tool's purpose ('Manage notes in a notebook. Unified tool for all note operations.') and lists supported actions (create, list, update, delete), distinguishing it from sibling tools like notebook_create which operate at the notebook level.
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 explains the actions and required parameters, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., batch operations or pipeline), leaving the agent to infer usage context from the action list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description should disclose behavioral traits. It explains that input_url replaces $INPUT_URL, but does not mention if execution is destructive, auth needs, or persistence. Moderately transparent.
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?
Well-structured with clear sections for actions and args. Every sentence adds value, no fluff.
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?
Covers parameters and actions well, but missing explanation of output or return values despite presence of output schema. Could mention that pipeline execution returns a result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains each parameter: action values, notebook_id required for run, pipeline_name required for run, input_url as URL variable. Adds essential meaning beyond 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?
Clearly states the tool manages and executes multi-step notebook pipelines, distinct from sibling tools like notebook_query that query notebooks directly.
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?
Explicitly lists actions (run, list) and when each is applicable, with required parameters per action. However, lacks comparison to alternative tools for pipeline management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations so description bears full burden. Mentions deprecations and auto-extraction but lacks details on persistence, side effects, or security implications. Adequate but not thorough.
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?
Well-structured with clear hierarchy (important note, bullet list). Slightly verbose but front-loads critical guidance.
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?
Covers usage context well but lacks completeness on outcomes, error scenarios, or what 'save' entails. Output schema exists but not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully compensates by explaining each parameter's purpose, when needed, and status (deprecated/optional). Adds meaning beyond schema types.
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?
Clearly states it saves cookies as a fallback method for authentication, with explicit preference for 'nlm login'. Distinguishes itself from sibling tools by indicating primary method.
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?
Provides explicit when-to-use ('only if CLI fails') and when-not ('try nlm login first'), along with deprecated parameter notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses asynchronous behavior, polling requirement, and that it returns result when completed or status otherwise. With no annotations, this is sufficient for a simple status check.
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?
Concise, front-loaded with purpose, and includes a parameter description. Every sentence adds value with no 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?
Given the existence of an output schema, the description adequately covers usage and expected behavior. Minimal gaps for a polling 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?
The single parameter 'query_id' is described as 'The query ID returned by notebook_query_start', adding necessary context beyond the schema's type-only definition.
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?
Description clearly states it checks status of an async query started by notebook_query_start. It specifies verb 'check', resource 'status', and the relationship to sibling tool.
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?
Explicitly instructs to poll every few seconds until status is 'completed' or 'error', providing clear usage guidance. Does not mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: blocking until complete or timeout, compact truncation, auto_import behavior, and task_id/query fallback. With no annotations, these disclosures are essential and well-covered, though error behavior on timeout is not detailed.
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 structured with an 'Args:' block and each parameter has a concise explanation. While not extremely terse, every sentence adds value for a tool with 7 parameters. It could be slightly more compressed but is not verbose.
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?
The description covers parameters, behavior, and workflow (auto_import vs manual). An output schema exists (not shown), so return values are assumed documented. Missing details about timeout handling and error cases, but overall complete for a polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are explained with defaults, purpose, and behavioral implications (e.g., compact truncates, auto_import triggers import). Schema description coverage is 0%, so the description fully compensates, adding meaning beyond the raw 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 'Poll research progress. Blocks until complete or timeout.' It uses a specific verb (poll) and resource (research progress), and the sibling tool set includes research_start and research_import, making the purpose distinct.
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 implicitly indicates when to use this tool (after starting research) and provides guidance on auto_import and fallback matching via query. However, it does not explicitly compare to sibling polling tools like notebook_query_status, so evaluation is slightly less clear.
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?
With no annotations, the description carries full burden. It explains the tool returns raw text from various source types (PDFs, web pages, etc.) and lists return fields. It lacks failure mode or prerequisite info, but is adequate for a simple read operation.
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 three sentences plus Args/Returns structure, front-loaded with the core purpose. Every sentence adds value: core action, scope/comparison, and output specification. No wasted words.
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 simple tool with one parameter and an output schema listed in description, it covers purpose, parameter meaning, return fields, and usage context. Could mention that the source must exist or error handling, but overall complete enough.
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?
The schema has 0% description coverage, but the description adds 'Source UUID' for source_id, clarifying its purpose. It also lists return fields, which indirectly explains the parameter's role. This adds meaningful context beyond the bare 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 'get' and resource 'raw text content of a source' while noting 'no AI processing', which distinguishes it from sibling tools like notebook_query that provide AI-processed content.
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 explicitly contrasts with notebook_query, stating it's 'much faster than notebook_query for content export', giving clear guidance on when to use this tool over an alternative. However, it does not list scenarios to avoid or mention other alternatives like source_describe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that freshness checks are performed by default and that skip_freshness speeds up listing, which are important behavioral details. It does not mention destructiveness or permissions, but for a listing tool, this is adequate.
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 extremely concise: two sentences for purpose and usage, then two bullet points for parameters. No extraneous words, well-structured, and front-loaded with the main action.
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 has an output schema (not shown), the description doesn't need to detail return values. It covers the main inputs, provides usage context relative to a sibling, and discloses a key option (skip_freshness). It is comprehensive for a listing tool with two parameters.
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 coverage is 0%, so description must compensate. It explains skip_freshness's effect ('skip per-source freshness checks for faster listing'), adding value beyond the schema. notebook_id is described as 'Notebook UUID', which is sufficient. Overall, it clarifies parameter behavior.
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 function: 'List sources with types and Drive freshness status.' It also distinguishes itself by suggesting use before source_sync_drive, which differentiates it from sibling tools.
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 explicitly says 'Use before source_sync_drive to identify stale sources,' providing a clear usage context. However, it does not specify when not to use it or list alternative tools, but the context is sufficient for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions the confirmation requirement but does not disclose potential side effects (e.g., overwrites, rate limits, permissions). The behavior beyond 'sync latest content' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus an Args section, all dense with information. Every sentence adds value—purpose, prerequisite, parameter meanings—with no redundancy or fluff.
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 2 parameters and an output schema, the description covers purpose, prerequisite, parameter semantics, and confirmation requirement. It lacks mention of idempotency or safety, but overall is sufficient given the output schema likely documents return values.
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 0%, but the description compensates by explaining both parameters: 'source_ids: Source UUIDs to sync' and 'confirm: Must be True after user approval'. This adds meaningful context beyond the schema's type definitions.
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 'Sync Drive sources with latest content', specifying a concrete action (sync) on a specific resource (Drive sources). This distinguishes it from sibling tools like source_add or source_delete, which have different verbs.
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: 'Call source_list_drive first to identify stale sources' and 'Requires confirm=True', instructing the agent on the correct workflow and prerequisites. This is strong usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the required confirm parameter (must be True after user approval) and type-specific options. However, it doesn't mention whether creation is synchronous or asynchronous, or what the output format is (output schema 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 long but well-structured with sections for args, type-specific options, common options, and examples. It front-loads the main purpose. Could be slightly more concise, but the structure aids readability.
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 high complexity (22 params, no annotations) and the presence of an output schema, the description does a good job covering creation behavior. It provides examples and explains type-specific parameters. It doesn't cover error handling or return values, but those may be in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds extensive meaning for each parameter, especially artifact_type and type-specific options. It provides detailed explanations, defaults, and valid values for all 22 parameters.
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 it is a unified creation tool for NotebookLM studio artifacts, lists all supported artifact types, and provides examples. It distinguishes itself from sibling tools like studio_delete and studio_revise.
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 usage context for creating any studio artifact and includes example calls. It does not explicitly state when not to use this tool or mention alternatives, but the breadth of supported types makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses irreversible deletion and confirmation requirement. With no annotations, this provides key behavioral traits, though side effects are not detailed.
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?
Very concise: two sentences plus bullet-style args. Information is front-loaded and every sentence is necessary.
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?
Covers the delete operation well. Though output schema exists but not shown, return values are typical. Could mention prerequisites like existing notebook.
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?
Describes each parameter with context (notebook UUID, artifact UUID from studio_status, confirm must be True after approval). Adds value beyond the schema, which lacks 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?
Clearly states it deletes a studio artifact and emphasizes irreversibility. Distinguished from siblings like studio_create and studio_revise by the delete action.
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?
Explicitly requires confirm=True and user approval, and notes irreversibility. Does not mention when to avoid or alternatives, but the context is clear.
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?
With no annotations, the description fully discloses behavioral traits: it lists actions like delete as irreversible and requiring confirm=True. It also describes each action's purpose. The existence of an output schema covers return values, so no further elaboration needed.
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: a concise opening summary, then a bulleted list of actions, then parameter explanations. It is slightly lengthy but efficiently organized, front-loading the purpose.
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 (9 parameters, multiple actions), the description covers actions, parameter usage, and notable constraints (e.g., confirm for delete). The presence of an output schema fills in return structure, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides meaningful explanations for each parameter (e.g., query for action=query, source_url for add_source, notebook_names as comma-separated strings). This adds value beyond the raw 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 it performs batch operations across multiple notebooks, listing specific actions. It distinguishes itself from sibling tools like notebook_create, notebook_delete, and source_add by being a batch operation tool.
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 clear usage context within the tool (e.g., actions and their parameters). However, it does not explicitly state when to use this tool versus alternative individual tools (e.g., notebook_create for single notebook creation), which would help an agent decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It explains that file_path must be on the MCP server machine, that image-bearing sources feed video generation, and describes wait/wait_timeout behavior. It does not cover error handling or side effects, but the given details are substantial.
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 brief purpose statement, a list of supported types, parameter descriptions, and examples. It is somewhat long but each sentence contributes useful information. It front-loads the core purpose and separates sections clearly, though minor redundancy exists (e.g., repeating source type examples).
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 complexity (11 parameters, 4 source types, conditional behaviors) and the presence of an output schema (which covers return structure), the description is highly complete. It addresses all parameter interactions, provides comprehensive examples, and clarifies platform-specific constraints (file_path accessibility).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 0%, so the description must fully explain all 11 parameters. It does so thoroughly, detailing each parameter's role conditioned on source_type, including supported extensions for file, and providing multiple examples that illustrate parameter combinations. This adds significant value beyond the bare 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 'Add a source to a notebook. Unified tool for all source types.', specifying the verb (add), resource (source to notebook), and scope (all source types). It lists supported types, distinguishing it from siblings like source_delete, source_describe, etc., which handle other operations on sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool is unified for all source types and provides parameter usage per type (url, text, drive, file) with examples. It does not explicitly state when not to use this tool, but the sibling tool names imply alternatives for specific operations (e.g., source_delete, source_sync_drive), making the usage context clear enough.
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?
With no annotations, the description discloses key behaviors: it creates a new artifact without modifying the original, requires confirm=True after user approval, and is asynchronous (poll status). However, it lacks details on error handling or rate limits.
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 header, parameter list, and example. It is reasonably concise, though the example could be slightly condensed.
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 presence of an output schema, the description covers purpose, usage, parameters, and behavioral expectations thoroughly. No additional information seems necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all parameters in detail, including the structure of slide_instructions and the required confirm=True. An example further clarifies usage.
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 'Revise individual slides in an existing slide deck. Creates a NEW artifact.' This is a specific verb+resource combination that distinguishes it from sibling tools like studio_create or studio_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that only slide decks support revision and advises polling studio_status after calling. It provides clear context but does not explicitly state when not to use this tool or list 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?
Since no annotations are provided, the description carries the full burden. It describes the query-and-aggregate behavior, mentions per-notebook citations, and warns about rate limits for all=True. It does not mention auth requirements or side effects, but query operations are inherently safe.
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 concise, starting with the core purpose followed by specification details in a bullet-like format. Every sentence adds value 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?
Given the tool's complexity and the presence of an output schema, the description covers key usage aspects: how to select notebooks, the query parameter, and a warning. It is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains each parameter: query as the question, notebook_names and tags as selection methods with examples, and all with a caution. This adds essential meaning 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 tool queries multiple notebooks and returns aggregated answers with per-notebook citations. It distinguishes from sibling notebook_query by focusing on multi-notebook queries and provides three specification methods.
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 explains how to specify notebooks (by name, tags, or all) and includes a caution for all=True regarding rate limits. However, it does not explicitly tell when to use this tool versus the single-notebook query alternative.
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?
With no annotations, the description must carry the behavioral burden. It explains the async workflow (poll and import), mode-specific performance (time and source counts), and that notebook_id creates a new notebook if omitted. It does not mention potential side effects like overwriting, but overall provides solid transparency.
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 structured into an intro, use cases, workflow, and args. Every sentence is purposeful, no waste. It is front-loaded with the core action and entirely self-contained.
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 presence of an output schema, the description does not need to detail return values. It provides a complete picture of the tool's purpose, workflow, and parameter effects. The links to sibling tools via workflow enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by listing each parameter with examples, defaults, and explanations (e.g., 'mode: fast (~30s, ~10 sources) | deep (~5min, ~40 sources, web only)'). This adds significant meaning beyond the schema's type and default information.
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 starts with a clear verb and resource: 'Search web or Google Drive to FIND NEW sources.' It lists specific use cases like 'deep research on X' and 'search web for Z,' and distinguishes itself from siblings by outlining the workflow research_start -> research_status -> research_import.
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 explicitly states when to use the tool ('Use this for: ...') and provides mode/source options. However, it does not mention when not to use it or contrast with alternatives like notebook_query, leaving room for improvement.
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?
With no annotations, the description carries the burden of behavioral disclosure. It explains the four actions and their parameter dependencies, but does not mention side effects, permissions, or limits. It is adequate but could be more explicit about behavior beyond the action descriptions.
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 concise with bullet points, no redundant sentences, and front-loads the overall purpose. Every sentence adds value.
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 has 5 parameters, 0% schema coverage, no annotations, and an output schema exists, the description is complete. It covers all actions and parameter constraints, making it sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully explains each parameter: action (operation), notebook_id (required for add/remove), tags (format and requirement), notebook_title (optional), query (required for select). Examples are provided, adding meaning beyond the raw 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 tool's purpose: 'Manage notebook tags and find relevant notebooks by tag matching.' It lists four specific actions (add, remove, list, select) with distinct roles, distinguishing it from sibling tools like notebook_list or notebook_query.
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 when to use each action via parameter requirements, but it does not explicitly state when not to use this tool or compare it to alternatives like notebook_list for listing notebooks without tag matching.
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 fully discloses the permanent, irreversible nature of the deletion and the mandatory confirm=True safety mechanism. With no annotations provided, this carries the entire burden and does so excellently.
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 extremely concise: a single impactful sentence followed by clean parameter definitions. Every sentence serves a purpose with no 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?
Given the tool's simplicity (2 parameters, no annotations, but has output schema), the description covers all necessary context: destructive action, confirm requirement, parameter types. The presence of output schema means return values need not be explained.
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?
The input schema has no descriptions (0% coverage), so the description must compensate. It does so by explaining notebook_id as a UUID and confirm as requiring user approval, adding significant meaning beyond the raw 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 'Delete notebook permanently' with strong emphasis on irreversibility. It specifies the exact action and resource, and distinctly separates from sibling tools like notebook_create or notebook_rename.
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 explicitly requires confirm=True and user approval before deletion, providing clear usage context. It lacks explicit alternatives or when-not-to-use scenarios, but for a destructive operation the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It accurately discloses that the tool queries existing sources (not modifying) and describes behavior via parameters. Missing explicit read-only claim or auth requirements, but query intent is clear.
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 extremely concise: two sentences for purpose/guidelines followed by a lean parameter list. Every sentence adds value, no fluff. Key info is front-loaded.
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 that an output schema exists (but not shown), the description adequately covers tool behavior, usage constraints, and parameter details. It explains when to use alternatives, fulfilling contextual needs for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all 5 parameters: notebook_id, query, source_ids (default all), conversation_id (for follow-up), and timeout (default from env or 120.0). This adds substantial meaning 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 'Ask AI about EXISTING sources already in notebook' and explicitly says 'NOT for finding new sources', distinguishing it from research_start. The verb 'ask' and noun 'sources' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('Ask about existing sources') and when-not-to-use ('Use research_start instead for deep research, web search, find new sources, Drive search'). It also explains parameters like conversation_id for follow-up and timeout.
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?
Without annotations, the description carries the burden of behavioral disclosure. It explains the async behavior, immediate return of query_id, and default timeout. It does not mention side effects, error handling, or authentication, but the core behavioral traits are sufficiently covered.
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 concise and well-structured: a clear purpose statement, when-to-use guidance, a workflow summary, and a parameter list. Every sentence adds value 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?
Given the tool's moderate complexity and the presence of an output schema (implied by 'returns immediately with a query_id'), the description provides sufficient context to use the tool correctly, including the complete workflow and parameter details.
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?
Although schema coverage is 0%, the description includes an Args section that explains each parameter with default values and context (e.g., 'source_ids: Source IDs to query (default: all)', 'timeout: Request timeout in seconds (default: from env NOTEBOOKLM_QUERY_TIMEOUT or 120.0)'). This adds meaning beyond the parameter names.
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: 'Start a notebook query asynchronously for large notebooks that may timeout.' It specifies the verb 'start' and the resource 'notebook query', and distinguishes itself from the sibling tool 'notebook_query' by noting the async nature and use case for large notebooks.
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 when to use this tool vs. the sibling 'notebook_query': 'Use this instead of notebook_query when querying notebooks with many sources (50+) where the response may take longer than 60 seconds.' It also outlines the workflow: 'notebook_query_start -> poll notebook_query_status until completed.'
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?
Discloses detailed behavioral traits: 30-second TTL caching, mtime-based bypass on auth-file changes, multi-probe strategy (homepage + API fallback). Explains that auth_status may be up to 30 seconds old and how external login is picked up. No annotations provided, so description carries full burden; no contradictions.
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 relatively long but well-structured with clear sections, bullet points for auth_status meanings, and front-loaded purpose. Every sentence adds value, though some repetition exists (e.g., 'cached credentials may be reported as configured' could be merged with caching explanation). Still appropriately sized for the complexity.
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 zero parameters and a fully described output schema (including version info, update availability, auth status, and update command), the description is complete. It covers all return values and their interpretation, leaving no ambiguity for the agent.
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?
Input schema has zero parameters, so baseline is 4. Description adds no parameter info as none are needed. The description's value is in explaining output rather than inputs.
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 'Get server version, check for updates, and report auth status' with specific verbs and resources. It clearly distinguishes itself from sibling tools by focusing on server metadata and auth status.
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?
Provides explicit guidance for AI assistants on handling update_available and each auth_status value, including actionable steps (e.g., 'inform the user that a new version is available', 'ask the user to run nlm login'). Also explains caching behavior and when to assume re-auth is needed.
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?
Despite no annotations, the description fully discloses behavior: timeout increase advice, cited_only overriding source_indices, and default import all sources. No contradictions.
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?
Front-loaded with purpose and timing, then lists arguments clearly. Every sentence adds value, with no 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?
Covers input parameters, usage conditions, edge cases (cited_only), and performance advice (timeout). With output schema present, return value detail is unnecessary. Complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains all five parameters including defaults, types, and special behaviors (e.g., cited_only overrides source_indices). Fully compensates for missing schema 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 clearly states 'Import discovered sources into notebook' with a specific verb and resource. It distinguishes itself from sibling tools like research_start and source_add by focusing on the import action.
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?
Explicitly states to call after research_status shows status='completed', and explains the cited_only override behavior. Provides clear timing and conditional logic.
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-cli MCP server](https://glama.ai/mcp/servers/whmathews15/notebooklm-mcp-cli/badges/card.svg)](https://glama.ai/mcp/servers/whmathews15/notebooklm-mcp-cli)

Score Badge

Copy to your README.md:

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

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/whmathews15/notebooklm-mcp-cli'

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