notebooklm-mcp

by jacob-bd

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.10.1
Disambiguation3/5
Most tools are clearly separated by resource (notebook, source, studio, collection, research) and descriptions explicitly disambiguate tricky pairs like notebook_query vs research_start. However, the catch-all batch tool overlaps with notebook_query, source_add, notebook_create/delete, and studio_create; cross_notebook_query duplicates the batch query action; and label vs tag are easy to confuse despite operating on different entities.
Naming Consistency3/5
The dominant noun_verb pattern (notebook_list, source_add, studio_create, collection_delete) is consistent across most resource groups, including the notebook_query_start/_status async pair. But verb-first exceptions (refresh_auth, save_auth_tokens, download_artifact, export_artifact) and five bare-verb umbrella tools (batch, label, note, pipeline, tag) break the pattern and create a mixed convention.
Tool Count2/5
48 tools is well into the 'too many' range (25+) and close to the extreme threshold. The unified action-dispatching tools (label, note, tag, batch, download_artifact) help cap the count, but the surface still forces agents to navigate a large tool space with many near-duplicate query, status, and batch paths.
Completeness4/5
The surface covers the NotebookLM domain thoroughly: full CRUD for notebooks, collections, notes, and labels; complete studio lifecycle (create, status, revise, delete, download, export); research workflow (start, status, import); chat, sharing, and auth. Minor gaps: no generic 'list all sources' tool (only source_list_drive, though notebook_get returns sources) and no chat deletion or source-moving capability.
Average 4.1/5 across 48 of 48 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 117 of 117 community issues answered or closed in the last 6 months
- 136 commits in the last 12 weeks
- Last stable release on September 3, 2026
- 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.
Tools from this server were used 2 times in the last 30 days.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description solely communicates a read operation ('get'). It does not disclose any behavioral traits such as data scope, permission requirements, or side effects. The term 'sources' is vague and not explained.
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 very concise with two sentences covering the action and single parameter. No unnecessary words. However, it could be expanded slightly for clarity without violating conciseness.
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 existence of an output schema, the description doesn't need return value details, but it fails to explain what 'details' and 'sources' mean. The tool has many siblings (e.g., notebook_describe, notebook_list), and the description provides no context for selection, making it incomplete for a tool of this complexity.
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 only repeats the parameter name and type ('Notebook UUID'), adding minimal semantic value beyond the schema. At 0% schema description coverage, the description should elaborate on the parameter's purpose or format, but it does not.
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 'Get notebook details with sources', specifying the verb and resource. However, it does not explicitly distinguish from sibling tools like notebook_describe or notebook_list, so there is room for improvement.
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_list for summaries, notebook_describe for different details). The description lacks any usage context or prerequisites.
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, and the description lacks behavioral details such as side effects, permissions needed, or error conditions. For a mutation tool, more transparency is expected.
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?
Very concise with a clear one-sentence purpose and a list of parameters. Could be slightly more structured but efficient.
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?
Despite having an output schema (not shown), the description does not explain return values. Lacks behavioral context and usage guidelines, making it incomplete for an agent.
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%, but the description lists parameter names and types in Args, adding minimal value beyond the schema itself. No further semantic detail about constraints or formats.
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,' using a specific verb and resource. It distinguishes from sibling tools like notebook_delete and 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?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or context for usage.
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 alone must disclose behavior. It states 'rename' (mutation) but does not mention side effects, permissions, reversibility, or error handling. The existence of an output schema is acknowledged but not described.
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: a single sentence stating the purpose followed by a structured parameter list. It is front-loaded with the main action, but the parameter list is slightly redundant with the schema, though it adds context.
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?
For a simple rename tool, the description covers purpose and parameters minimally but misses behavioral context (idempotency, failure modes, return type) and prerequisites (e.g., existence of notebook/source). The output schema exists but is not leveraged to describe the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds value by naming parameters and giving brief explanations (e.g., 'Notebook UUID containing the source'). However, it lacks details on constraints (e.g., title length limits, UUID format) and does not explain the meaning beyond what is obvious from the 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 verb 'Rename' and the resource 'source in a notebook', distinguishing it from sibling tools like source_add, source_delete, and source_describe. It specifies the context and action concisely.
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 (e.g., source_add for adding, source_delete for removing). No prerequisites or exclusion conditions are mentioned, leaving the agent to infer usage without direction.
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, description carries full burden. It does not disclose whether the tool is destructive/reversible, what it does to existing settings, or any authentication requirements. Only parameter constraints are mentioned.
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: purpose stated first, then parameter list in clean format. No superfluous text. Every sentence is informative.
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?
While parameters are described, the overall effect of configuration (e.g., what goal or response_length actually do) is missing. Return value or success indication not mentioned. Annotations are absent. An output schema exists but description does not reference it.
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?
Adds valuable meaning beyond schema: explains custom_prompt is required when goal=custom with a max length constraint. This conditional logic is not in the schema. However, 0% schema coverage means more explanation would be beneficial.
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?
Description clearly states 'Configure notebook chat settings' with a specific verb and resource. It distinguishes from sibling tools like chat_list and chat_get, which list/get chats, by indicating configuration. However, it could be more explicit about modifying existing settings.
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 chat_configure vs alternative tools. It does not specify prerequisites or conditions (e.g., notebook existence, permissions) or exclude scenarios.
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?
The description only states the creation action without disclosing side effects, auth requirements, or constraints such as duplicate title handling. Since no annotations are provided, the description carries full burden but adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no wasted words, front-loading the action effectively. It includes an args section in a clear format, though it could be slightly more informative without harming conciseness.
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 creation tool with one optional parameter and an output schema, the description is minimally adequate. However, it omits details about what constitutes a notebook (e.g., structure) and any prerequisites, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds 'Optional title for the notebook,' which clarifies the parameter's optionality and role. This provides some added meaning beyond the schema's default value, though it lacks details like length limits.
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 'Create a new notebook.' clearly states the action (create) and the resource (notebook). It distinguishes the tool from siblings like notebook_list, notebook_get, and notebook_delete, which have 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 such as notebook_import or notebook_clone. There are no when-to-use or when-not-to-use indicators, leaving the agent to infer usage without context.
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. The description lacks details on pagination, ordering, or filtering behavior beyond max_results. It does not disclose whether the list is complete or limited.
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 two sentences. But the parameter description could be integrated more naturally. 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?
Given the tool's simplicity and presence of output schema, the description is adequate but lacks details on return format or pagination behavior. It could mention that notebooks are returned as a list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains max_results parameter with default value, adding meaning beyond schema. However, it could specify whether results are sorted or if there is a maximum limit.
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,' which is a specific verb+resource. It distinguishes from sibling tools like notebook_get, notebook_create, and notebook_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 vs alternatives like search or filter tools. The description does not mention excluded scenarios or prerequisites.
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?
Since annotations are absent, the description carries the full burden of behavioral disclosure. It conveys only that the tool 'creates' a collection, but does not disclose what happens on duplicate names, whether notebook_ids are validated against existing notebooks, what side effects occur, or any error behavior. There is nothing misleading, but there is no behavioral nuance beyond the verb itself.
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 compact and front-loaded: a single, plain purpose sentence followed by a short Args block. No filler, from any word, and the structure is appropriately minimal for a simple two-parameter tool.
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 that this is a simple two-parameter create operation and that an output schema provides return information, the definition is minimally viable. However, it lacks broader context such as what a 'collection' is semantically, how it relates to notebooks, or any potential pitfalls (e.g., constraints on the name or behavior with invalid notebook_ids).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself has 0% description coverage, so the parameter semantics are introduced to compensate. The Args section does add value for notebook_ids — it explains the array contains UUIDs and that they are 'to include in the collection' — but the name parameter is glossed only as 'Name of the collection,' which nearly restates the property name and adds little semantic content.
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 opening sentence 'Create a new collection.' states a specific verb (create) and a specific resource (collection). This clearly distinguishes it from sibling tools like collection_list, collection_edit, collection_delete, and collection_set_emoji, which each have a different operation on the same resource.
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 other collection or notebook tools. It does not mention common use cases, preconditions (e.g., whether notebooks must exist before being referenced), or situations where a sibling tool such as collection_edit should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool lists collections, with no mention of read-only semantics, authentication requirements, pagination, ordering, or the meaning of 'native'. This is a significant gap for a tool with zero annotation support.
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 a single, concise sentence with no wasted words. It is slightly under-specified, particularly the ambiguous 'native' qualifier, but it remains appropriately brief for a no-parameter tool.
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 is simple (no parameters, output schema exists), the description is mostly adequate, but the undefined term 'native' and lack of behavioral details such as pagination or ordering leave room for agent confusion. A sentence clarifying 'native' or noting the output shape would make it complete.
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 tool has zero parameters and the schema is already fully described (100% coverage), so the baseline of 4 applies. The description correctly adds no parameter information because there are no parameters to document.
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 states a specific verb ('List') and resource ('all native collections'), making the tool's purpose immediately clear. Among siblings, there is no other collection-list tool, so the name and description together distinguish it from collection_create, collection_edit, collection_delete, and collection_set_emoji.
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 given about when to use this tool versus alternatives, nor any exclusion criteria. The qualifier 'native' vaguely implies a distinction from non-native collections, but this is not explained, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does disclose a key nuance: passing an empty string clears the emoji rather than setting it. However, it does not mention permissions, overwrite behavior, or any side effects beyond the mutation, leaving some uncertainty for a tool with no annotation safety profile.
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 minimal and well structured: one purpose sentence followed by two arg lines. There is no filler, and the important clearing behavior is included efficiently without bloating the description.
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 tool is simple and an output schema exists, so return values need not be described. But the description lacks when-to-use routing relative to collection_edit, error/precondition notes, and any behavioral context beyond the bare mutation. It is adequate for invocation but has gaps an agent might stumble on.
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 provides no property descriptions, so the description must compensate. It does so for both parameters: collection_id is explained as the UUID of the collection, and emoji is described with the special empty-string clearing behavior. This is sufficient for a simple two-parameter tool, though it omits format constraints like maximum emoji length or valid emoji characters.
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 opens with a specific verb and resource: 'Set or clear the emoji marker on a collection.' This is clear and unambiguous. However, it does not explicitly differentiate itself from sibling collection_edit, which could also modify collection fields, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over collection_edit or other collection tools. It states what the tool does but not the conditions, exclusions, or alternatives that should drive selection. No sibling is named or recommended.
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 full burden. It discloses the permanent nature of deletion and the non-deletion of notebooks, which is important behavioral context. However, it doesn't mention whether the operation is reversible, what happens to associated artifacts, or any permission requirements. The confirm parameter is disclosed but its purpose (safety guard) is implied rather than explicit.
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 key fact (permanent deletion, notebooks not deleted). The Args section is clear and minimal. No wasted words, though the format could be slightly more structured.
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 tool has an output schema (not shown) and only 2 parameters, so the description covers the essential semantics. However, for a destructive operation with no annotations, it could benefit from more context about what happens to the collection's contents, whether the operation can be undone, and any side effects. The confirm parameter's role is stated but not elaborated.
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%, so the description must compensate. It explains collection_id as a UUID and confirm as a boolean that must be True after user approval. This adds meaning beyond the bare schema types, though it could be more detailed about the confirm parameter's role in preventing accidental deletion.
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 deletes a collection permanently and explicitly notes that notebooks inside are NOT deleted. This distinguishes it from sibling tools like notebook_delete and source_delete, though it doesn't name them explicitly.
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 usage for deleting a collection, and the confirm parameter requirement is stated. However, it doesn't explicitly contrast with alternatives like notebook_delete or provide conditions for when to use this vs. other deletion tools. The 'confirm must be True after user approval' gives some usage context but no explicit when/when-not guidance.
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 the description carries full burden. It does not disclose side effects, prerequisites, or whether the operation is read-only. The action 'export' is implied non-destructive but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence followed by a parameter list. It is front-loaded with the main action, though the parameter list could be integrated more smoothly.
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 an output schema exists, return values need not be explained. However, the description lacks information on output handling, limitations, or prerequisites (e.g., ownership). It is adequate but not comprehensive.
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 the schema description coverage being 0%, the description provides meaningful descriptions for all parameters: 'Notebook ID or title alias', 'Optional conversation ID', and 'Export format: md or json (default: md)', adding context 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 action 'Export a chat transcript' to specific formats 'Markdown or JSON'. This distinguishes it from sibling tools like chat_list (list) and chat_get (get single).
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 guidance on when to use this tool versus alternatives. The purpose is clear but lacks context for selection among similar export methods.
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 bears full burden. It only states 'Returns: success status', lacking details on error handling (e.g., invalid email, duplicate invite), side effects, or required permissions. Behavioral traits are minimally disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no extraneous words. It lists parameters clearly but could benefit from a more structured format (e.g., bullet points) for readability.
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 presence of an output schema (not shown), return details may be there, but the description only says 'success status'. Lacks context on error conditions, idempotency, and whether the operation is reversible. Moderate completeness.
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 adds meaning: notebook_id is 'Notebook UUID', email is 'Email address to invite', role has explicit enum values ('viewer' or 'editor') with default. This 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 'Invite a collaborator by email', specifying the verb 'invite' and the resource 'collaborator'. It distinguishes from sibling tools like notebook_share_status (status check) and notebook_share_public (public sharing) by focusing on email invite.
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 usage for inviting a specific user via email but does not provide explicit guidance on when to use this tool versus alternatives (e.g., batch share). No 'when not to use' or context about prerequisites.
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, and the description does not disclose behavioral traits such as side effects (e.g., whether 'run' modifies data), authentication requirements, or rate limits. The term 'execute' implies mutation but lacks explicit safety warnings.
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 single-sentence overview, bulleted actions, and a detailed args list. Every sentence adds value without redundancy or unnecessary elaboration.
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?
While the description covers actions and parameters adequately, it lacks behavioral context (e.g., synchronous vs async, error handling) and does not leverage the existing output schema to explain return values. Given no annotations, more completeness is needed.
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 compensates by explaining all four parameters: action (with values 'run' and 'list'), notebook_id (required for run), pipeline_name (with example 'ingest-and-podcast'), and input_url (replaces $INPUT_URL). This adds essential 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 tool manages and executes multi-step notebook pipelines, with explicit actions 'run' and 'list' to further clarify scope. This distinguishes it from sibling tools like notebook_query or chat_list that handle different resources.
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 lists actions but provides no guidance on when to use this tool vs alternatives like notebook_query or source_list_drive. It does not specify prerequisites or when not to use it, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it exports and returns a URL, but does not disclose permissions, side effects (e.g., whether it creates a new document in user's drive), or any destructive behavior. It is a read-like operation but not explicit.
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?
Description is concise, uses bullet points for supported conversions, and front-loads the core action. Every sentence adds value; no unnecessary 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?
Given an output schema exists (so return value is covered), the description covers all parameters, supported conversions, and the return URL. It could mention error conditions or prerequisites, but overall complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It lists three required parameters and one optional, and explains the mapping of export_type to target format. However, it does not specify valid values for export_type as an enum or describe format constraints for IDs.
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 exports an artifact to Google Docs or Sheets, with specific mappings (Data Tables → Sheets, Reports → Docs). It uses a specific verb+resource and distinguishes from sibling tools like download_artifact.
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 (export to Google Docs/Sheets) but does not explicitly tell when not to use or compare to alternatives like download_artifact. No exclusion criteria or context-driven guidance.
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 behavioral traits. It outlines actions and required parameters but does not mention side effects (e.g., consequences of adding duplicate tags), idempotency, or authentication requirements, leaving gaps for safe invocation.
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 purpose statement followed by bullet lists for actions and parameters. It is mostly concise, though some parameter examples could be trimmed without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema exists, the description covers input well but does not explain return values or pagination. It is adequate but leaves some behavioral context unaddressed.
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 for all parameters: action, notebook_id, tags (with comma-separated example), notebook_title, and query (with example). It specifies which parameters are required for which actions, significantly enhancing 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 manages notebook tags and finds relevant notebooks via tag matching. It lists specific actions (add, remove, list, select) and differentiates from siblings like notebook_query which are about querying content rather than tags.
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 usage via actions but does not explicitly guide when to use this tool versus alternatives like notebook_query or cross_notebook_query. It lacks when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details such as error handling, pagination, or side effects. For a simple list operation, it is minimally adequate but would benefit from more disclosure.
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 no extraneous text. Purpose comes first, followed by parameter details in a clear format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list with two parameters) and presence of an output schema, the description is largely complete. Missing details like ordering or error responses are minor 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 meaning beyond the schema by explaining notebook_id as ID or title alias and noting limit's default. Since schema has no descriptions, this is helpful and covers all 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 the tool lists chat sessions for a notebook using a specific verb and resource. This distinguishes it from siblings like chat_get (single chat) or notebook_query (different purpose).
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 chat_get. No context about prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return format (summary in markdown, suggested topics list), but does not mention that the summary is AI-generated (which may imply latency, cost, or content considerations). No side effects or restrictions are noted, leaving behavioral traits partially unspecified.
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 front-loaded, with the purpose in the first sentence. The inclusion of an args block is slightly redundant but acceptable. Every sentence contributes value.
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 presence of an output schema (not shown), the description could omit return details but chooses to include them, which is helpful. However, it does not explain what 'suggested topics' means or any prerequisites for the notebook (e.g., must have content). The completeness is adequate for a simple summary tool but could be richer.
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 'Notebook UUID' to the notebook_id parameter, clarifying its expected format beyond the schema's type string. This adds meaningful semantics for a single required 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 the tool returns an AI-generated notebook summary with suggested topics. This distinguishes it from siblings like notebook_get (which likely returns raw metadata) and notebook_query (which runs queries). The verb-resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining a summary, but it does not explicitly state when to use this instead of other notebook tools (e.g., notebook_get for raw data, notebook_query for specific queries). No exclusions or alternatives are mentioned, leaving the agent to infer usage.
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?
Without annotations, the description should disclose behavioral traits. It explains that conversation_id defaults to the latest active session, but does not mention error handling, rate limits, or side effects. The read-only nature is inferred but not explicit.
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 three lines, front-loading the purpose. Every word adds value, with no redundant or vague statements.
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 read tool with 2 parameters and an output schema (which documents return values), the description covers the core usage and default behavior. It lacks details on error scenarios (e.g., invalid notebook_id), but the existing information is sufficient for typical use.
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, but the description fully compensates by explaining both parameters: notebook_id as 'Notebook ID or title alias' and conversation_id as 'Optional conversation ID (defaults to latest active session)'. This adds critical meaning beyond the schema's type-only 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 'Get full transcript of a specific chat session,' providing a specific verb and resource. It distinguishes itself from sibling tools like 'chat_list' (lists sessions) and 'chat_export' (exports transcripts), so the purpose is unambiguous.
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 given on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or comparisons with similar tools like 'chat_list' or 'chat_export', leaving the AI agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It highlights irreversibility of delete and necessity of confirm=True, but does not disclose other side effects (e.g., partial failures, rate limits, or permission requirements). Adequate but incomplete.
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?
Description is front-loaded with purpose and action list, followed by parameter details. It is structured but could be slightly tighter (e.g., remove redundant phrasing). However, it is efficient and scannable.
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 (9 parameters, multiple actions) and presence of an output schema, the description covers actions and parameter dependencies. However, it lacks details on error handling, partial failures, or atomicity, which are important for batch operations. The output schema may fill some gaps, but completeness is still moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential meaning: it maps parameters to actions (e.g., query for action=query, source_url for add_source) and specifies formats like 'Comma-separated notebook titles'. Some ambiguity remains (e.g., whether notebook_names accepts IDs or names), but overall significantly compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Perform batch operations across multiple notebooks' and enumerates specific actions (query, add_source, create, delete, studio). This distinguishes it from single-notebook operations like notebook_query or cross_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 provides context for when to use each action, e.g., query requires a 'query' parameter, delete requires 'confirm=True' and is irreversible. It lacks explicit when-not or alternatives, but the action listing implies appropriate usage scenarios.
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 full burden. It discloses return fields (is_public, access_level, collaborators, public_link) and implies a read-only operation, but does not mention permissions, rate limits, or other behavioral traits.
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 no wasted words; purpose is front-loaded and every sentence adds 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?
Given the tool's simplicity (one parameter, read-only) and the presence of an output schema, the description adequately explains the return values. It lacks mention of permission requirements but is otherwise complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by specifying 'Notebook UUID' for the single parameter, 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 'Get current sharing settings and collaborators', which is a specific verb+resource. It differentiates from sibling tools like notebook_share_public (which sets sharing) and notebook_share_invite (which invites).
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 use to check current settings but provides no explicit guidance on when to use this tool versus alternatives or any conditions/prorequisites.
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 full burden. It usefully discloses that notebook_ids is a 'New complete list' to include, implying replacement rather than incremental updates, and marks fields as optional. But it does not mention permissions, failure behavior, or the effect of omitting notebooks from the list beyond the 'complete list' wording.
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 front-loaded sentence followed by a compact argument list. Every line carries useful information with no filler, repetition, or unnecessary detail.
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?
All three parameters are described, an output schema exists, and the core edit/replacement semantics are communicated, making the tool callable. It is slightly incomplete in lacking explicit alternative-tool routing and more thorough side-effect disclosure, but these are minor given the low complexity.
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 must compensate, and it does. The Args section explains collection_id as a UUID, name as the new optional name, and notebook_ids as the complete replacement list, adding real semantic meaning beyond types and defaults.
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 uses a specific verb ('Edit') and identifies the resource ('existing collection') plus the exact mutable aspects: name and list of notebooks. This clearly distinguishes it from collection_create, collection_delete, collection_list, and collection_set_emoji.
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 purpose implies when to use it: when an existing collection's name or notebook membership needs changing. However, it never explicitly contrasts it with siblings like collection_set_emoji or notebook_rename, nor gives any exclusions or conditions for choosing an 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?
No annotations provided, so description carries full burden. It discloses the toggle behavior and return values (public_link if enabled, None if disabled). It could mention that enabling makes the notebook publicly accessible, but the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a docstring-style format with Args and Returns sections. It is front-loaded and each sentence provides necessary information without 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?
Tool has output schema, so return details are optional. Description already covers returns. It is complete for a toggle tool, though no mention of prerequisites or side effects. With siblings, it stands alone well.
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 add meaning. It explains notebook_id as 'Notebook UUID' and is_public with default and effect. This adds value beyond the schema properties.
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 action: 'Enable or disable public link access.' This is a specific verb+resource that distinguishes it from sibling tools like notebook_share_status and notebook_share_invite.
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 (enable/disable public link) but lacks explicit guidance on alternatives or when not to use. Sibling tools exist for checking status or inviting by email, but no comparison is given.
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 mentions rate limits for all=True and describes the output format. However, it does not explicitly state that the tool is read-only or disclose other behavioral traits like error handling or synchronization.
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: a brief summary followed by an Args list. Every sentence adds value, with no fluff. It is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (unseen), the description covers the main aspects: query purpose, parameter options, and output format. It lacks details on error handling, authentication, or concurrency, but is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully document parameters. It describes all four parameters with examples (e.g., 'AI Research, Dev Tools') and their roles. It adds meaning beyond the schema types, though it omits explicit mention of defaults for notebook_names and tags.
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 'query', resource 'multiple notebooks', and output 'aggregated answers with per-notebook citations'. This distinguishes it from sibling 'notebook_query' which likely queries a single notebook.
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=True) and includes a caution for all=True about rate limits. However, it does not explicitly state when to use this tool versus alternatives like notebook_query, though it is implied.
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 discloses the mandatory 'confirm' parameter after user approval and explains the return structure. However, it could add details on error handling or partial failures.
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 well-structured with clear sections. It could be slightly more scannable, but it appropriately front-loads the 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, the description covers purpose, parameters, and return format. It could mention edge cases or idempotency, but is sufficient for correct 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 coverage is 0%, so the description must compensate—and does so fully. It explains each parameter: notebook_id as UUID, recipients as list of dicts with default role, and confirm as boolean requiring True. An example is provided.
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 verb (invite), resource (collaborators), and scope (batch). This distinguishes it from sibling tools like notebook_share_invite (single invite) and notebook_share_public.
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 batch invitation but does not explicitly contrast with alternatives or provide when-to-use guidance. It lacks exclusion criteria or mention of prerequisites.
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 full responsibility. It explicitly discloses that deletion is permanent and irreversible, and that confirm must be set after user approval, covering the most critical side effects. It does not mention potential cascading effects or partial failures in bulk operations, but it adequately warns about the destructive nature.
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, front-loaded with the core action and warnings, and includes a clear args section. No fluff or redundancy; every sentence adds 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?
Given the complexity (3 optional params, destructive operation) and the presence of an output schema, the description is reasonably complete. It covers the action, irreversibility, confirmation, and parameter meanings. It could mention success/failure semantics or atomicity for bulk operations, but these are not essential for a straightforward delete.
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 meaning beyond the schema by explaining source_id as a single UUID and source_ids as a list for bulk, including that they are alternatives. It also clarifies confirm's role. There is a slight inconsistency: schema allows source_ids to be a string or array, while description says 'List', which could confuse agents expecting only arrays. Overall, it significantly improves schema comprehension.
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 source(s) permanently' with a specific verb and resource, and adds the critical nuance of irreversibility. It distinguishes from sibling tools like source_add or source_rename by indicating a destructive action. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context by stating 'Requires confirm=True' and 'Must be True after user approval', which guides when it's safe to invoke. However, it does not explicitly mention alternatives or when-not-to-use scenarios, and while it's obvious this is for deletion, it lacks formal comparison to other source management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes the listing nature and skip_freshness parameter effect. Implies read-only (no mutation). Could explicitly state it's a read operation, but sufficient for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus parameter list. No unnecessary words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description need not detail return values. Covers purpose, usage, and parameter meaning adequately. Could elaborate on 'freshness status' but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Explains skip_freshness effectively ('skip per-source freshness checks for faster listing'). Description for notebook_id is minimal ('Notebook UUID'), repeating type but adding no context. Partially compensates.
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 lists sources with types and Drive freshness status, and explicitly links to source_sync_drive as a precursor. Differentiates from sibling tools by specifying its role in identifying stale 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?
Provides explicit usage: 'Use before source_sync_drive to identify stale sources.' This tells when to use. Does not mention when not to use, but the context and sibling tool list imply it's for listing only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns query result or current status, and mentions polling behavior. However, it lacks details on error handling, side effects, or rate limits. 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 and well-structured: a clear purpose statement, behavioral note, polling instruction, and args section. 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 presence of an output schema (not shown but indicated), the description adequately covers the tool's behavior. It explains return values (result or status) and polling usage. No gaps for a simple 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?
Only one parameter (query_id) with 0% schema description coverage. The description adds meaning by stating 'The query ID returned by notebook_query_start', linking it to the start tool. This compensates for the schema's lack of description.
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 'Check the status of an async notebook query started with notebook_query_start', specifying the resource (async notebook query) and action (check status). It distinguishes from sibling tools like notebook_query_start which initiates the 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?
Provides explicit polling guidance: 'Poll this tool every few seconds until status is 'completed' or 'error'.' This indicates when and how to use it after starting a query. No explicit alternatives or when-not, but the advice is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool reloads from disk and attempts re-authentication, and returns a status. However, it lacks details on side effects, failure modes, or what happens during re-authentication. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences: first states action, second and third provide usage context, fourth describes return. No unnecessary words, well 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 no parameters and only an output schema, the description covers purpose, use cases, and return value comprehensively. For a simple auth refresh tool, it provides sufficient context.
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, and schema description coverage is 100%. The description does not need to add parameter info. Baseline score of 4 applies as no parameter details are required.
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 action ('Reload auth tokens from disk or run headless re-authentication') and specifies distinct use cases (after `nlm login` or automatic re-authentication). It differentiates itself from sibling tools like `save_auth_tokens` by focusing on reloading and re-authentication.
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 states when to call the tool: 'Call this after running `nlm login` to pick up new tokens, or to attempt automatic re-authentication if Chrome profile has saved login.' Provides clear context, though no explicit when-not-to-use or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral clarity. It discloses that the summary is AI-generated and returns markdown with bold keywords, indicating a read-only, non-destructive operation. However, it does not explicitly state it is safe or mention any required 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, with a one-line purpose followed by labeled Args and Returns sections. Every sentence is informative, and the structure is front-loaded, allowing quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description adequately covers the key aspects: what it does, its input, and its return type. It could mention that it's read-only, but that is inferred from 'Get'. Overall, it is sufficient for a single-purpose describe 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?
The description adds semantic value to the single parameter 'source_id' by explaining it is a 'Source UUID', which goes beyond the schema's mere 'type: string'. Since schema coverage is 0%, this context is essential and well-provided.
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 source summary with keyword chips', specifying the verb 'Get' and the resource 'source summary'. This distinguishes it from sibling tools like 'source_add' or 'source_delete', which are for adding or deleting sources.
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 usage when needing a source summary, but it does not explicitly state when to use or avoid this tool compared to alternatives. It provides no exclusions or alternative tool suggestions, relying on the tool name for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses an important behavioral requirement: 'Requires confirm=True' and clarifies that it must be set after user approval, implying the operation has side effects. It also hints at the sync behavior via 'latest content' and the prerequisite workflow, but could be more explicit about what synchronizing does (e.g., overwrite local data or pull from Drive).
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. It leads with the purpose, then the requirement, a prerequisite, and an Args list. Every sentence earns its place, with no redundancy or filler.
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 only 2 parameters, one required, and an output schema, the description is fairly complete. It covers purpose, prerequisites, parameter meanings, and a safety requirement. The only minor gap is lack of explicit clarification on what happens during sync (e.g., whether it is incremental or overwriting), but the output schema likely covers return values, so the description is sufficient.
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%, so the description must compensate. The Args section adds meaning: 'source_ids: Source UUIDs to sync' and 'confirm: Must be True after user approval.' This goes beyond the raw schema types, explaining what each parameter is for and the constraint on confirm, though it could provide more detail on edge cases or formats.
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 action: 'Sync Drive sources with latest content.' This is a specific verb ('sync') and resource ('Drive sources'), distinguishing it from sibling tools like 'source_list_drive' (which lists sources) and 'source_delete' (which deletes).
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 gives a concrete usage guideline: 'Call source_list_drive first to identify stale sources.' This implies the tool should be used after listing and identifies a prerequisite. It could be stronger if it explicitly stated when not to use it or named an alternative, but it provides clear workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It discloses the restriction to existing sources, the timeout budget behavior, and conversation handling. It does not mention authentication or side effects, but since the tool appears read-only and the description conveys that, it 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the primary purpose and a clear exclusion, then a compact Args list. It wastes no words while covering all parameters.
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?
With 6 parameters incl. optional ones, the description provides defaults, environment fallback, and usage notes. Output schema exists (per context) so return values need not be described. Comprehensive enough for an agent to operate without further lookup.
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 shows 6 params and 0% description coverage, but the description explains all six parameters: notebook_id, query, source_ids (default all), conversation_id (follow-up), timeout (default from env or 120, 180+ recommendation), and new_conversation. That adds significant meaning beyond the raw 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?
Description opens with 'Ask AI about EXISTING sources already in notebook' – a specific verb and resource. It immediately excludes the alternative use case ('NOT for finding new sources') and names the sibling tool (research_start) that handles that. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (ask AI about existing notebook sources) and when not to (finding new sources), and points to the alternative tool. Clear contextual cues for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the asynchronous nature, immediate return of a query_id, the need to poll status, and the timeout budget. It could additionally mention failure modes or whether starting a query mutates conversation state, but the core behavior is well covered.
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 front-loaded with purpose and usage, followed by a compact workflow line and an Args block. It is slightly repetitive around the 120-second/180-second timeout guidance, but every sentence contributes useful information and the structure is easy to scan.
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 six-parameter asynchronous tool with no annotations, the description covers the essential workflow, timeout behavior, and parameter meanings. An output schema exists, so the return shape need not be repeated. It stops short of explaining status semantics or error/timeout outcomes, but the explicit polling workflow mitigates that 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 description coverage is 0%, so the description must compensate, and it largely does: all six parameters are named with semantic explanations and defaults, such as 'source_ids: Source IDs to query (default: all)' and 'timeout: Wall-clock query budget in seconds'. Minor ambiguities remain around new_conversation and conversation_id interaction, but the description adds substantial 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 opens with a specific verb and resource: 'Start a notebook query asynchronously.' It clearly distinguishes itself from notebook_query by framing this as the variant for source-heavy notebooks or long questions, so an agent can identify the tool's role among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to choose this tool: 'Use this instead of notebook_query when the response may take longer than the default 120-second budget.' It also provides the follow-up workflow, 'notebook_query_start -> poll notebook_query_status until completed', which is direct, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses mode duration and source counts (fast ~30s, ~10 sources; deep ~5min, ~40 sources, web only), and explains that notebook_id creates a new notebook if omitted. It does not mention authentication, rate limits, or whether the operation is read-only, but the creation aspect 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, usage examples, workflow, and parameter list. It is front-loaded with purpose. The Args section is clear but could be slightly tighter; however, it avoids unnecessary verbosity.
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 (not shown but known), the description does not need to explain return values. It covers inputs, workflow, approximate outcomes, and the polling/import sequence, providing a complete picture for an agent.
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 parameters. It does so in the Args section, providing meanings for query, source, mode (with durations and source counts), notebook_id (optional, creates new), and title. This adds substantial value beyond the schema's default values and 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?
The description clearly states the tool's purpose: 'Search web or Google Drive to FIND NEW sources.' It provides example use cases ('deep research on X', 'find sources about Y') and distinguishes 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 lists explicit usage scenarios ('Use this for...') and the workflow implies when to use this tool versus research_status or research_import. However, it does not explicitly state when not to use this tool or provide alternative tools beyond the workflow chain.
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 discloses blocking behavior, polling intervals, timeout, compact mode, and the auto_import side effect. It is transparent about key behavioral traits.
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 front-loaded with the core purpose, then lists parameters clearly. It is not overly long, though the contributor credit is unnecessary but minor. Well-structured for quick parsing.
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 (7 params) and no annotations, the description covers all necessary details: blocking, polling, compact, auto_import interaction, and fallback matching. An output schema exists, so return value detail is not required.
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 explains all 7 parameters (notebook_id, poll_interval, max_wait, compact, task_id, query, auto_import) with clear meanings and defaults, fully compensating for the lack of 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 'Poll research progress. Blocks until complete or timeout.' This is a specific verb+resource combination that distinguishes it from siblings like research_start, research_import, and notebook_query_status.
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?
While no explicit when-to-use/alternatives are given, the description implies usage for synchronous waiting and provides context for optional parameters like task_id and query, helping the agent understand its role in the research workflow.
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 fallback nature, deprecation, and auto-extraction but does not detail side effects (e.g., file writing, overwriting) or permissions needed, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and front-loaded purpose. Some redundancy (e.g., 'IMPORTANT FOR AI ASSISTANTS') but no wasted words.
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 output schema exists and annotations are absent, the description covers all parameters, usage logic, and alternatives, making it complete for a fallback authentication 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?
Schema coverage is 0%, but the description adds detailed meaning: cookies source, deprecation, auto-extraction, and manual extraction conditions. This fully compensates 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?
The description clearly states it saves NotebookLM cookies as a fallback method. It distinguishes from the preferred 'nlm login' command, making the purpose and context explicit.
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 instructs to try 'nlm login' first and only use this tool if CLI fails. Also notes deprecated parameters, guiding proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details behavior: status returns artifacts with statuses, rename modifies title, list_types shows supported types. It covers pagination and include_details impact. It does not mention auth or rate limits but is sufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized with bullet points and sections for actions, parameters, and return values. It is front-loaded with the main purpose and avoids redundancy. Minor improvements could trim some detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 3 actions, pagination, return structure), the description is comprehensive. It documents the output dictionary with fields and details, compensating for the lack of an output schema. No gaps are apparent.
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 by explaining each parameter's role, dependencies (e.g., artifact_id required for rename), defaults, and constraints (e.g., limit 1-100). It provides critical semantic 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 clearly states the tool's purpose: 'Check studio content generation status and get URLs, or rename an artifact.' It uses specific verbs and resources, distinguishing from sibling tools like studio_create 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 outlines three actions (status, rename, list_types) with clear conditions for each. It doesn't explicitly compare to siblings, but the actions are self-contained and context is implied via sibling tool names.
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 behavioral burden and does well by disclosing partial-failure handling, skipped in-progress/failed artifacts, failure isolation across items, and path restrictions. It does not explicitly state whether existing files are overwritten when skip_existing=False, which is a relevant side-effect for a file-writing tool, so it loses a point.
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 appropriately detailed for a 7-parameter tool, with a clear opening summary, an Args section that mirrors the schema, a Returns summary, and two examples. Every sentence contributes useful information, and the structure is easy to scan. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, multi-mode download tool with no annotations, the description covers all important aspects: scope selection, directory creation, extension mapping, failure behavior, parameter constraints, and return shape. The examples clarify realistic usage. There is no meaningful gap an agent would need to guess about before calling it.
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 fully documents all 7 parameters with meaningful details: notebook_id vs all_notebooks, output_dir semantics, artifact_types, output_format scoping, slide_deck_format selection, and skip_existing behavior. It even includes examples of default file extensions. This fully compensates for the absent 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 opens with a specific verb and resource: 'Download all completed studio artifacts of one notebook — or every notebook.' It clearly distinguishes from the singular sibling download_artifact by emphasizing the bulk scope, and explains the output structure. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use context: use a single notebook_id or sweep with all_notebooks, restrict artifact types, and use skip_existing for incremental runs. It even references download_artifact for path-refusal details. It could more explicitly say 'for downloading a single artifact, use download_artifact instead,' but the contrast with the sibling is otherwise clear from the name and scope.
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 full burden, detailing behaviors like destructive actions ('delete permanently'), required confirmations, and preconditions (5+ sources). However, it omits some aspects like error behavior 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?
The description is well-structured with a summary, enumerated actions, parameter details, and multiple examples. Every sentence adds value, and the most critical information 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 9 parameters, no annotations, and an output schema, the description covers all actions, parameter requirements, preconditions, and examples, making it complete for an agent to select and invoke the tool 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 coverage is 0%, but the description adds rich meaning for all parameters, listing valid actions, required fields per action, and examples, fully compensating for the lack of 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 the tool's purpose as 'Manage source labels in a notebook' and emphasizes it's a 'Unified tool for all label operations,' distinguishing it from siblings like 'tag' by covering all label-related actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed usage for each action (e.g., 'requires 5+ sources for auto-labeling', 'confirm=True needed for delete'), but does not explicitly mention when to use alternative sibling tools or exclude them.
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 discloses that delete is permanent and requires confirm=True, and describes parameter dependencies per action. It does not cover rate limits or auth, but is otherwise 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 concise, well-structured with bullet points, and includes four clear examples. 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 (6 parameters, 4 actions) and the presence of an output schema, the description provides all necessary context: parameter details, action-specific requirements, and concrete examples. No gaps remain.
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 thoroughly explains each parameter, including required conditions, defaults, and valid actions. This fully compensates for the lack of 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 it is a unified tool for all note operations, listing create, list, update, delete. It distinguishes from sibling tools by focusing specifically on notes within a notebook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly covers all note operations and provides examples, but does not explicitly state when not to use it or mention sibling tools for comparison. However, it is clear enough for an agent to understand its scope.
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 behavioral disclosure burden. It discloses meaningful runtime behavior: source_indices defaults to all, timeout defaults to 300 and should be increased for large notebooks, and cited_only overrides source_indices. It does not describe side effects, error conditions, or whether imports are idempotent, but the covered behavior is genuinely useful.
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 short, front-loaded with the primary purpose, and then structured with a precondition and a compact Args block. Every sentence adds relevant workflow or parameter information, with no filler.
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 5-parameter tool with no schema descriptions and no annotations, the description is complete for invocation: it supplies the required workflow state, all argument meanings, the default behavior, and customization guidance. The presence of an output schema means return value details do not need to be duplicated here.
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 provides 0% parameter descriptions, so the description must fully compensate. It does: every parameter is explained, including notebook_id, task_id, source_indices semantics, timeout guidance, and cited_only override behavior. This makes the entire parameter surface safely invocable.
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 opens with a specific verb and resource: 'Import discovered sources into notebook.' This clearly differentiates it from siblings like research_status, source_add, and notebook_* tools by tying it to the research workflow and notebook destination.
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 gives an explicit precondition: 'Call after research_status shows status=completed.' It also explains when cited_only should be used. It does not name an alternative tool or exclude other cases, so the guidance is clear but not as strong as an explicit when-not/alternative comparison.
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 carries the full burden and does so excellently. It discloses the 30-second TTL caching, mtime-based bypass, up-to-30-second staleness, semantics for each auth_status value, and the meaning of latest_version being None. This is far more transparent than typical descriptions.
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 lengthy but well-structured, with a clear opening sentence and distinct sections for auth_status and return fields. Every sentence adds necessary detail, though some trimming of the auth_status explanation could make it tighter without losing 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?
The description leaves little ambiguous: it documents all return fields, explains each auth_status value with failure modes, covers caching behavior, and gives user-facing instructions. The output schema exists but the description goes beyond it, making the tool fully understandable.
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 tool accepts no parameters, so there are no parameter semantics to clarify. The description appropriately focuses on the return payload and status meanings. The baseline of 4 applies because no parameter documentation is needed.
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: 'Get version, auth status, and conservative MCP capability visibility.' It uses a specific verb and resource, and is distinct from sibling tools like refresh_auth or save_auth_tokens, which handle authentication actions rather than status reporting.
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 actionable guidance for AI assistants, such as what to do when update_available is True, and thoroughly explains auth_status interpretations. It does not explicitly contrast with sibling tools or state when to prefer this tool, but the context clues are strong enough for a status-only 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?
With no annotations, the description carries the full burden. It discloses that confirm must be True after user approval, that source_ids defaults to all sources, and that language falls back to NOTEBOOKLM_HL env var or 'en'. It also notes constraints like visual_style not allowed for cinematic/short. It does not mention async behavior or how to monitor progress, but for a creation tool it provides meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but justifiably so for a 22-parameter polymorphic tool. It is front-loaded with the main purpose, then uses headings, bullet lists, and examples to organize information efficiently. No unneeded sentences – every section 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?
All 22 schema parameters are accounted for in the description, and it adds enums, constraints, and defaults. The presence of an output schema means return-value documentation can be external. The description also includes practical examples, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 is the sole source of parameter meaning. It explains every parameter, including artifact_type with nine enumerated values and type-specific sub-options (audio_format, video_format, orientation, etc.), which goes far beyond the schema's raw defaults and anyOf 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?
The description opens with 'Create any NotebookLM studio artifact' – a clear verb and resource. It then lists all supported artifact types (audio, video, infographic, etc.), making its scope explicit and distinguishing it from siblings 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?
It is described as a 'Unified creation tool', which clearly signals when to use it for artifact creation. The examples demonstrate valid calls. However, it does not explicitly mention alternatives for revision (e.g., studio_revise) or when not to use this tool, leaving a slight gap in exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals key behavioral traits: creates a new artifact (original unchanged), asynchronous (poll studio_status), requires confirmation (confirm=True). The existence of an output schema compensates for missing return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with an Args section and example. Every sentence provides useful information without redundancy. It is appropriately front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values. It covers purpose, parameter details, usage flow (async polling, confirmation), and constraints (only slide decks). It is complete for a revision 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?
The input schema has 0% description coverage, but the description explains each parameter thoroughly, especially slide_instructions with structure, examples, and the confirm parameter's semantics. 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 action ('Revise individual slides') and the resource ('existing slide deck'). It distinguishes from siblings like studio_create and studio_status by emphasizing that it creates a new artifact and requires polling. The verb and resource 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: only slide decks support revision, and users should poll studio_status after calling. It does not explicitly state when not to use it, but the context and siblings imply it is the appropriate tool for revisions.
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?
No annotations are provided, but the description explicitly declares 'IRREVERSIBLE' and notes the confirm parameter requirement, fully disclosing the destructive nature.
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 efficient, but could be slightly more structured (e.g., separate sections). However, it is clear and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool, the description covers all essential aspects: action, irreversibility, required parameter confirmation. Output schema exists, so return value explanation is not needed.
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%, yet the description adds crucial meaning: notebook_id is a UUID, confirm must be True after user approval. This compensates for the schema's lack of 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 uses a specific verb ('Delete') and resource ('notebook'), clearly indicating permanent deletion. It distinguishes from sibling tools like notebook_rename and 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 states the requirement for confirm=True and user approval. While it does not explicitly compare to alternatives, the action is unambiguous and guidelines are implied.
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 provided, the description carries the full burden of behavioral disclosure and meets it admirably. It discloses that admission does not guarantee provider processing success, notes that file paths are relative to the MCP server machine, explains the impact of the 'wait' parameter, and mentions that image sources may feed video generation pipelines. These details go beyond simple parameter lists.
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 a synopsis, parameter list, and examples, making it easy to scan. However, the omission of the 43 file extensions (or moving them to an external reference) would improve conciseness without losing critical operational detail. The structure itself is strong, but the length borders on excessive for an MCP tool description.
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 high complexity (11 parameters, 4 source types, async behavior), the description is remarkably complete. It covers edge cases like bulk uploads, server-side file paths, wait timeouts, and provider processing caveats. Since an output schema exists in the structured data, the omission of return value details is acceptable, and the description fully supports the agent in a wide range of usage 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 fully compensate, which it does. Every parameter is documented with its purpose, allowed values (like source_type options), and behavioral implications (e.g., url vs urls mutual exclusivity, file_path accessibility, wait_timeout default). The examples further illustrate parameter usage in context, making the schema far more usable.
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 opens with 'Add a source to a notebook. Unified tool for all source types,' which uses a specific verb and resource while clearly stating its role as the consolidated tool. This differentiates it from specialized sibling tools like source_delete, source_rename, and source_describe, which are all listed alongside it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context for each source type (url, text, drive, file) and includes multiple examples demonstrating single vs bulk URLs, wait behavior, and file usage. It implicitly excludes non-add operations, though it does not explicitly name alternative tools for other operations. The guidance that 'a path on a different client/agent host is not accessible' is a valuable caveat.
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 critical behavior: 'IRREVERSIBLE' and 'Requires confirm=True.' With no annotations, the description fully informs the agent about the destructive nature and confirmation requirement.
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 and well-structured: a brief header with warning, followed by a bulleted list of arguments. No superfluous text; every sentence adds 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?
Covers purpose, usage, parameters, and behavioral traits adequately. An output schema exists, so return values are not needed. Could mention prerequisites like user permissions, but overall complete for a delete 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?
Schema description coverage is 0%, but the description provides detailed explanations for each parameter: notebook_id is Notebook UUID, artifact_id is Artifact UUID (from studio_status), and confirm must be True after user approval.
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 'Delete studio artifact' using a specific verb and resource. It distinguishes from siblings like notebook_delete and source_delete by specifying 'studio artifact.'
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?
Provides clear guidance: it warns of irreversibility and requires confirm=True. It also references artifact_id from studio_status. However, it lacks explicit when-not-to-use or comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden and delivers: downloads are sandboxed to the download directory and outside paths are refused; default location (~/Downloads/gemini-notebook) and NOTEBOOKLM_DOWNLOAD_DIR override are disclosed; polling semantics (wait, wait_timeout, poll_interval) are explained; and artifact_id falls back to 'latest' when omitted. This is far more than the schema or annotations reveal.
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 one-sentence purpose is front-loaded, followed by a positioning statement and a compact type list. The Args block is organized per-parameter with defaults and formats, and the Returns line plus three varied examples close it out. For a 9-parameter tool with no schema descriptions, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Every one of the 9 parameters is documented with defaults, allowed values, and behavioral notes; the path-confinement constraint and polling knobs are covered; and since an output schema exists, the brief 'Returns: dict with status and saved file path' suffices. Nothing an agent needs to invoke this complex tool correctly is missing.
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 — and it does comprehensively. artifact_type maps each value to its format (audio→MP4/MP3, report→Markdown, etc.), output_path explains relative pathing and confinement, output_format and slide_deck_format get explicit value lists and defaults, and every optional parameter's behavior is described. Three usage examples ground the semantics concretely.
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?
Opens with a specific verb+resource: 'Download any NotebookLM artifact to a file.' The next sentence, 'Unified download tool replacing 9 separate download tools,' explicitly positions it against the per-type download tools an agent might otherwise reach for. The full artifact-type list removes any ambiguity about scope.
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?
'Unified download tool replacing 9 separate download tools. Supports all artifact types' gives clear context that this is the single entry point for downloading any one artifact. However, it does not explicitly say when to prefer the sibling download_all_artifacts or export_artifact, so the when-not-to-use guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns raw indexed text, the wait/polling behavior, and the returned fields. However, it does not mention potential errors (e.g., source not found) or other edge cases, so it's 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 concise and well-structured, leading with the main purpose, then explains returns and provides a flat Args list. Every sentence adds value with no unnecessary filler.
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 the core action, parameter meaning, return values, and usage context. Given the tool's moderate complexity and lack of annotations, this is sufficient for an agent to select and correctly invoke the tool. The output schema (though not shown) is complemented by the Returns section.
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: source_id as UUID, wait as polling activation, wait_timeout as max seconds, and poll_interval as check frequency. It also documents return fields, making parameter semantics 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 identifies the tool's purpose: 'Get raw text content of a source (no AI processing).' It specifies the resource (source) and the action (get content), and distinguishes itself from notebook_query by noting it's faster for content export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('for content export') and contrasts it with an alternative ('Much faster than notebook_query'). It also clarifies that no AI processing is involved, helping the agent choose between this and other query tools.
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:

[![gemini-notebook-mcp-cli MCP server](https://glama.ai/mcp/servers/jacob-bd/gemini-notebook-mcp-cli/badges/card.svg)](https://glama.ai/mcp/servers/jacob-bd/gemini-notebook-mcp-cli)

Score Badge

Copy to your README.md:

[![gemini-notebook-mcp-cli MCP server](https://glama.ai/mcp/servers/jacob-bd/gemini-notebook-mcp-cli/badges/score.svg)](https://glama.ai/mcp/servers/jacob-bd/gemini-notebook-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/jacob-bd/gemini-notebook-mcp-cli'

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