notebooklm-mcp
Server Quality Checklist
Latest release: v0.9.12
- Disambiguation3/5
The query family is genuinely ambiguous at the edges: notebook_query, notebook_query_start/status, cross_notebook_query, and batch with action=query all serve near-identical user intents and require reading detailed descriptions to distinguish. Similarly, refresh_auth and save_auth_tokens overlap on re-authentication, and notebook_get vs note/list (chats) vs source listings can confuse as to which 'list' you get. That said, the documentation is unusually clear about when to use each, and the core resource tools (notebooks, sources, studio artifacts) are cleanly separated.
Naming Consistency4/5The tool surface overwhelmingly follows consistent snake_case verb_noun naming (notebook_create, source_delete, studio_status, research_start). Minor inconsistencies exist: source_add vs notebook_create use different verbs for the same concept, the low-level 'note'/'tag'/'label'/'batch' tools break the prefix convention, and notebook_query_start/status use a suffix pattern that could be confused with action-dispatch tools. Overall highly predictable and readable despite these deviations.
Tool Count2/5At 43 tools, this is a heavy surface for an agent to keep in context, landing in the 'too many for the apparent scope' territory even though NotebookLM is a large product. The server already senses this by compressing features into action= dispatchers (note, label, tag, batch, pipeline) while still exposing 43 top-level entries. A more aggressive split—like making the action managers first-class tools or consolidating the query family—would likely reduce cognitive overhead substantially.
Completeness4/5Coverage is exceptionally thorough: full CRUD on notebooks and sources, an end-to-end research workflow (start/status/import), studio artifact lifecycle (create/status/revise/delete/download/export), chat history, sharing, Drive sync, tagging, and pipelines. Minor gaps exist (no note deletion or chat deletion tool, and some flows like pipeline are thin), but the domain is comprehensively served with no obvious dead ends.
Average 4.1/5 across 42 of 43 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 120 of 121 community issues answered or closed in the last 6 months
- 154 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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?
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/5Is 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/5Given 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/5Does 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/5Does 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. 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/5Is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It clarifies the scope ('EXISTING sources'), the exclusion of new-source search, and parameter defaults, but does not disclose whether the operation is synchronous, how long it may block, or what happens with follow-up conversation state beyond the new_conversation flag. This is adequate but not deeply 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear purpose statement, a one-line exclusion, an alternative-tool pointer, and a concise argument list. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and an output schema, and the description covers the main use case, exclusions, alternatives, and parameter behavior. It is slightly incomplete because it does not mention asynchronous alternatives like notebook_query_start/status, but overall it is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the bare schema: source_ids 'default: all', conversation_id is 'For follow-up questions', timeout uses an environment variable default, and new_conversation 'Start a fresh conversation when conversation_id is omitted.' This compensates well for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Ask AI about EXISTING sources already in notebook' and explicitly contrasts with 'NOT for finding new sources.' This provides a specific verb, resource, and scope, and distinguishes the tool from research_start and related query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage guidance: 'Use research_start instead for: deep research, web search, find new sources, Drive search.' This tells the agent not only when to use notebook_query but also which sibling tool to use for alternative tasks.
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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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?
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/5Is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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?
With no annotations, the description carries the transparency burden. It explains optional artifact_id falls back to latest, and the wait/poll parameters reveal propagation delays. It also states the return type. It does not cover permissions or error scenarios, but for a download tool this is reasonably 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though detailed, every sentence adds value. It is structured with a short summary, a parameter list with descriptions, a return note, and three representative examples. The information density is high without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, an output schema, and no annotations, so the description must cover a lot. It does: explains all parameters, return values, and provides usage examples covering different artifact types and formats. This is a complete and self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully compensate. It does: every parameter is explained with allowed values, defaults, and interplay (e.g., 'For quiz/flashcards only' for output_format). Examples show valid parameter combinations, going well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Download any NotebookLM artifact to a file.' It clearly enumerates supported artifact types and notes it is a 'unified download tool replacing 9 separate download tools,' which distinguishes it from more narrowly scoped alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it is the unified replacement for separate download tools, and it gives format-specific parameters (e.g., output_format for quiz/flashcards, slide_deck_format for slide_deck). However, it does not explicitly differentiate from sibling tools like download_all_artifacts or export_artifact, so a brief 'when not to use' statement would make it stronger.
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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to 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/5Does 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/5Does 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/5Does 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 provided, but the description fully discloses behaviors: subdirectory creation, naming conventions, default extensions, skipping unfinished/failed artifacts, and non-blocking failure per artifact. Also explains return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with bullet points and examples. Every sentence adds value, though minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and an output schema, the description covers all necessary aspects: argument details, behavior, return format, and examples. Sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explains all 7 parameters with defaults, types, and examples (e.g., notebook_id, artifact_types, output_format). Fully compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it downloads all completed studio artifacts from one or all notebooks, distinguishing it from sibling tools like download_artifact (single artifact) and export_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use (download all artifacts from specific notebook or all notebooks) and mentions skipped artifacts. Implicitly distinguishes from single artifact download, but lacks explicit 'when not to use' or 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?
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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It explains that the query runs asynchronously, returns immediately with a query_id, requires polling, and includes timeout defaults. It doesn't cover error conditions or resource implications, but the core async behavior and lifecycle are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with an intro, usage comparison, workflow arrow, and parameter list. Every sentence/line adds necessary information without redundancy or filler. It is appropriately sized for a tool with this many parameters and an async workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is async, has 6 parameters, no annotations, but has an output schema. The description covers the async workflow, when to use it, polling, defaults, and parameter semantics. This is complete enough for an agent to select and invoke the tool correctly without additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. Every parameter has a meaningful one-line explanation: notebook_id as UUID, source_ids defaulting to all, conversation_id for follow-ups, timeout defaulting from env, and new_conversation behavior. This adds substantial semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a notebook query asynchronously for large notebooks that may timeout. It explicitly distinguishes this from notebook_query by naming the alternative and specifying the 50+ source threshold and 60-second risk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this instead of notebook_query when querying notebooks with many sources (50+)' and provides the recommended workflow: notebook_query_start -> poll notebook_query_status. This is strong situational 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 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jacob-bd/gemini-notebook-mcp-cli'
If you have feedback or need assistance with the MCP directory API, please join our Discord server