NotebookLM

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

Annotations already show idempotentHint=true and destructiveHint=false. The description adds behavioral details: calling with no args returns a link, calling with token sets a session token, and the permanent config option is recommended. It explains the token is a JWT and that the connection is non-expiring when set via config.

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 three sentences long, front-loaded with purpose. It contains necessary details but could be slightly more concise (e.g., 'log in' vs 'MCP.AI for IDE agents...'). Still, every sentence is informative and 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?

Given the single optional parameter and no output schema, the description covers the core functionality well. It explains the two authentication flows (permanent via config, session via token) and how to invoke each. Missing details like error responses or what happens if already authenticated, but overall complete for the tool's simplicity.

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

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

Schema coverage is 0% (no parameter description in schema). The description fully compensates by explaining the 'token' parameter: it is a JWT from the browser, and calling without it returns the login link. This adds essential meaning beyond the schema.

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

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, explaining the login flow and token acquisition. It distinguishes from sibling tools like 'connect' by specifying the method (browser login, token paste) and the permanent vs session options.

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 clear context on when to call with no args (to get the login link) vs with a token (for session login). It also mentions the best permanent method (config header). However, it does not explicitly state when not to use this tool or list alternatives among siblings.

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 readOnly, idempotent, non-destructive. Description adds context about return values and scenarios, but no additional behavioral traits beyond what annotations provide.

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 purpose and behavior, no fluff. Front-loaded with main purpose.

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, description adequately explains return values and scenarios. Covers both success and missing credentials 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?

No parameters in schema, so baseline 4. No need for parameter 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?

Description clearly states the tool returns connection status and URLs, with specific scenarios (all providers connected vs credentials missing). Distinguishes from sibling 'authenticate' by focusing on status rather than performing authentication.

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 vs alternatives like 'authenticate'. Description does not provide context for tool selection.

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

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

Annotations only state readOnlyHint=false and openWorldHint=true. The description goes much further by disclosing that writes require owner/admin, invoke runs one-off without installing, and that search/describe flag installation status. It also explains side-effect-free running of uninstalled MCPs and the return of connect/checkout links when credentials or payment are needed.

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 logically front-loaded: core purpose, then action flow, then key behavioral nuances, then permissions, then prompt library. Every sentence adds value, but the long one-paragraph format could be improved with bullet points or section breaks for 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?

This is a complex hub with 14 action values, 23 parameters, and two sub-domains (MCPs and prompts). The description covers the essential flows, permissions, edge cases (connect/checkout links), and return-link behavior, which is strong given no output schema. It leaves a few parameters (resume, immediate, conversation) unexplored, but the core usage is sufficiently complete for an agent to select and invoke the 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?

The schema has no parameter descriptions across 23 parameters (0% coverage). The description compensates by explaining the central 'action' enum (search, describe, invoke, install, etc.) and key parameters like tool_id, mcp_id, prompt_slug, and prompt_vars. However, not all 23 parameters are covered, so it is not fully exhaustive.

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 marketplace is the official catalog of MCPs/tools and the way to run them. It enumerates specific actions (search, describe, invoke, install) and distinguishes itself from sibling tools, which are concrete applications like notebooklm 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 provides explicit when-to-use guidance: 'Use install only to make an MCP PERMANENT in the active toolkit; prefer invoke for a single/occasional use.' It also outlines the core flow from search to describe to invoke, and explains when to expect connect/checkout links and retry behavior.

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 says 'Apaga' (delete), which implies destructive behavior, yet annotations set destructiveHint to false, creating a contradiction. Beyond that, it does not disclose consequences, permissions, or irreversibility. The bulk support note is included but insufficient for full 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?

Very concise (two sentences), front-loaded with the core action. However, the brevity sacrifices necessary detail, and the structure could be improved with a clear sentence order.

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 lacks essential context: no return value description, no success/failure indicators, no edge cases. Given four parameters and no output schema, more completeness 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%, and description only mentions 'notebook_ids, artifact_ids for batched execution' without explaining the required single parameters (notebook_id, artifact_id) or their roles. The description adds minimal value 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 deletes an artifact and mentions bulk support, which aligns with the name. However, it does not explicitly differentiate from other delete tools (e.g., notebook_delete, source_delete), but the context of artifact-specific operations makes it clear enough.

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, nor any prerequisites or conditions. The only hint is bulk support, but without context on when batch deletion 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, idempotentHint=true, and destructiveHint=false, so the tool is known to be safe. The description adds the bulk execution feature, which is useful context. No additional behaviors like rate limits or authentication needs are disclosed, but annotations cover the safety profile adequately.

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—two short lines with clear information. The main purpose is front-loaded, followed by a separate line for bulk support. 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 four parameters and no output schema, the description omits details about return values, what constitutes 'details/status', and how single vs. batch requests differ. Annotations cover safety but not functionality. The bulk support mention is helpful but leaves gaps for a complete 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?

