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

With no annotations, the description carries the full burden. It does disclose the mutating nature and the need for explicit user permission, which is important. However, it does not mention what happens on success or failure, whether duplicates are possible, or whether API authentication is required, leaving behavioral gaps.

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

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

The description is overlong and repetitive, restating the permission requirement multiple times ('Only when user explicitly asks', 'Do not add without user permission', 'Only after explicit Yes'). The 'How to Get a NotebookLM Share Link' section, including quota details, is auxiliary and not necessary for tool invocation.

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 provides enough workflow detail for an agent to successfully call the tool, including how to obtain a share link and how to confirm metadata. However, there is no output schema and no description of return values, error handling, or authentication requirements, especially given the presence of setup_auth and re_auth among siblings.

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 already documents all seven parameters, so the baseline is 3. The description adds meaning by explaining how parameter values should be elicited from the user (URL first, then content, topics, use cases) and how metadata should be proposed and confirmed before calling.

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

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

The description clearly identifies the verb 'add' and resource 'notebook', and narrows invocation to explicit user requests. This distinguishes it from sibling tools like list_notebooks, update_notebook, and remove_notebook without needing to inspect their schemas.

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

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

It explicitly states when to use the tool ('Only when user explicitly asks to add a notebook'), when not to ('Do not add without user permission'), and provides a mandatory conversational workflow. The example further reinforces the correct timing and confirmation step.

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?

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions authentication needs and browser debugging options, it doesn't explain what the tool actually does behaviorally - whether it performs a conversational query, returns RAG results, creates sessions, or how it interacts with NotebookLM. The behavioral mechanics are unclear.

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 poorly structured and not front-loaded with the tool's purpose. It begins with setup instructions rather than explaining what the tool does. While individual sections are reasonably concise, the overall structure prioritizes auxiliary information over core functionality, making it inefficient for quick understanding.

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 complex tool with 6 parameters, nested objects, no output schema, and no annotations, the description is incomplete. It covers setup and authentication context but fails to explain what the tool actually returns, how sessions work, or the core NotebookLM query behavior. The description doesn't compensate for the lack of output schema and behavioral annotations.

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 100%, providing comprehensive parameter documentation. The description adds no parameter-specific information beyond what's already in the schema. The baseline score of 3 reflects adequate parameter understanding through schema alone, with no additional value from the 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 fails to clearly state what the tool does. It's primarily composed of setup instructions, authentication tips, and user guidance rather than explaining the core function. The tool name 'ask_question' suggests asking questions to NotebookLM, but the description doesn't explicitly state this purpose or distinguish it from sibling tools like search_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 provides clear context about when to use this tool by explaining prerequisites (needs an active notebook) and referencing related tools for setup (add_notebook, list_notebooks, select_notebook). It mentions authentication requirements and troubleshooting steps, giving practical guidance for proper usage.

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

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

With no annotations, the description carries the full burden of behavior disclosure. It clearly indicates destructive deletion, preview-before-deletion, explicit confirmation, deep mode, Chrome/Chromium prerequisite, cross-platform behavior, and the library preservation option. This is far beyond minimal disclosure and fully prepares an agent for the tool's safety profile.

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

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

Although the description is long, it is well-structured with a critical warning front-loaded, a scannable categorized list, and clear sections for workflow and use cases. Every element serves the operational needs of a destructive, cross-platform tool; there is no filler 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?

Given the tool's complexity, destructive nature, absence of annotations, and absence of an output schema, the description is remarkably complete. It covers prerequisites, the eight categories scanned, the preservation escape hatch, a step-by-step workflow, and use cases. No critical detail needed to invoke the tool safely is missing.

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 100% for both parameters, so the baseline is 3. The description adds a recommended workflow that maps confirm=false to preview and confirm=true to execution, and clarifies preserve_library as keeping library.json 'while cleaning everything else.' This usage-level guidance goes beyond the schema's 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?

