NotebookLM

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate idempotentHint=true and destructiveHint=false. Description adds context about permanent vs session behavior, explaining that config token is non-expiring and session token is temporary. This goes beyond annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single dense paragraph that front-loads the context ('MCP.AI for IDE agents') and efficiently covers both methods. Every sentence adds value, though it could be slightly restructured for easier scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an authentication tool with no output schema, the description covers the main flows (config token and session token) and mentions the login link. Missing details on error handling or token validation are minor; overall it provides sufficient context for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has one optional parameter 'token' with 0% description coverage. Description explains that token is a JWT from browser login, and clarifies its usage depending on the authentication method. This 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is for authentication for IDE agents, specifying two distinct methods (config token or session paste). It effectively distinguishes this tool as the primary authentication mechanism among siblings, which include unrelated tools like notebookLM operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage scenarios: best to add token to config for permanent connection, or paste token for session-only. Clearly states when to call with token argument (after user pastes) or with no args (to get login link). No ambiguity about when to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the output structure (authenticated boolean, pending array, connect_url) and conditional behavior, which is beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently convey the tool's purpose and conditional behavior. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and annotations covering safety, the description fully explains the return values and states. It is complete for a status-check tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in input schema, so baseline is 4. The description does not need to add parameter details; it correctly focuses on functionality.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns connection status and URLs, with specific behavior for 'all providers connected' vs 'credentials missing'. It uses a specific verb+resource and distinguishes from siblings like 'authenticate'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking connection status, but does not explicitly state when to use versus alternatives (e.g., authenticate). No exclusions or when-not guidance provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses that writes require workspace owner/admin, indicating authorization constraints. It also mentions search result flags (installed vs available) and provides context for each action. However, it does not detail side effects or error conditions for write operations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph but is well-structured with purpose first, then action-by-action breakdown. It is concise for the amount of information, though a bulleted list could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (13 parameters, no output schema), the description adequately covers the tool's purpose and main actions but omits details on return values and parameter formats. This leaves gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 13 parameters and 0% schema description coverage, the description fails to explain individual parameters like 'limit', 'arguments', 'immediate', etc. It only implicitly covers 'action' and 'query' through action descriptions. This leaves agents unable to correctly set many parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as 'THE official mcp.ai marketplace' for discovering and managing MCPs. It specifies the resource (marketplace catalog) and action (managing MCPs), and distinguishes it from external registries or sibling tools like notebooklm_*.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to use this tool (action=search) FIRST before external registries. It details when to use each action (e.g., describe for profiling, install/uninstall for management, list_tools/invoke after install) and mentions that writes require admin. This provides clear when-to-use and when-not-to guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description claims the tool deletes an artifact, which implies destructive behavior, but the annotation destructiveHint=false contradicts this. This is a serious inconsistency that misleads the agent about the tool's safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (two sentences) and front-loaded, but it is in Portuguese, which may reduce readability for some agents. It could be more concise in English. Still, it earns its place by stating the core action and bulk support.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, 4 parameters, and no behavioral annotations beyond the contradictory destructiveHint, the description fails to explain return values, error conditions, permissions, or side effects. It is insufficient for an agent to reliably use this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It mentions bulk support with notebook_ids and artifact_ids, but does not explain the relationship between singular and plural parameters, nor clarify when each is appropriate. The required fields artifact_id and notebook_id are not elaborated on.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Apaga' (deletes) and the object 'artifact', distinguishing it from sibling tools like notebooklm_artifact_get or notebooklm_notebook_delete. However, it does not define what an artifact is, which may cause ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives (e.g., notebooklm_artifact_rename or notebooklm_notebook_delete). There is no mention of prerequisites, consequences, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and idempotent behavior. The description adds value by disclosing bulk execution capability, which is not inferable from annotations or schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, front-loading the purpose. Every word adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description omits details about return format (single vs multiple results) and any error conditions. Since no output schema exists, more context would be needed for full agent autonomy.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description partially compensates by noting batch parameters (artifact_ids, notebook_ids), but it does not explain the required singular parameters (artifact_id, notebook_id) or their relationship to bulk parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves details/status of an artifact, distinguishing it from sibling tools like list or delete. However, the use of Portuguese ('Detalhes/status') may reduce clarity for some agents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for getting artifact details and mentions bulk support, but it does not explicitly compare with alternatives like notebooklm_artifact_list or provide when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, consistent with listing. Description adds bulk batch behavior and parameter details, providing transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two succinct sentences: first explains core purpose and filtering, second notes bulk support. No wasted words; information is front-loaded and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, filtering, and bulk. Lacks details about return format (e.g., what fields each artifact object contains) and behavior when both `notebook_id` and `notebook_ids` are provided. Adequate but missing context for a fully autonomous agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, description adds meaning: enumerates valid values for `type` (audio, video, etc.) and explains `notebook_ids` for bulk. Does not fully detail `notebook_id` vs `notebook_ids` relationship, but compensates significantly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists artifacts for a notebook ('Lista os artifacts do notebook'), identifies filtering by type with specific values, and mentions bulk support. Differentiates from siblings like notebooklm_artifact_get (single) and notebooklm_artifact_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on using the `type` filter with enumerated values and notes bulk execution via `notebook_ids`. Does not explicitly exclude alternatives, but context is clear: use to list artifacts with optional filtering or batch retrieval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description is not burdened to repeat them. The description adds value by naming the operation as polling (idempotent and safe) and introducing bulk support. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two succinct, front-loaded sentences with zero wasted words. The bulk support note is efficiently appended. This is textbook conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple poll tool with strong annotations and no output schema, the description covers the essential purpose and bulk feature. It could be slightly more complete by explicitly linking to generation initiation (e.g., 'after notebooklm_generate'), but overall it provides sufficient context for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description should compensate but only notes that 'notebook_ids' and 'task_ids' enable batched execution. It does not explain the singular required parameters ('notebook_id', 'task_id') or their roles. Parameter names are self-explanatory to some extent, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'aguarda/consulta o status de uma geração de artifact' (waits/checks status of artifact generation). This conveys a specific verb and resource, distinguishing it from siblings like 'notebooklm_artifact_get' (which likely retrieves the final artifact) and 'notebooklm_generate' (which initiates generation). However, it could explicitly mention that it is for asynchronous generation polling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after initiating artifact generation to check status, and mentions bulk support. However, it does not explicitly state when to use versus alternatives (e.g., 'notebooklm_artifact_get' for final results, 'notebooklm_artifact_retry' for failed tasks). No when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are minimal (readOnlyHint=false, destructiveHint=false). The description adds the bulk support behavior, which is useful context beyond annotations. However, it doesn't disclose side effects, atomicity, or what happens if the title already exists. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. The first sentence states the core purpose, and the second adds a key feature (bulk support). No unnecessary words. Front-loaded effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple rename tool, the description covers the basic action and bulk capability. However, it lacks details on return values, error handling, or the scope of renaming. With no output schema and 0% parameter coverage, more explanation would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the description does not explain any parameter semantics. The bulk support mention hints at the array parameters (artifact_ids, notebook_ids) but doesn't link them or clarify required vs optional usage. With 5 parameters and no additional info, this is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Renomeia um artifact' (renames an artifact), providing a specific verb and resource. The bulk support mention adds clarity, but it doesn't explicitly differentiate from sibling tools like notebooklm_note_rename or notebooklm_artifact_get, though the name implies the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description briefly mentions bulk support for batched execution but provides no guidance on when to use this tool versus alternatives (e.g., notebooklm_note_rename) or when not to use it. No pros/cons or context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide no hints (all false), so the description carries the full burden. It only says 'retry' without disclosing side effects, idempotency, rate limits, or what happens on success/failure. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences covering main purpose and bulk support. Concise, but the bulk sentence could be clearer. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters, no output schema, and no annotations, the description is incomplete. It lacks information on return values, error handling, and proper usage of bulk parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, requiring description to explain parameters. It mentions bulk arrays but does not clarify the relationship between required single IDs and optional arrays, or whether they are exclusive. No parameter descriptions exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it retries the generation of a failed artifact, using the specific verb 'retry' and resource 'artifact'. It clearly distinguishes from sibling tools focused on other operations like delete, get, list, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions bulk support with arrays but provides no guidance on when to use this tool versus alternatives (e.g., notebooklm_generate or notebooklm_artifact_poll). No exclusions or conditions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already define readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds the batched execution capability, which is not in annotations, but does not disclose other behaviors like response format or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief with two sentences, front-loading the main purpose. However, it is overly sparse and misses important details, but it is not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and the presence of many sibling tools, the description is incomplete. It does not describe return values, error behavior, or how to interpret suggestions. Annotations provide safety info but the description lacks depth.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no details about the parameters. It only mentions 'notebook_ids' for bulk, but does not explain the meaning or constraints of notebook_id or the array items.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Sugestões de artifacts para o notebook' which clearly indicates the tool suggests artifacts for notebooks. The purpose is specific and unique among sibling tools, but it does not explicitly contrast with similar tools like notebooklm_artifact_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'Bulk support: accepts notebook_ids for batched execution', which hints at when to use batch mode, but it does not explain when to use this tool over alternatives like notebooklm_artifact_list or notebooklm_artifact_get.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive. The description adds that responses are grounded with citations and may take time, plus bulk execution support. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise with two sentences, front-loading the primary behavior and citations. Could be slightly more structured but no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate but missing context like prerequisites (e.g., need sources loaded) and detailed return format. Output schema absent but description hints at cited responses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description must compensate but only mentions 'notebook_ids' for bulk support. It does not explain 'question' or 'notebook_id' beyond their names, insufficient for providing parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: asking the notebook and receiving grounded answers with citations. This distinguishes it from sibling tools like 'notebooklm_generate' (generation) and 'notebooklm_history' (history).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for question-answering but does not explicitly state when to use versus alternatives. It mentions bulk support for batched execution, but lacks exclusions or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (read-only, idempotent), the description adds that text types return inline content, binary types return metadata+size, and URL delivery is handled separately. This adds 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with key behaviors. Efficient but could be structured with bullet points for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and no output schema, the description explains text vs binary returns and bulk support. However, it lacks details on return format specifics for both cases and error conditions, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. It mentions notebook_id and kind implicitly, but does not explain artifact_id, artifact_ids, or notebook_ids roles. Lacks detail on how to use parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it downloads artifact content, distinguishes between text and binary types with specific return behaviors, and mentions bulk support. This is specific and helpful.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for downloading artifacts, but does not explicitly compare with sibling tools like notebooklm_artifact_get or list when-not-to-use scenarios. Bulk support is mentioned but no guidance on when to use batch vs single.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate mutability (readOnlyHint=false) and non-destructiveness. The description adds critical async behavior and detailed options per kind, but does not elaborate on side effects beyond artifact creation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and informative, starting with purpose then listing options. No redundancy; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity and lack of output schema, the description covers async behavior and follow-up steps well. It could be more explicit about the artifact state, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant detail for 'kind' and 'options' parameters, with specific format details per type. However, it does not describe 'source_ids', 'language', or 'notebook_id' beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it generates a notebook artifact asynchronously, and lists all the kinds (audio, video, slide_deck, etc.). This distinguishes it from sibling tools that retrieve, delete, or list artifacts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description recommends following up with notebooklm_artifact_list/get, providing a clear usage flow. It does not explicitly state when not to use it, but the async nature and alternative types are covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. It adds value by noting bulk support, but it does not disclose behavior related to limit or show_all parameters, nor the format or ordering of returned history.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first clearly states the purpose, the second introduces bulk support. It is front-loaded, concise, and contains no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and 0% schema description coverage, the description explains the core notebook_id and notebook_ids but omits details on limit, show_all, return format, or pagination. This leaves significant gaps 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description partially compensates by explaining that notebook_ids is for batched execution, implying notebook_id is for a single notebook. However, it does not explain limit or show_all, leaving half the parameters without semantic guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Histórico de Q&A da conversa do notebook' which translates to 'History of Q&A of the notebook conversation,' providing a specific verb and resource. It distinguishes itself from siblings like notebooklm_ask and notebooklm_generate by focusing on retrieving past interactions. The mention of 'Bulk support' further clarifies batch capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies that the tool retrieves Q&A history and supports batched execution via notebook_ids, offering clear context for when to use it. However, it does not explicitly exclude alternatives or provide when-not-to-use guidance, though the tool's unique purpose among siblings makes this less critical.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the return format ([{ id, title, ... }]) and notes that the id is needed elsewhere, providing value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences in Portuguese, front-loaded with the core action. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and the simple listing nature, the description fully covers what the tool does, including the return format hint. Complete for the use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description does not need to add parameter meaning. Baseline 4 applies as per rubric.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Lista os notebooks do usuário' (list the user's notebooks), a specific verb-resource combination. It distinguishes from sibling tools like notebooklm_notebook_create or notebooklm_source_list by focusing on listing notebooks and indicating the return format with id for use in other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It mentions 'use o id nas demais tools', implying this list is a prerequisite for operations requiring a notebook ID. No explicit when-not or alternatives, but the zero-parameter context makes usage straightforward.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate not read-only, not destructive, not idempotent. Description adds that it returns the notebook with id, which is useful. However, fails to disclose if title conflicts cause error or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the key action. Every word contributes value; no redundant or verbose phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple creation tool with one parameter and no output schema, the description covers the essential purpose but lacks details on parameter semantics and error behavior. Could be improved with constraints on title and return value structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage for the single 'title' parameter. Description does not explain what title represents, format, or constraints. Agent receives minimal guidance beyond the parameter name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Creates a new (empty) notebook' using specific verb and resource. It distinguishes from sibling tools like delete, rename, metadata by specifying creation of an empty notebook.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., notebooklm_note_create, notebooklm_source_add). No mention of prerequisites or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description states 'irreversível' (destructive), but annotation 'destructiveHint' is false. This is a direct contradiction. No other behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no waste. Efficiently communicates key points.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Minimal context beyond deletion and bulk. Lacks error handling, permissions, and side effects. Contradiction reduces reliability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but description adds meaning: notebook_ids for batch execution. However, does not clarify relationship between notebook_id and notebook_ids.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb (delete/apagar) and resource (notebook), includes irreversibility and bulk support. Sibling tools are distinct in name, but no explicit differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Only minimal guidance: mentions bulk batch execution via notebook_ids. No when-to-use, prerequisites, or alternatives provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds that it returns metadata and sources and supports batch execution, which is useful but not extensive. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the primary purpose and adding a valuable note on bulk support. No superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with no output schema, the description covers core functionality (metadata and sources) and batch ability. However, it omits details about the output structure or any limits, leaving some ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema documentation coverage is 0%, so the description must compensate. It only hints at 'notebook_ids' for bulk support but does not explain the purpose of 'notebook_id' or the format of 'notebook_ids'. This leaves parameter semantics largely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: retrieves notebook metadata and list of sources. It distinguishes from siblings by specifying 'metadados do notebook + lista de fontes', and mentions bulk support, which sets it apart from similar notebook retrieval tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for fetching metadata and sources, and explicitly mentions bulk support via 'notebook_ids'. However, it lacks guidance on when not to use this tool versus alternatives like notebooklm_notebook_summary or notebooklm_source_list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate it is not read-only (modifies state) and not destructive. The description simply restates the rename action without adding behavioral details like idempotency, side effects, or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no redundant information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 0% schema coverage, the description is too sparse. It lacks details on return values, error handling, or how bulk execution works, making it incomplete for full understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter descriptions in schema). The description only mentions 'notebook_ids' for bulk but does not explain the meaning or constraints of 'notebook_id' or 'new_title'. Minimally helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Renomeia um notebook' (Renames a notebook), clearly identifying the verb and resource. Among siblings, there are other rename tools for artifacts, notes, and sources, making this specific to notebooks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions bulk support via 'notebook_ids' for batched execution, giving guidance on single vs batch use. However, it does not explicitly state when not to use or mention alternatives beyond the sibling context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about AI-generated insights and bulk processing, which does not contradict annotations. Additional behavioral detail is limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise, but written in Portuguese which may hinder understanding for English-based agents. The structure is clear but the language choice is suboptimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and simple parameters, the description covers basic functionality but lacks details on return format, error handling, or differentiation from similar summary tools. Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains the 'topics' parameter and 'notebook_ids' for bulk support, but does not clarify the required 'notebook_id' parameter or the relationship between the two. Partial but incomplete compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it generates a notebook summary with AI insights and mentions optional topics. This clearly distinguishes it from sibling tools like notebooklm_list or notebooklm_notebook_metadata, though the verb is implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no exclusions or prerequisites. Only mentions topics flag and bulk support, which is implicit usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false. The description confirms creation behavior but does not add extra details like idempotency, failure handling, or side effects beyond the bulk capability.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences: first states the primary purpose, second adds the key bulk feature. No redundant information, front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the core creation and batch functionality, but lacks description of return values (no output schema) and does not explain constraints on 'content' or 'title'. For a 4-parameter tool with no output schema, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so parameter descriptions are missing. The description explains the notebook_ids parameter for batch usage, but does not clarify the 'title', 'content', or 'notebook_id' parameters beyond their presence. Partial compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Cria uma nota no notebook' (Creates a note in the notebook), specifying the action and resource. It also mentions bulk support via notebook_ids, distinguishing it from sibling note tools like get, list, delete, and rename.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating notes and adds bulk support for batched execution. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description states deletion, but annotations set destructiveHint=false, which is a direct contradiction. No disclosure of side effects, permissions, or reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise two sentences, but mixing Portuguese and English may confuse. Provides essential info without superfluous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple delete tool with batch support; lacks return value description but overall sufficient given low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage; description adds meaning by clarifying that notebook_ids and note_ids enable batch execution, which is not apparent from parameter names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The name 'note_delete' and description 'Apaga uma nota' clearly indicate the tool deletes a note. It is distinct from siblings like notebooklm_note_create, notebooklm_note_get, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies use for deleting notes but provides no explicit when-to-use vs. alternatives. Bulk support is mentioned but no context on when batch is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the behavioral trait of bulk execution support (accepts arrays of IDs), but does not elaborate on what 'content' entails or any other side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with two short sentences, no fluff. However, it is somewhat under-specified; conciseness should be balanced with informativeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given four parameters, no output schema, and moderate annotations, the description is incomplete. It does not explain the response format, parameter roles beyond batch hints, or any edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning no parameters are explained. The description only mentions 'notebook_ids, note_ids for batched execution' but does not define singular parameters (note_id, notebook_id) or their formats. It adds minimal value beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Conteúdo de uma nota' (Content of a note), which specifies the verb (get) and resource (note). It also mentions bulk support with notebook_ids and note_ids, distinguishing it from sibling tools like notebooklm_note_list or notebooklm_note_create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool versus alternatives. While it mentions bulk support, it lacks explicit context for usage differentiation, such as prerequisites or cases to avoid.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it accepts notebook_ids for batched execution, which is a behavioral detail. However, it does not disclose return format, pagination, or behavior when both parameters are provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with the purpose front-loaded. No unnecessary words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite simplicity and annotations covering safety, the description lacks expected output details, pagination info, and potential filtering. Without an output schema, the agent has no idea what the list contains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description should compensate but only mentions notebook_ids for bulk support. The required notebook_id parameter is not explained, leaving agents to infer its meaning from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it lists notes of a notebook ("Lista as notas do notebook"), which is clear but lacks specificity about what the list contains. It distinguishes itself from single-note retrieval siblings like notebooklm_note_get by implying multiple notes, but does not explicitly contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like notebooklm_note_get or notebooklm_note_create. The mention of bulk support is a small hint, but there is no explicit context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-read-only and non-destructive; description adds batch support detail but no side effects, permissions, or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with main function and key bulk feature; no extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity and no output schema, description covers basic usage but omits behavior when both single and bulk ids are provided, error handling, and confirmation steps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description only mentions notebook_ids and note_ids for bulk; does not explain new_title, notebook_id, or relationship between parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool renames a note, and mentions bulk support, differentiating it from sibling note tools (create, delete, get, list) and notebook_rename.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use single vs bulk via note_id vs note_ids, and distinguishes from notebook_rename by name; lacks explicit when-not or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are all false, but the description does not disclose behavioral details such as required permissions, side effects, idempotency, or error states. The bulk support is noted, but overall transparency is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences: the first states the core purpose, the second adds bulk execution capability. No redundant information, but the first sentence could be clearer about the role options.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, no output schema, and no annotations providing guidance, the description is too brief. It does not cover return values, error conditions, or optional vs required parameters beyond what the schema's 'required' list specifies. The agent is left with many unknowns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description mentions email, permission (editor/viewer), and notebook_ids, but does not explain the 'message' parameter or clarify the relationship between notebook_id and notebook_ids. This provides some but insufficient semantic value beyond property names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shares a notebook with an email specifying editor/viewer role. It mentions bulk support with notebook_ids, which helps differentiate from single-share operations. However, it does not explicitly distinguish from sibling tools like notebooklm_share_public, notebooklm_share_update, or notebooklm_share_remove.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives one usage hint about bulk execution via notebook_ids, but does not specify when not to use this tool, prerequisites, or alternatives among sibling sharing tools. The Portuguese language may also be a barrier for some agents.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate modification (readOnlyHint false) and non-destructive, non-idempotent. The description adds 'toggle' and 'bulk support', providing some behavioral context. It does not contradict annotations, but misses details on consequences (e.g., link generation) or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff, front-loaded with purpose. Every sentence adds value: purpose and bulk support.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters and no output schema, the description is insufficient. It omits details about the enable parameter's role, return values, and what exactly happens on toggle (e.g., URL generation). The bulk support mention is helpful, but overall incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must add meaning. It implies 'enable' via 'liga/desliga' and mentions bulk via notebook_ids. However, the enable parameter is not explicitly linked to the toggle action, and no format/validation details are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool toggles the public link of a notebook, using a verb and resource. However, the mix of Portuguese and English may reduce clarity for non-Portuguese speakers. It distinguishes from sibling sharing tools by focusing on the public link toggle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions bulk support with notebook_ids, giving a hint for batch usage. However, it lacks explicit when-to-use or when-not-to-use guidance, and does not differentiate from other share tools beyond the specific action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description notes bulk support via 'notebook_ids', which adds context beyond annotations. However, it does not disclose whether the operation requires ownership, is reversible, or notifies the collaborator. Annotations (destructiveHint=false) are not contradicted but the description could provide more behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the core purpose and then adding the bulk feature. Every sentence is informative and there is no unnecessary text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple removal tool, the description covers the main action and bulk capability. However, it lacks information about error handling, permission requirements, or what happens if the email is not a collaborator. Given no output schema and limited context, it is reasonably complete but could be improved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining bulk execution via 'notebook_ids'. However, it does not explicitly describe the 'email' parameter (though it is obvious from context) or the role of 'notebook_id' in single removals, limiting full parameter clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Remove o acesso de um colaborador') and distinguishes the tool from siblings like notebooklm_share_add and notebooklm_share_update by focusing on removal. It also mentions bulk support, further specifying its capability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for removing collaborators but does not explicitly state when to use this tool versus alternatives (e.g., status or update). No when-not or prerequisites are given, which is adequate but lacks explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the bulk support capability ('accepts notebook_ids for batched execution'), which is useful. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: two sentences with no unnecessary words. The first sentence states the purpose, the second adds a key feature (bulk support).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters, annotations, and no output schema, the description provides the core function and bulk support but lacks details on the output format, error conditions, or batch response structure. It is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must clarify parameters. It only mentions 'notebook_ids' in the context of bulk support, but does not explain the purpose of 'notebook_id' or the relationship between the two parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves the sharing status of a notebook ('Status de compartilhamento do notebook') and mentions bulk support. However, it does not explicitly differentiate it from sibling share-related tools like notebooklm_share_view_level.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or context for choosing this over other share tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide little (destructiveHint=false). The description does not disclose behavioral traits beyond the basic operation. No info on reversibility, permissions, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with core action. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 params, no output schema, and minimal annotations, the description lacks completeness. It does not cover return values, error cases, or detailed parameter behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage. Description only explains notebook_ids for bulk support, ignoring email, permission, and notebook_id. The enumeration for permission is not explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool updates a collaborator's permission, with a verb and resource. It distinguishes from siblings like add, remove, and status by its specific action. Bulk support mention adds clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for updating permissions but provides no explicit guidance on when to use or avoid. It mentions bulk support, which gives context, but no alternatives or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds little beyond what annotations already convey. Annotations indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description does not detail side effects or further 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with only two sentences. It front-loads the core purpose and adds bulk support in the second sentence, leaving no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with three parameters and no output schema, the description covers the essential purpose and bulk capability. However, it could be more complete by clarifying parameter relationships and expected behavior when using notebook_ids versus notebook_id.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description fails to explain the parameters individually. It mentions 'level' implicitly via the enum values and 'notebook_ids' for bulk, but does not clarify the role of 'notebook_id' or how they relate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: defining the access level of the public link (full notebook or chat only). It distinguishes from siblings by specifying the view level, and mentions bulk support, leaving no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains when to use the tool (to set the view level) and mentions bulk support for batch execution. However, it does not provide explicit guidance on when not to use it or how it compares to other share-related tools like notebooklm_share_add.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are minimal (readOnlyHint=false, destructiveHint=false). The description adds behavioral context: type auto-detection and bulk support. It does not contradict annotations and enriches understanding beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, the first covering the basic operation, the second adding bulk support. No extraneous information. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core operation and mentions bulk support, but lacks details on response format, error handling, or the difference from sibling notebooklm_source_add_research. Given the tool's simplicity, it is adequate but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining the auto-detection of type and the use of title with text. It adds meaning to the parameters beyond the schema's enums and types, though not all parameters (e.g., notebook_ids) are detailed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds a source (URL or text) to a notebook, distinguishing it from sibling tools like delete, list, etc. The verb 'add' and the resource 'source' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage hints like auto-detection of type and bulk support, but does not explicitly state when not to use this tool or how it differs from siblings like notebooklm_source_add_research. Guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide no hints (all false), so the description must cover behavior. It discloses search-and-add behavior and batch capability, but lacks details on side effects (e.g., whether existing sources are affected), rate limits, or authorization needs. Basic transparency 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. It front-loads the primary action and then adds a bulk note. However, the Portuguese language may reduce scannability for English-based agents, but the structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters, 2 required, and no output schema, the description is incomplete. It covers the high-level purpose and batch capability but leaves parameter meanings and return value unspecified, requiring external documentation or trial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It only mentions batch support via notebook_ids and does not explain mode, import_all, from_source, or the relationship between notebook_id and notebook_ids. Almost no parameter semantics provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it searches the web or Drive and adds sources from results, clearly specifying the verb and resource. It distinguishes from sibling tools like notebooklm_source_add by implying research-based addition. However, the Portuguese language may slightly reduce clarity for an English-configured agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like notebooklm_source_add or notebooklm_source_list. The mention of bulk support hints at batch use, but no when-to-use or when-not-to-use context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states 'Remove' (a destructive action), but the annotation 'destructiveHint: false' indicates the tool is not destructive. This is a direct contradiction. The description only adds that batch execution is supported, but the contradiction severely undermines behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two short, front-loaded sentences. The first states the primary action, and the second adds essential bulk support information. No extraneous text, so it is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, no output schema, annotation contradiction), the description is incomplete. It lacks parameter details, preconditions (e.g., source must exist), return behavior, and does not resolve the annotation contradiction. The bulk support note is helpful but insufficient for full context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, placing the burden on the description to explain parameters. The description only mentions that notebook_ids and source_ids are accepted for bulk execution, but does not differentiate required vs optional parameters, the role of source_id and notebook_id, or any constraints. This is insufficient for the four parameters present.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Remove uma fonte do notebook' meaning 'Remove a source from the notebook', which is a specific verb-resource pair. The bulk support mention further clarifies the scope, and it is easily distinguished from sibling tools like notebooklm_source_add and notebooklm_source_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions bulk support via notebook_ids and source_ids, giving some context for batch execution. However, it provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it, leaving the agent to infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context: that it returns full text and supports batch execution. No contradictions. Could mention output size or format handling, but annotations lower the burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no fluff. The first sentence states the purpose; the second adds bulk capabilities. Could be slightly improved by separating single vs batch usage, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no output schema, and 0% schema coverage, the description is incomplete. It fails to explain the format parameter, the output (full text content), or how to handle single vs batch requests. The agent has significant gaps in understanding how to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, placing full burden on the description. The description only mentions that notebook_ids and source_ids are accepted for batch, but does not explain other parameters like format (enum text/markdown) or the relationship between required and optional arrays. Agents lack clarity on how to construct valid requests (e.g., can both single and batch be provided?).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves the full indexed text of a source ('Texto completo indexado de una fuente'). It is specific about the resource (fulltext) and implies retrieval. It distinguishes from siblings like notebooklm_source_get (which likely gets metadata) and notebooklm_source_list (list sources). Not a 5 because it doesn't explicitly say 'get' or 'retrieve'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions bulk support with notebook_ids and source_ids, indicating when to use for batch execution. However, it does not explicitly state when to use single vs batch, nor does it provide guidance on alternatives (e.g., notebooklm_source_get for metadata). No exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and idempotent behavior. The description adds useful behavioral context about bulk execution support, enhancing transparency beyond the structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two short sentences. It fronts the primary purpose immediately, and every word adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description omits what the return value contains beyond 'details'. It also does not clarify the purpose of required parameters not mentioned in the bulk support note. The description is incomplete for a 4-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It adds that notebook_ids and source_ids are for batched execution, but does not explain the primary parameters notebook_id and source_id, nor the relationship between them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Detalhes de uma fonte' clearly indicates the tool retrieves source details. It distinguishes from sibling tools like source_delete or source_list, but could be more specific about what 'details' include.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions bulk support with notebook_ids and source_ids, providing context for batch usage. However, it does not explicitly state when to avoid this tool (e.g., when text content is needed) or suggest alternatives like source_fulltext.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that the output is AI-generated, which is useful but does not disclose any additional behavioral traits like limitations or latency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief at two sentences, covering the core purpose and batch feature. It could be slightly more structured but is efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without output schema and with minimal parameter details, the description lacks completeness. It does not explain return values, batch operation mechanics, or constraints, which are important for a tool with multiple parameters and no sibling differentiation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It mentions batch support but does not describe the meaning or usage of each parameter (notebook_id, source_id, etc.), leaving ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it provides an AI-generated summary and keywords of a source, which is clear. However, it does not differentiate from similar sibling tools like notebooklm_source_get or notebooklm_source_fulltext.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions bulk support with notebook_ids and source_ids, but provides no guidance on when to use this tool versus alternatives, such as when a summary is preferred over full text.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool as read-only and idempotent. The description adds transparency by noting the return structure (list of sources with id, title) and bulk execution capability, providing context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, front-loading the purpose and adding key information about bulk support. No redundant words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides return structure and bulk feature, which is adequate for a simple listing tool. Lacks details on pagination or error handling, but is complete enough given the tool's straightforward nature and annotation coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description partially compensates by explaining notebook_ids is for batched execution. However, it does not elaborate on the primary notebook_id parameter or data format beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists sources of a notebook, specifying the resource (fontes do notebook) and action (Lista). It distinguishes from sibling tools like notebooklm_source_get (single source) and notebooklm_source_add, making it clear this is a listing operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description mentions bulk support via notebook_ids, it does not explicitly state when to use this tool versus alternatives like notebooklm_source_get or notebooklm_source_fulltext. Usage context is implied but not directly guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are minimal (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds that the tool re-indexes content, indicating modification. However, it does not disclose side effects, permissions, or rate limits, leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief (two sentences) and front-loaded with the main purpose. It conveys the essential action efficiently, though some details are missing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters and no output schema, the description is incomplete. It does not explain return values, error handling, asynchronous behavior, or prerequisites, leaving significant gaps for a modification tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only vaguely mentions bulk support. It does not explain what each of the four parameters (notebook_id, source_id, notebook_ids, source_ids) does, nor does it clarify relationships or required fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Reprocesses a URL/Drive source (re-indexes the current content).' The verb 'reprocess' and resource 'source' are specific and distinguish it from sibling tools like notebooklm_source_add or notebooklm_source_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions bulk support with 'notebook_ids, source_ids for batched execution,' but does not provide explicit guidance on when to use this tool versus alternatives like notebooklm_source_add or notebooklm_source_delete. The usage context is implied but not fully elaborated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-readonly and non-destructive. The description adds no behavioral traits beyond stating the action and bulk capability. It does not describe side effects, reversibility, or authorization needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (two lines), conveying the core action and bulk support. However, it is too sparse for effective use, lacking detail without being verbose. It is efficient but incomplete.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters (3 required), no output schema, and minimal description, the tool is inadequately documented. The description does not cover parameter constraints, return values, or prerequisites. It is insufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It only mentions 'notebook_ids' and 'source_ids' for batch support, but fails to explain 'new_title', 'notebook_id', or 'source_id' parameters and their relationships. The meaning of parameters is largely left to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'renames' and the resource 'source'. It mentions bulk support, distinguishing it from sibling tools like notebooklm_source_delete or notebooklm_source_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor any conditions for single vs batch execution. No exclusions or context are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide idempotentHint=true, readOnlyHint=false, destructiveHint=false, which are not contradicted. The description adds the behavioral context of needing conversation for reproduction, but does not go beyond what annotations already convey about safety or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste. The purpose is stated immediately, and the single usage guideline follows concisely. No unnecessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (3 params, no output schema). The description covers purpose and gives one key usage hint. However, it lacks mention of return behavior or that the tool might be idempotent (though annotation says so). Adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'conversation' parameter by specifying it should include recent messages, but fails to explain 'context' or 'message' beyond their presence in the schema. This leaves two of three parameters under-documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: reporting bugs, missing features, or sending feedback. It is distinct from sibling tools, which are mostly NotebookLM-related or authentication/toolkit functions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance to include the conversation array with recent messages for reproduction. It implicitly indicates when to use the tool (for reporting issues) but does not explicitly mention when not to use or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns current version info but does not detail the return format or any side effects. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words, front-loaded with the key action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema. While the description tells what it shows (platform and adapter versions), it does not specify the return format or structure. For a simple version query this may be sufficient, but more detail would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description correctly implies no input is needed. No additional parameter info required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shows 'current MCP platform and adapter versions', with a specific verb and resource. It is distinct from siblings like toolkit_info which likely provides more general info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking versions but does not explicitly state when to use this over alternatives or provide exclusions. For a simple tool, this is minimally adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which are consistent with a read-only state retrieval. The description adds value by specifying the exact content returned (installed MCPs, connection status, catalog counts), complementing the annotations well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, concise sentence that front-loads the main point ('Returns the current toolkit state') and efficiently lists the components. No unnecessary words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main return contents but lacks details on data types or structure (e.g., nested fields). However, given no output schema, the high-level summary is mostly sufficient for a simple info tool. Could clarify what an 'MCP' is.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters and 100% schema coverage, the baseline is 4. The description does not need to add parameter info since there are none, and it correctly focuses on the return value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Returns' and clearly states the resource 'toolkit state' with three concrete components: installed MCPs, connection status, and catalog tools count. It distinguishes itself from sibling tools that perform actions or target specific notebookLM features.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for inspecting toolkit state, but does not explicitly state when to use versus alternatives like show_version or login tools. No exclusions or sibling comparisons are provided, leaving context partially implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.