With 0% schema description coverage, the description must compensate. It explains that 'artifact_ids' and 'notebook_ids' enable batch execution, clarifying the purpose of the array parameters beyond the schema's raw structure. This adds meaningful context for selecting single vs. batch calls.

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 'Detalhes/status de um artifact' (details/status of an artifact), clearly indicating the tool retrieves artifact information. It distinguishes from siblings like 'notebooklm_artifact_delete' and 'notebooklm_artifact_list', though the verb 'get' is implied by the title but not explicit in the description.

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 'artifact_ids' and 'notebook_ids', giving context for batch usage. However, it does not specify when to use this tool versus similar tools like 'notebooklm_artifact_list' or provide exclusions 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 already indicate the tool is read-only and idempotent. The description adds context about batch processing but does not disclose additional behavioral traits beyond what annotations provide.

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. First sentence front-loads the primary function and filter; second adds batch capability. No redundant 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?

Covers core functionality but lacks explanation of return format or what constitutes an artifact, which would be helpful given no output schema.

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 listing the allowed type values and explaining batch behavior with notebook_ids. However, the required notebook_id parameter lacks description.

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 artifacts, specifies the type filter with allowed values, and mentions bulk support. It distinguishes from siblings like get (single) and 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 provides context for using the type filter and batch execution but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

Annotations already convey read-only, idempotent, non-destructive behavior. Description adds that it 'awaits' status, implying blocking, but does not detail rate limits or response format.

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, but inconsistent language (Portuguese and English). Could be more structured with clear separation of single and batch usage.

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 schema descriptions, and no output schema, the description is insufficient. It lacks information on polling behavior, expected response, and error handling.

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 mentions batch support with notebook_ids and task_ids but does not explain individual parameters, required fields, or singular vs plural usage.

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 the tool polls/queries artifact generation status, which is distinct from sibling tools like notebooklm_artifact_get or notebooklm_artifact_list. However, 'artifact generation' could be more specific (e.g., audio generation).

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, such as after calling notebooklm_generate. No when-not or alternative tools mentioned.

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 and destructiveHint=false. The description adds behavioral context about bulk support (accepts arrays), which is beyond annotations. However, it does not disclose permissions, reversibility, 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, no waste. However, the first sentence is a single verb phrase and could be more informative. The structure is adequate but not optimized for quick 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?

The tool has 5 parameters and no output schema. The description lacks details on return values, error handling, batch limits, or how the operation behaves. Given the complexity and sibling tools, the description is insufficient for confident use.

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 bulk support but does not clarify the relationship between required single IDs and optional arrays. Missing explanations for 'new_title' and how batching works.

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 an artifact ('Renomeia um artifact'). The verb and resource are specific, but it does not differentiate from sibling tools like notebooklm_artifact_delete or notebooklm_artifact_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?