The description states a specific verb (cleanup) and resource ('all NotebookLM MCP data files across 8 categories'), with explicit scope. It is clearly differentiated from sibling tools, which are about notebooks, sessions, auth, or health, none of which perform system-wide data deletion. The 'Always runs in deep mode' detail adds further precision.

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

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

It provides explicit use cases (clean reinstall, troubleshooting auth issues, removing all traces before uninstall, cleaning old browser sessions) and a recommended workflow that sequences preview and execute calls, followed by setup_auth/re_auth. It does not explicitly state when not to use the tool, but since no sibling tool is an alternative for cleanup, the guidance is sufficient.

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

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

With no annotations available, the description carries the safety burden. The 'ask before closing' guardrail signals that closing can be disruptive and requires user consent, but it never states what closing actually does, whether it can be undone, or side effects on the current workflow.

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 with no filler. The core action is front-loaded, and the safety instruction 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 single-parameter tool with no output schema and a simple action, this definition is nearly sufficient: it gives the target, the ID source, and the key caution. It is only missing a clear statement of consequences and a pointer to the related reset_session alternative.

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 100%, and the schema already documents session_id as 'The session ID to close.' The description's 'by session ID' adds no new parameter semantics, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and target ('Close a specific session by session ID'), making the tool's purpose unambiguous. The action is distinct from siblings like list_sessions and reset_session, even though no sibling is named.

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

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

It gives an explicit behavioral rule: ask before closing if the user might still need the session, which tells the agent when invocation is appropriate. It does not name alternatives or list when not to use it, so it falls just short of full guidance.

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

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

Because annotations are absent, the description carries the burden. 'Get' implies read-only behavior and the returned categories are named, but there is no explicit statement that the call has no side effects, no authentication requirements, or no impact on sessions. The recovery note adds some useful behavioral context, but not 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?

The description is three compact, purposeful sentences: purpose, usage context, and an actionable troubleshooting fallback. It front-loads the core definition and every sentence 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?

The description tells an agent what to call, why, and what to inspect (authentication state, active sessions, configuration), plus how to recover from a failed health check. Since there is no output schema, a slightly more explicit return-shape note would make it fully complete, but the existing guidance is sufficient for a health check tool.

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

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

The tool takes zero parameters and schema coverage is complete, so there are no undocumented parameters to clarify. The rubric baseline for zero-parameter tools is 4, and the description does not need to add parameter-level detail.

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 a clear action ('Get server health status') and specifies the resource by enumerating what is included: authentication state, active sessions, and configuration. This makes the tool's function immediately identifiable and distinct from the other notebook/session tools.

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

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

It explicitly says to use this tool to verify the server is ready before starting research workflows, which is a concrete usage context. It also gives a conditional recovery path (cleanup_data + setup_auth when authenticated=false with persistent issues), but it does not explicitly contrast the tool with siblings such as list_sessions or setup_auth.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates a read-only statistics operation, which is sufficient for this simple zero-parameter tool, though it does not detail what 'usage' includes or specify return structure.

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

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

The description is a single, front-loaded sentence with no redundancy. It communicates the core purpose efficiently and includes concrete examples without unnecessary detail.

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, read-only statistics tool, the description is largely complete. The absence of an output schema is partially mitigated by the examples given, though exact fields and format remain unspecified.

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

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

The tool has zero parameters, so parameter semantics are not applicable; the baseline of 4 reflects that no parameter guidance is needed. The description's mention of the statistics content compensates for the lack of an output 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 a clear verb ('get') and a specific resource ('statistics about your notebook library'), with examples like total notebooks and usage. It is distinguishable from sibling tools like list_notebooks or get_notebook, though it does not explicitly name 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 implies this tool is for high-level library statistics, but gives no explicit guidance on when to use it versus listing notebooks or querying individual notebook details. There are no stated exclusions or alternative tool references.

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?