No guidance on when to use this tool versus alternatives. The mention of bulk support is useful but does not specify when batching is appropriate or when to use single vs bulk parameters.

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 do not provide behavioral traits (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so description carries burden. It only says 'retry' but does not disclose side effects, whether it replaces existing artifacts, or required permissions. Minimal behavioral context beyond the name.

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-load the purpose and add bulk feature. No wasted words, but could benefit from separating single vs bulk usage 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?

With 4 parameters, no output schema, and minimal parameter info, the description leaves significant gaps: no explanation of single vs bulk workflow, return value, error handling, or prerequisites for retrying a failed artifact.

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 only mentions 'notebook_ids, artifact_ids for batched execution' but does not explain each parameter's role, relationship between single and bulk parameters (e.g., mutual exclusivity), or data formats. Inadequate value added.

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 retries failed artifact generation, distinguishing it from sibling tools like get, list, delete, etc. The verb 'retry' and resource 'artifact' are specific, and the bulk support note adds 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?

The description mentions bulk support, giving a hint about batch vs single execution, but does not explicitly state when to use this tool over alternatives, prerequisites (e.g., artifact must have failed), or when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is safe and non-destructive. The description adds the bulk execution behavior via notebook_ids, which is not captured by annotations. 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?

Two short sentences, front-loaded with purpose and bulk capability. No wasted words, but could be slightly more descriptive.

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 rich sibling context, the description is incomplete. It does not explain what the suggestions look like, how they are generated, or prerequisites. The bulk support is noted, but the overall behavior remains vague.

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 mentions 'notebook_ids' for bulk support but does not explain the purpose of 'notebook_id' or provide format/constraints. At a baseline, the description adds minimal value 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 provides 'artifact suggestions' and mentions bulk support, distinguishing it from sibling artifact tools like notebooklm_artifact_list or notebooklm_artifact_delete. The verb 'suggestions' indicates a generative or recommendation function.

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. The bulk support hint is useful but does not provide context or exclusions. With many sibling tools for artifact management, the agent lacks direction on when to choose suggestions.

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 idempotentHint=true. The description adds that the response is grounded in sources with citations and that execution may be slow ('Pode demorar'), providing behavioral context beyond the 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 two sentences long, with the first sentence front-loading the core purpose and key behavior. Every word adds value, and there is no redundancy or filler.

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 lack of an output schema, the description should ideally explain the return format. It mentions citations and grounding but does not describe the exact structure, error behavior, or execution semantics like streaming. It covers basic intent but misses details that would fully inform an 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 description coverage is 0%, so the description must compensate. It mentions `notebook_ids` for bulk support, but does not clarify the semantics of `question` or `notebook_id` individually. Minimal parameter guidance is 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 verb 'ask' and the resource 'notebook', specifying that the answer is grounded in sources with citations. This sets it apart from sibling tools like `notebooklm_generate` and `notebooklm_history`, which imply different 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?

The description mentions that the operation may take time and supports bulk execution via `notebook_ids`, but does not explicitly state when to use this tool versus alternatives like `notebooklm_generate` or `notebooklm_history`. Usage context is implied but not clearly differentiated.

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. The description adds beyond this by specifying that text returns inline content, binary returns metadata + size, and bulk support is available. 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?

The description is extremely concise with two sentences covering the main behavior and bulk support. Every sentence adds value, and the information is 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?

Given the tool has 5 parameters (2 required) and no output schema, the description provides an adequate overview but lacks details on parameter formats, error handling, or specific return values. It mentions URL delivery separately but does not elaborate.

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 bears the burden. It explains that 'kind' determines content type and notes bulk parameters (artifact_ids, notebook_ids). However, it does not detail each parameter's format or constraints, leaving some ambiguity. It adds some value but not full 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 the tool downloads an artifact's content, distinguishing between text types (inline content) and binary types (metadata + size). It also mentions bulk support with notebook_ids and artifact_ids, which distinguishes it from related sibling tools like notebooklm_artifact_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 clear context for when to use the tool (downloading artifacts), with distinctions between inline text and binary content, and bulk execution. However, it does not explicitly state when not to use it or mention alternatives, but the context is clear enough.

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, providing minimal safety info. The description adds key behavioral details: it is asynchronous ('assíncrono') and returns the artifact in generation state. It also explains how different options affect the output. This compensates well for the sparse 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 reasonably concise given the complexity, but the mixture of Portuguese and English and the inline parameter details in a paragraph format slightly reduce clarity. It is front-loaded with the main action and follow-up guidance.

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?

It explains generation parameters and follow-up actions. No output schema exists, so description could mention expected return value or error handling. Given the tool's complexity (nested options, 6 params), it is mostly complete for invocation, but missing some behavioral 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?

With 0% schema description coverage, the description fully compensates by detailing each kind and its specific options with examples (e.g., audio format, slide_deck length, quiz difficulty). It adds meaning far beyond the schema's bare 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 generates a notebook artifact and lists all possible kinds. It distinguishes itself from sibling tools that manage already generated artifacts (e.g., notebooklm_artifact_get, 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 advises to follow up with notebooklm_artifact_list/get, providing usage context. However, it does not explicitly state when to use this tool versus alternatives, though the context is somewhat implied by its uniqueness.

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 safety profile is clear. The description adds the bulk execution behavioral trait, which is useful beyond the 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 short, front-loaded sentences with no redundancy. Every word 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 4 parameters and no output schema, the description lacks details on return format, pagination, or error conditions. It mentions 'bulk support' but does not describe what the output looks like or how to interpret results.

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 explain parameter meanings. It only mentions that notebook_ids enables batched execution, but does not clarify limit, show_all, or the required notebook_id. This is insufficient.

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 Q&A history of a notebook conversation, and mentions bulk support for multiple notebook IDs. This distinguishes it from sibling tools like notebooklm_ask (for asking questions) and notebooklm_list (for listing 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?

The description implies the tool is for retrieving history, but provides no explicit guidance on when to use it versus alternatives, nor when not to use it. Given the many sibling tools, some differentiation would be helpful.

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, so the safety profile is clear. The description adds minor value by specifying the return format (array with id, title) and the note about using id in other tools.

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, direct sentences with no wasted words. The key information (what it does, what it returns, how to use the result) is 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?

For a zero-parameter listing tool with comprehensive annotations, the description fully covers expected behavior: it lists notebooks, returns IDs and titles, and guides the agent to use those IDs in other tools.

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?

There are no parameters, so schema coverage is effectively 100%. The description does not need to add parameter info, and the baseline is 4.

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 user notebooks, returns an array with id and title, and instructs to use the id in other tools. It effectively distinguishes itself from siblings like notebooklm_artifact_list or notebooklm_note_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 implies this is the entry point to get notebook IDs for use in other tools, providing clear context. It does not explicitly mention when not to use it, but no sibling lists notebooks, so usage is unambiguous.

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 adds that the tool returns the notebook with its id, which is beyond annotations. However, it does not discuss side effects, idempotency (annotations indicate non-idempotent), or other behavioral traits. Annotations are present but minimal, so description provides moderate additional value.

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 very concise (two sentences) and front-loaded with the core purpose. No wasted words, though it could benefit from a bit more structure or explicit return info.

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 1-parameter tool with no output schema, the description covers basic purpose and return value. However, it lacks details like behavior when title is empty or duplicate, making it marginally 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?

Schema has 1 parameter (title) with 0% description coverage. The description does not mention the title parameter at all, adding no meaning beyond the type string. 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?

Description clearly states the verb 'cria' (creates) and resource 'notebook novo vazio' (new empty notebook), distinguishing it from siblings like delete or rename. It is specific and unambiguous.

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

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

No guidance on when to use this tool vs alternatives, no prerequisites or context provided. The description only states the action without any usage direction.

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 deletion is irreversible ("irreversível") while annotations have destructiveHint: false, creating a contradiction. Score 1 per rule.

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 core action. 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?

No output schema; description does not explain return values or post-deletion behavior. Minimal additional context beyond the core action.

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 notebook_ids for bulk but does not explain notebook_id or provide additional context for parameter usage.

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 deletes a notebook ("Apaga um notebook") and emphasizes irreversibility. It distinguishes from sibling tools like create, rename, 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 does not explicitly state when to use this tool versus alternatives. It mentions bulk support but lacks guidance on prerequisites or conditions.

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. The description adds that the tool returns metadata and a list of sources, and supports batch execution. This provides useful context beyond the 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 states the purpose, the second explains batch support. Every sentence 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?

Given no output schema, the description provides a high-level overview of the output (metadata and sources) but lacks detail on return structure or fields. Adequate for a simple tool, but could be more 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 only clarifies that 'notebook_ids' is for batch execution, but provides no detail on 'notebook_id' (the required parameter) or format constraints. Minimal value added.

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 'Metadados do notebook + lista de fontes' which clearly indicates the tool returns metadata and a list of sources. This distinguishes it from siblings like notebooklm_list (listing notebooks) and notebooklm_notebook_summary (summary). The verb is implicit but clear.

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 and the use of 'notebook_ids' for batched execution, but it does not specify when to use this tool versus alternatives (e.g., notebooklm_notebook_summary) or any prerequisites or limitations.

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 it is not read-only and not destructive, but the description does not add behavioral context beyond the rename operation. No mention of side effects, permissions, or return values.

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 the core action and a concise second sentence about bulk support. 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?

Given the tool's simplicity (3 params, no output schema), the description is insufficient. It lacks details on return values, error conditions, or prerequisites, relying too much on implicit knowledge.

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 explains the 'notebook_ids' parameter for batch execution but does not clarify 'notebook_id' and 'new_title' beyond the implicit rename action.

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 notebook' (renames a notebook), which is a specific verb+resource. The bulk support note further distinguishes it from other tools by indicating batch 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?

No guidance is provided on when to use this tool versus alternatives like notebooklm_notebook_create or other rename tools. The only hint is bulk support, but no explicit when/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 already declare readOnlyHint=true and idempotentHint=true, so the description only needs to add behavioral context. It adds that the tool generates AI insights and supports batch execution, but does not explain what happens with the summary (e.g., whether it is cached, any limits).

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) with no fluff. It front-loads the purpose and then adds bulk support. However, it could be slightly more structured by listing parameters explicitly.

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 tool with 3 parameters and no output schema, the description lacks key details: it does not explain the 'notebook_id' parameter, the expected output format (e.g., plain text or structured JSON), or any limitations. Despite annotations covering safety, the description is 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 the description must explain all parameters. It only describes 'topics' (boolean for including topics) and 'notebook_ids' (bulk support), but fails to clarify the required 'notebook_id' parameter, leaving a critical 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 states it generates a 'notebook summary with AI-generated insights' and mentions topics and bulk support. The purpose is clear as a summary retrieval tool, but it could be more precise about the exact output (e.g., text summary vs structured data).

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 sibling tools like notebooklm_notebook_metadata or notebooklm_notebook_list. The only usage hint is that 'topics:true' includes suggested topics, but no exclusions or alternatives are mentioned.

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 this is not read-only (readOnlyHint=false), not idempotent, and not destructive. The description adds transparency by revealing bulk support via 'notebook_ids' for batched execution, beyond what annotations provide.

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: one for the main purpose and one for bulk support. It is front-loaded and contains no fluff, though a slightly more structured format 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 4 parameters and no output schema, the description should provide more context on parameter usage (e.g., required fields, default behavior) and return value. It only covers bulk support, leaving significant gaps for a creation 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?

With 0% schema description coverage, the description must compensate. It only adds meaning for 'notebook_ids' (bulk support). The other parameters (title, content, notebook_id) are not explained, leaving their semantics unclear beyond their 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 'Cria uma nota no notebook' (Creates a note in the notebook), specifying the verb and resource. It also mentions bulk support. While it does not explicitly differentiate from sibling tools like notebooklm_note_rename, the purpose is unambiguous.

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

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

The description implies usage for creating notes but provides no explicit guidance on when to use this tool versus alternatives (e.g., notebooklm_note_rename or notebooklm_note_delete). The mention of bulk support offers some context for batched execution but no exclusions.

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 the deletion behavior, but adds little beyond the annotations (readOnlyHint=false indicates mutation). There is a contradiction: annotations set destructiveHint=false while the description implies destruction, reducing trust.

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: the first front-loads the core purpose, the second adds bulk support details. 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?

For a simple delete tool, the description is fairly complete given the annotation context. However, it lacks error conditions, return values, and side effects. With many sibling tools, more context could reduce 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 coverage is 0%, so the description partially compensates by mentioning bulk support with notebook_ids and note_ids. However, individual parameter meanings and required fields are 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 'Apaga uma nota' (delete a note), providing a specific verb and resource. It distinguishes from sibling note tools (create, get, list, rename) by explicitly indicating deletion.

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., when to use delete vs. other note operations). The bulk support mention is helpful but does not address use cases or exclusions.

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, indicating a safe read operation. The description adds information about batch execution, which is useful behavioral context beyond annotations, but does not cover response format or other behaviors.

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 with two sentences, no fluff. However, the first sentence is nearly redundant with the tool name. Still, it is efficiently structured and 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?

Given the lack of output schema and 0% schema coverage for 4 parameters, the description is incomplete. It does not explain return values, parameter details (e.g., format of IDs), batch size limits, or error handling. The tool is simple but the description insufficiently compensates for missing schema.

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 notebook_ids and note_ids for batch execution, giving meaning to the array parameters, but does not explain the relationship between singular and plural parameters, required fields, or how batch interacts with required 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 'Conteúdo de uma nota' (content of a note) and the name 'note_get' indicates retrieval. It distinguishes from sibling tools like note_list (which lists summaries) and note_create/delete/rename. The bulk support mention further clarifies the scope.

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 note_ids, but does not provide explicit guidance on when to use this tool vs alternatives like notebooklm_note_list. No context on prerequisites or exclusions.

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, and idempotentHint=true, covering safety and idempotency. The description adds batch execution behavior but fails to disclose pagination, limits, or sorting. 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?

Two sentences with no filler: first sentence states purpose, second adds critical bulk info. 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?

No output schema means the description should clarify return values, but it does not. It also lacks information on limits, sorting, or error conditions. For a simple list tool with batch, the description is 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 the description must compensate. It only notes that notebook_ids supports batched execution, leaving notebook_id completely undocumented. Details like format or constraints are missing.

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 'Lista' (list) and resource 'notas do notebook' (notes of the notebook), distinguishing it from sibling note tools like create, get, delete, etc. However, it does not specify the exact output content (e.g., IDs only or full notes), leaving some 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?