With no annotations, the description carries the burden of behavioral disclosure. 'Get detailed information' clearly signals a read-only operation, but it does not specify what 'detailed' includes, how errors are handled (e.g., invalid ID), or any response format expectations. Adequate but shallow.

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

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

A single sentence that is direct and front-loaded, with no filler. Every word contributes meaning.

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 one-parameter read tool, the description is sufficient to invoke correctly: provide an ID and receive detailed notebook info. The lack of an output schema makes 'detailed information' somewhat vague, but this is a minor gap given 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 description coverage is 100%, so the id parameter is already well documented in the schema. The description's 'by ID' merely restates the parameter's purpose without adding format, source, or usage details. Baseline 3 applies.

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

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

The description uses a specific verb ('Get') + resource ('notebook') + scope ('specific notebook by ID'), making it easy to distinguish from sibling tools like list_notebooks or search_notebooks. The intent 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 phrase 'by ID' implies usage when a notebook ID is available, but there is no explicit guidance on when to prefer this over list_notebooks, search_notebooks, or select_notebook. Alternatives are not named or excluded, so the usage context remains implied rather than stated.

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

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

With no annotations, the description carries the burden of conveying behavior. It reveals that the tool returns list metadata (name, topics, use cases, URL), but it does not mention pagination, ordering, authentication requirements, or potential side effects. For a simple list operation this is adequate but not richly transparent.

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: the first states exactly what is listed and what metadata is included; the second gives a clear next-step workflow. Well front-loaded and economical.

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 parameterless list tool, the description covers what it returns and how to use the result. It lacks details like whether the result is sorted or limited, but the core invocation context is 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?

The tool has zero parameters, so there is nothing for the description to explain beyond confirming it needs no input. The baseline for a parameterless tool is 4, and the description does not mislead.

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 a specific verb ('List') and resource ('library notebooks'), and includes the metadata fields returned. It is clearly a listing operation, distinct from 'get_notebook' or 'search_notebooks', though it does not explicitly name those siblings or explain the difference.

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

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

The description gives clear workflow guidance: use this tool to present options, then ask which notebook to use. It does not mention alternative tools or when to prefer search_notebooks or get_notebook, but the provided context is actionable.

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?

With no annotations, the description carries the full burden. It discloses the operation ('List all active sessions') and the returned stats, so an agent can infer a read-only listing, but it does not specify sorting, pagination, or what makes a session 'active.'

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: the first states the action and output shape, the second states the intended use case. Everything 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 no-parameter listing tool, the description gives the resource, the returned stats, and a usage directive. There is no output schema, but the stat list is spelled out, so the agent has what it needs to invoke and interpret 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 tool has zero parameters and 100% schema description coverage, so the schema already fully handles parameter meaning. Per the baseline for zero-parameter tools, a 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 states a specific verb-resource pair ('List all active sessions') and enumerates the returned data ('age, message count, last activity'), distinguishing it from notebook-focused siblings like list_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 second sentence explicitly frames when to use the tool—'continue the most relevant session instead of starting from scratch'—which gives clear context. It does not name alternatives or list explicit exclusions, so it stops short of a 5.

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?

Even with no annotations, the description fully discloses the destructive side effects: closing all browser sessions, deleting cookies and the Chrome profile, and opening a fresh login. It also sets expectations about repeated failures and cleanup steps. This is far more transparent than a minimal 're-authenticate' statement.

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 front-loaded with purpose and usage triggers, then moves through effects, verification, and troubleshooting in a logical order. Although long, every section earns its place given the destructive and potentially repeating nature of re-authentication, and there is no 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?

For a tool with no output schema and no annotations, the description is complete enough to call correctly: it explains what will happen, when to use it, how to verify success, and how to recover if re_auth fails repeatedly. The parameter schema fills in the remaining details.

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 100%, so the input schema already documents both parameters and their defaults. The description adds some framing around 'simple version' vs 'browser_options' but does not meaningfully expand on parameter semantics beyond what the schema provides.

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 opens with a specific action ('Switch to a different Google account or re-authenticate'), names the resource, and lists concrete triggers: rate limit reached, account switch, and broken authentication. This clearly communicates what the tool does and differentiates it from initial auth/setup by emphasizing re-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?