The description only mentions bulk support via notebook_ids but provides no guidance on when to use this tool versus alternative tools (e.g., notebooklm_note_get for a single note). No when-not or context for selection is 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 indicate readOnlyHint false and destructiveHint false, consistent with renaming. The description adds bulk execution behavior. No contradictions, but no further disclosure of side effects or permission 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 extraneous content. The first sentence states the purpose, the second adds bulk information. Efficient, but could benefit from slightly more structure, e.g., separating single and bulk usage.

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?

No output schema exists, and the description does not mention return values. The bulk support is explained, but parameter relationships are unclear. For a tool with 5 parameters and batch capabilities, more details on usage scenarios and parameter combinations would enhance 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 coverage is 0%, so description must compensate. It explains that note_ids and notebook_ids are for batched execution, but does not clarify the relationship between required single fields (notebook_id, note_id) and optional array fields, nor the meaning of new_title. The parameter interplay remains ambiguous.

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 'Renomeia uma nota' (renames a note), identifying the verb and resource. It distinguishes from sibling tools like notebooklm_note_create, notebooklm_note_delete, and notebooklm_note_list by focusing on renaming and adding bulk support.

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 mentions bulk support via arrays for notebook_ids and note_ids, giving some context on when to use bulk vs single. However, it does not specify prerequisites or when to avoid the tool, nor does it mention alternatives. More guidance on required vs optional parameters for bulk usage would improve clarity.

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 and destructiveHint false. The description adds that it shares (mutation) and supports bulk, but lacks details about side effects, permissions, or notifications.

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 that are concise and front-loaded with the primary action. Minor loss for being in Portuguese if the agent expects English.

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 covers the main action and bulk but omits details on message, permission enum, and success/failure behavior, leaving the tool somewhat 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?

The description adds meaning by linking email and permission to the share action, and mentions notebook_ids for bulk. However, with 0% schema coverage, it fails to explain the message parameter and exact values for permission, leaving gaps.

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 (share notebook), resource (notebook), and role (editor/viewer). It also mentions bulk support, which helps distinguish it from sibling share tools like remove, update, or status.

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 (to add a share), but does not explicitly state when not to use or provide alternatives. It could better differentiate from other share-related 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 already indicate readOnlyHint=false and destructiveHint=false, but the description adds little beyond stating the toggling action. It does not disclose whether the operation is reversible, what happens to existing public links, or any side effects. The bulk support mention adds minor context but fails to address behavioral details like rate limits or confirmation.

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 immediately states the main action (toggle public link), and the second adds the bulk support feature. 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?

Given the tool has three parameters and no output schema, the description is insufficient. It does not clarify parameter relationships, return values, or error conditions. While the core action is clear, the lack of detail forces the agent to rely on implicit knowledge.

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 for parameter meaning. It only mentions 'notebook_ids for batched execution' but does not explain the crucial 'enable' boolean or the primary 'notebook_id' parameter. This leaves significant ambiguity for an agent.

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 ('Liga/desliga o link público do notebook'). It also mentions bulk support, distinguishing it from sibling tools like notebooklm_share_add or notebooklm_share_remove which handle specific sharing 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or 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 provide no behavioral hints (all false). The description does not disclose side effects, permissions, or idempotency. The action 'remove' implies a change, but no details are given to help the agent understand implications.

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. No wasted words, but could be better structured with a clearer statement of action and parameters.

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 is mostly adequate but lacks details on prerequisites, return behavior, and error 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?

With 0% schema coverage, the description partially compensates by indicating that notebook_id and email are used for removing a collaborator, and notebook_ids for batch. However, it does not explain each parameter's format or constraints.

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 removes a collaborator's access and supports batched execution. It distinguishes from siblings like notebooklm_share_add, though it could be more precise in specifying the resource (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 like notebooklm_share_update or notebooklm_share_add. The bulk support is mentioned but without context on preferable use cases.

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 batch execution capability but no other behavioral details (e.g., error handling or response format).

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 brief sentences with no filler words; adequate given the tool's simplicity.

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?

No output schema; description omits return value details and prerequisites. Incomplete for a tool with no schema descriptions.

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%; description mentions notebook_ids for bulk but does not explain the relationship between parameters or their expected format.

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 'Status de compartilhamento do notebook' clearly indicates it retrieves sharing status. Bulk support is mentioned, distinguishing it from sibling tools like notebooklm_share_add.

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_share_add or notebooklm_share_view_level. Usage is implied but not 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 already indicate readOnlyHint=false, so the description confirms it is a write operation. But it lacks details about side effects (e.g., overwriting existing permissions), authorization needs, error states, or rate limits. The only added behavioral info is batch support, which is more about usage than 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 is extremely concise with two sentences. The first sentence delivers the core purpose, and the second adds a key feature (bulk support). No redundant or 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 the tool has 4 parameters with zero schema descriptions and no output schema, the description is insufficient. It omits parameter details, return values, prerequisites, and error handling. The bulk mention is helpful but not enough for an agent to fully understand the tool's 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 description coverage is 0%, so the description should compensate. It only explains the 'notebook_ids' parameter for batch operations, but fails to clarify 'email', 'permission' (enum values editor/viewer), and 'notebook_id'. No details on required versus optional behavior.

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 ('Atualiza a permissão de um colaborador') and the resource ('permissão de um colaborador'). It also distinguishes from siblings like notebooklm_share_add and notebooklm_share_remove by focusing on updating existing permissions, not adding or removing them.

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 vs single notebook_id. However, it does not provide explicit guidance on when to use this tool versus alternatives like notebooklm_share_add or notebooklm_share_remove, leaving some ambiguity.

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 sparse (no readOnlyHint or destructiveHint), and description does not disclose side effects, prerequisites, or behavioral traits beyond the basic operation. For a mutation tool, more context is needed.

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

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

Two sentences with clear front-loading: first sentence defines core purpose, second adds bulk support. No extraneous content.

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?

Lacks explanation of prerequisites, error behavior, or return values. Without output schema and with minimal annotations, description should cover more 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?

Description partially compensates for 0% schema coverage by mentioning level enum values and bulk support. However, it does not explain the relationship between notebook_id and notebook_ids, nor the required/optional nature.

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 the tool defines the access level of a public link, specifying the two possible values (full and chat). It distinguishes itself from sibling tools like notebooklm_share_public by focusing on view level rather than sharing status.

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 when-to-use or when-not-to-use guidance. Bulk support is mentioned, but no comparison to alternatives like notebooklm_share_public. Usage context is implied only.

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 readOnlyHint=false and destructiveHint=false, implying mutation but not destruction. The description adds that type auto-detection occurs and bulk execution is supported, but does not disclose other behavioral traits such as permission requirements or side effects beyond what annotations provide.

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 long, front-loaded with the main action and variants, and every sentence adds value. 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?

For a tool with 5 parameters, no output schema, and low schema coverage, the description covers the essential aspects: type handling, title usage, and bulk support. It is reasonably complete for an add operation, though it could mention input constraints or error conditions.

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?

Despite 0% schema description coverage, the description adds significant meaning: it clarifies that type is auto-detected, advises using type:'text' + title for text input, and explains that notebook_ids enable bulk execution. This compensates for the schema 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 the action (adds a source), the resource (notebook), and distinguishes between types (URL, YouTube, text). It also mentions bulk support, differentiating it from other source tools like notebooklm_source_add_research.

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 some guidance on when to use type:'text' + title for pasting text and mentions bulk support. However, it does not explicitly state when not to use this tool or compare it to alternatives like notebooklm_source_add_research, leaving usage context somewhat implied.

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 this is a mutation tool (readOnlyHint=false) and not destructive. The description confirms it adds sources, consistent with annotations. However, it does not disclose potential side effects like duplicate handling, permission requirements, or rate limits beyond what annotations already 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 concise sentences: first states core purpose, second adds batch capability. No fluff, front-loaded with the primary action, 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?