The description provides explicit 'Use this when' bullets covering rate limits, account switching, and broken authentication, plus follow-up verification with get_health and recovery steps involving cleanup_data. However, it does not explicitly contrast with setup_auth or state when not to use this tool, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the behavioral burden and does so well: it flags the tool as 'Dangerous,' requires explicit confirmation, and clarifies that the call removes from the library but 'Does not delete the actual NotebookLM notebook.' It does not mention error behavior or reversibility, but the destructive semantics and limits are disclosed.

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 warning is front-loaded and the numbered workflow is well organized. The example is slightly redundant with the steps, but it does not bloat the description and reinforces the confirmation behavior.

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 single-parameter destructive tool with no output schema, the description is complete: it covers the prerequisite lookup, exact confirmation wording, permission rule, and scope boundary. An agent has everything needed to decide and perform the call safely.

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 only parameter id is already fully described in the schema ('The notebook ID to remove'), so the schema carries the semantic weight. The description's workflow implies the id should be resolved by looking up the full notebook name, but it never explicitly connects id to list_notebooks or explains required 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 makes the operation clear through the quoted confirmation prompt 'Remove '[notebook_name]' from your library?' and explicitly scopes it to the library, adding 'Does not delete the actual NotebookLM notebook.' This distinguishes removal from the sibling update and add operations even without a direct declarative sentence.

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 numbered confirmation workflow: wait for user request, look up full name, ask explicit confirmation, and only call on 'Yes'. Explicitly states 'Never remove without permission or based on assumptions,' giving strong when-to-use guidance and a safety exclusion.

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?

With no annotations provided, the description reveals the key behavior: chat history is discarded while the session ID is preserved, and it flags that user consent is needed. However, it does not explicitly state that the reset is irreversible or what happens to the session immediately after reset.

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 carry the purpose, the behavioral caveat, and user guidance with no filler. Important information is front-loaded before the usage note.

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 one-parameter tool with no output schema, the description covers what is reset, that the session ID persists, when to use it, and the consent requirement. It could mention irreversibility or return behavior, but the tool is simple enough that nothing critical is missing.

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 100%, so the schema already fully documents session_id. The description adds no parameter-specific detail, which is acceptable given the single parameter is self-explanatory.

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 starts with a specific verb and resource: 'Reset a session's chat history.' The parenthetical '(keep same session ID)' further distinguishes it from close_session and makes the tool's scope 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?

It explicitly states when to use the tool ('Use for a clean slate when the task changes') and provides an important guardrail ('ask the user before resetting'). It does not explicitly name alternative tools, but the purpose and condition are clear enough for an agent.

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?

With no annotations, the description carries the behavioral burden. It adds useful context by explaining that results should be proposed and the user asked which to use, implying a non-destructive, candidate-returning search. However, it does not explicitly state that the operation is read-only, how results are returned, or any failure 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?

Two short sentences, no filler, with the core function front-loaded. Every sentence earns its place: the first defines what it searches, the second defines how to use the results.

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 single-parameter search tool with no output schema, the description covers the search fields and the intended follow-up workflow, which is enough to invoke correctly. It does not spell out the exact return structure, but that is a minor gap given 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?

The schema only describes 'query' as 'Search query', while the tool description adds that the query applies to name, description, topics, and tags. This enriches the otherwise minimal schema description and tells the agent what the query parameter will match.

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 a specific action ('Search library by query') and defines the resource scope plus the fields being searched (name, description, topics, tags). This clearly distinguishes it from sibling tools like list_notebooks, which would list without query matching.

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

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

The description gives clear usage context: use it to propose relevant notebooks for the task and then ask which to use. It does not explicitly name alternatives or list when-not-to-use cases, so it stops short of a 5.

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?