The description omits return value (no output schema), error behavior, or execution order. Given 6 parameters and moderate complexity, the agent lacks critical context to use the tool reliably beyond basic 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 explains from_source (web/drive) and notebook_ids (bulk), but leaves mode (fast/deep), import_all, and notebook_id unelucidated. This partial coverage is insufficient for an agent to correctly configure all 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 searches the web (or Drive) and adds sources from results, with explicit mention of bulk support via notebook_ids. It distinguishes itself from sibling notebooklm_source_add (which likely adds sources directly) by including the research action.

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 research-based source addition and mentions bulk support, but does not provide explicit guidance on when to use this tool versus alternatives like notebooklm_source_add, nor does it list any exclusions 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 says 'Remove' but annotations show destructiveHint=false, which is inconsistent for a delete operation. The description does not clarify whether the removal is permanent or reversible, nor does it mention required permissions 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?

The description is only two sentences, front-loaded with the purpose. It is concise, though a bit more detail on parameters could be included without becoming 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 no output schema and destructiveHint=false annotations, the description should provide more context about what happens after deletion (e.g., if the source is permanently deleted or just disassociated). It also lacks guidance on when to use this vs. other delete tools.

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 add value. It explains that notebook_ids and source_ids support bulk execution, but does not differentiate between the single (source_id, notebook_id) and array parameters, nor explain their format.

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 a source) and the resource (notebook). However, it does not differentiate this tool from sibling delete tools like notebooklm_notebook_delete or 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?

The description mentions bulk support via notebook_ids and source_ids, implying when to use array parameters. But it lacks explicit when-to-use, when-not-to-use, or alternatives to other 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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds info about batch execution via notebook_ids and source_ids, which is useful but not extensive. 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 sentences with no redundancy. The first sentence is brief but vague; the second adds batch support. Could be more direct, but length is appropriate.

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 0% schema description coverage, the description is too sparse. It fails to explain what is returned, the role of format, or the relationship between singular and plural IDs. A more complete description would cover these 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 the description must compensate. It mentions batch support for arrays, but does not explain the singular counterparts (source_id, notebook_id) or that they are required. The format enum is in the schema but not elaborated. The description adds minimal value over 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 states 'Texto completo indexado de uma fonte' which indicates it retrieves full text of a source. Although no explicit verb like 'get' or 'retrieve' is used, the context of sibling tools (e.g., notebooklm_source_get for metadata) implies it fetches content. Distinguishes from siblings by being the only one providing full text.

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. The description only mentions bulk support with arrays, but does not explain when to prefer this over notebooklm_source_get or other tools. No when-not or exclusion criteria 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering core safety. The description adds the behavioral trait of bulk execution (accepts notebook_ids, source_ids), but fails to mention return format or error behavior. 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 short sentences) with no wasted words. However, it lacks structure (e.g., separate sections for single vs. batch) and could be slightly expanded for clarity without losing 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?

Given 4 parameters, no output schema, and the tool's complexity, the description is insufficient. It does not specify return fields, required input format, or error handling, leaving the agent guessing about the tool's full 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?

With 0% schema coverage, the description partially compensates by explaining that notebook_ids and source_ids enable batch execution. However, it does not explain the required single parameters (notebook_id, source_id) or their relationship to the arrays.

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' (details of a source) clearly states the tool retrieves source details, distinguishing it from sibling tools like notebooklm_source_list (list sources) and notebooklm_source_delete. The bulk support mention reinforces its purpose for single or batch retrieval.

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 (e.g., notebooklm_source_list for listing, notebooklm_source_get for details). The description lacks context on prerequisites or comparison with sibling 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 already indicate readOnlyHint=true and idempotentHint=true. The description adds that the output is AI-generated, implying potential variability, and that bulk execution is supported. This enriches the behavioral context without contradicting annotations.

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

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

Two concise sentences. The first sentence front-loads the core purpose (summary + keywords). The second adds the bulk capability. No unnecessary words; every sentence provides 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?

For a tool with no output schema, the description covers the main function and batch support. However, it lacks details on output structure, prerequisites (e.g., source must exist), language, and the exact meaning of 'guide' in the name. These gaps reduce 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?

The input schema has 0% description coverage, so the description adds critical meaning: that source_id and notebook_id are for single use, while source_ids and notebook_ids enable batch processing. This explains the role of two parameters partially, but does not clarify the relationship between the singular and plural versions or other constraints.

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 generates an AI-powered summary and keywords for a source. This distinguishes it from sibling tools like notebooklm_source_get or notebooklm_source_fulltext which retrieve raw content. The purpose is specific and actionable.

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

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 a usage hint. However, it does not explicitly state when to prefer this tool over alternatives (e.g., for quick insights vs. full text), nor does it provide exclusions 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. The description adds that it returns a list, which is expected, but provides no further behavioral context (e.g., pagination, permissions). Adequate given 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 sentences, front-loaded with the core purpose, and a separate line for bulk support. No unnecessary words, highly 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 purpose and bulk support, but lacks details about return fields beyond id and title (the '...' is vague), and does not mention notebook_id requirement explicitly. With no output schema, more detail on the return structure 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 descriptions are absent (0% coverage). The description implicitly references notebook_id and introduces notebook_ids for bulk support, but does not explain parameter formats, constraints, or relationships. Partially compensates but insufficient for a 2-parameter tool with no 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 lists sources of a notebook and returns an array of objects with id, title, and presumably other fields. This distinguishes it from sibling tools like notebooklm_source_get (single source) and notebooklm_source_add/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 via notebook_ids, implying batch usage, but does not explicitly guide when to use this tool versus alternatives like notebooklm_source_get or when not to use it. Context is implied but not 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?