With no annotations, the description carries the full burden. It discloses the side effect of changing the active default for future ask_question calls and gives auto-switching guidance. It does not cover persistence, errors, or return behavior, but it is honest about the state mutation.

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 front-loaded with a one-sentence purpose, then organized into clear sections. The bullets and example are concise and directly useful for an agent deciding when and how to invoke the tool.

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 one-parameter tool with no output schema, the description is remarkably complete: it defines the effect, gives usage triggers, and provides an example. It could mention how to obtain the notebook ID (e.g., via list_notebooks) and what happens on an invalid ID, but those are minor 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 coverage for the single 'id' parameter is 100%, so the schema already explains it as 'The notebook ID to activate'. The description adds context about the default mechanism but not much additional parameter-level meaning.

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

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

The description opens with a specific verb and resource: 'Set a notebook as the active default'. It also clarifies its role relative to ask_question, which distinguishes it from the notebook CRUD siblings.

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 'When To Use' section gives explicit trigger conditions such as context switches and explicit user requests. It stops short of naming alternatives or stating when not to use the tool, but the provided contexts are clear and actionable.

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?

With no annotations provided, the description carries the behavioral burden and does so well: it explains the browser window opens, the tool returns immediately, the user has 10 minutes to log in, and get_health should verify success. It could go further by specifying what happens if the login times out or whether existing credentials are overwritten, but it is still notably transparent.

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 well-organized and front-loaded with the core behavior, then alternatives, then troubleshooting. It is longer than minimal but every section earns its place, especially the troubleshooting block that tells an agent exactly how to recover from auth failures.

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 annotations and no output schema, the description covers the main operational context: what it does, how long login takes, how to verify success, when to use an alternative, and how to recover from persistent failures. Minor gaps remain around exact return behavior and edge cases like expired browser sessions, but overall it is complete enough to call 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?

The input schema already provides 100% parameter coverage, describing show_browser and browser_options with defaults and guidance. The description itself does not add significant parameter-level meaning, but that is acceptable because the schema is already rich and the baseline for full schema coverage is 3.

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: Google authentication for NotebookLM access via a manual browser login. It also explicitly contrasts setup_auth with re_auth, so an agent can distinguish them without opening schemas.

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

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

The description gives concrete usage guidance: use setup_auth for first-time authentication or when auto-login credentials are unavailable, use re_auth for account switching/rate-limit workarounds, and verify with get_health afterward. It even includes a troubleshooting sequence involving cleanup_data, which fully covers when and how 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that metadata is updated but does not explain overwrite vs. merge semantics, permissions, reversibility, or return behavior. The example says 'Add Next.js 14 to topics' while the schema says 'New topics list', leaving ambiguity about whether array fields replace or augment existing 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?

The description is front-loaded with a one-sentence purpose, followed by compact Pattern, Examples, and Tip sections. Each section earns its place, and the examples make the intended confirmation flow concrete without adding 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?

The tool is reasonably complete for an update operation because the pattern and examples specify the call flow and the schema documents all parameters. However, with no annotations and no output schema, important gaps remain: overwrite semantics are ambiguous and the description's field enumeration is incomplete, which could lead to incorrect 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?

Schema description coverage is 100%, so the baseline is 3. The description adds useful context by listing common fields and noting that multiple fields may be updated at once, but its field list omits name and content_types, and it does not clarify whether array parameters replace or merge with existing values.

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 operation: 'Update notebook metadata based on user intent' and identifies the resource and relevant fields. This distinguishes it from siblings like add_notebook, remove_notebook, and get_notebook because it is the only tool that mutates an existing notebook's metadata.

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 Pattern section provides explicit conditions: identify the target notebook and fields, propose the exact change back to the user, and only call the tool after explicit confirmation. The examples reinforce this confirmation workflow. It does not explicitly name alternatives or when not to use it, so it stops short of a 5.

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