Description explains the action (re-indexing) and does not contradict annotations. It adds value beyond annotations by specifying that it updates content rather than being destructive.

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 the core action, and efficient mention of bulk support. 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?

Covers the main purpose and bulk capability. Could mention prerequisites (source must exist) for completeness, but the core behavior is well described.

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 noting bulk support via notebook_ids and source_ids, but doesn't fully clarify the relationship between required and optional 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 reprocesses a URL/Drive source (re-indexes current content), using specific verbs ('reprocessa', 're-indexa') and distinguishing it from sibling tools like add or 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?

Usage is implied (refresh existing sources) but lacks explicit when-to-use or when-not-to-use guidance. No alternatives mentioned, though the bulk support hint provides some 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 indicate readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond 'Bulk support'. It does not disclose whether the operation is idempotent, atomic for bulk, or any side effects. The description fails to add 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?

The description is very concise (two short sentences), but it sacrifices essential information. While front-loaded with the core action, the brevity results in insufficient detail. Every sentence earns its place, but the content is minimal.

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 tool with 5 parameters, no output schema, and 0% schema coverage, the description is severely incomplete. It omits return value, error handling, bulk semantics, parameter constraints, and any usage scenarios. Agents are left with insufficient information to use 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 0% schema description coverage, the description must compensate but only mentions 'notebook_ids, source_ids for batched execution'. It does not explain the relationship between singular and plural parameters, the meaning of 'new_title', required vs optional, or any constraints. This leaves agents guessing about parameter usage.

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 'Renomeia uma fonte' clearly states the action (rename) and resource (source). It distinguishes itself from siblings like notebooklm_source_add or notebooklm_artifact_rename by specifically targeting source renaming. However, it lacks explicit differentiation from other rename tools (e.g., notebooklm_notebook_rename) and could be more specific about the scope.

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 any guidance on when to use this tool versus alternatives (e.g., when to use singular parameters vs. bulk arrays). It mentions 'Bulk support' but lacks context on prerequisites, limits, or when not to use this tool.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=true) are present. The description adds behavioral context by specifying what input to provide (conversation array). 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 concise sentences with front-loaded purpose. 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 output schema and a simple tool, the description covers the basic action but lacks details on return value, behavior on submission, or error handling. Adequate for a simple feedback 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%, so the description must compensate. It only explains the 'conversation' parameter ('Include the conversation array...'), leaving 'context' and 'message' without explanation. 'message' is obvious but 'context' remains ambiguous.

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: 'Report a bug, missing feature, or send feedback.' It uses a specific verb ('report') and resource ('bug, missing feature, feedback'), and is distinct from sibling tools which are mostly for notebook 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 a clear usage instruction: 'Include the conversation array with recent messages for reproduction.' It gives context for when to use the tool, though it does not explicitly state when not to use it or mention 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=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool shows platform and adapter versions, which aligns with these traits. No contradiction, and the description adds useful 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 a single, well-formed sentence with no unnecessary words. 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?

For a parameterless, read-only tool with no output schema, the description is complete. It clearly communicates the tool's purpose without needing additional detail.

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?

There are no parameters (schema description coverage 100%), so the description does not need to explain parameters. A baseline of 4 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 the verb 'Show' and specifies what is shown: current MCP platform and adapter versions. This distinguishes it from siblings like toolkit_info, which likely provides different 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 use when version info is needed, but does not explicitly state when to use or alternatives. Given the tool's simplicity and lack of similar siblings, this is adequate but not exemplary.

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 useful context by enumerating exactly what the returned state includes (installed MCPs, status, accounts, tool counts), which goes beyond the annotations and helps the agent set expectations.

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, well-structured sentence that front-loads the core purpose ('Returns the current toolkit state') and then lists the key contents. Every word contributes value, with no fluff 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?

For a simple read-only tool with no parameters and no output schema, the description gives a complete picture of what is returned. It covers the tool's main components and is sufficient for an agent to decide when to invoke it.

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, and the input schema is effectively empty. The description correctly does not mention parameters, and the baseline for zero-parameter tools is 4. No additional parameter semantics are needed.

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 returns toolkit state, listing specific components (installed MCPs, connection status, accounts, catalog tool count). This is a specific verb+resource ("Returns the current toolkit state") and distinguishes it from sibling tools like authenticate or show_version.

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 this tool (when you need to inspect toolkit state) but does not explicitly state alternatives or exclusions. The context is clear, but it lacks a direct 'when to use vs. alternatives' statement.

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