Server Quality Checklist

Tool Scores

• ask_questionC
  2.6/5.0
  Behavior2/5

  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.

  Conciseness2/5

  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.

  Completeness2/5

  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.

  Parameters3/5

  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.

  Purpose2/5

  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.

  Usage Guidelines4/5

  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.

• get_notebookC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving 'detailed information' but does not specify what that includes, whether it's a read-only operation, error handling, or authentication requirements. This leaves significant gaps for a tool with no annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'detailed information' includes, potential errors, or how the tool behaves in edge cases. For a tool with no structured behavioral data, more context is needed to guide effective usage.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting the 'id' parameter. The description adds minimal value by implying the ID is used to fetch notebook details, but does not provide additional context like format examples or constraints beyond what the schema already states.

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

  Purpose4/5

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

  The description clearly states the tool's purpose as retrieving detailed information about a specific notebook using its ID. It specifies the verb ('get') and resource ('notebook'), but does not differentiate it from sibling tools like 'select_notebook' or 'search_notebooks', which may have overlapping functionality.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as 'list_notebooks' or 'search_notebooks'. It lacks context about prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving the agent to infer usage.

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

• get_library_statsB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get statistics' but doesn't specify if this is a read-only operation, requires authentication, has rate limits, or what the output format might be (e.g., aggregated counts vs. detailed logs). The description is minimal and fails to disclose key behavioral traits beyond the basic action, leaving significant gaps for the agent.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('Get statistics about your notebook library') and adds brief examples ('total notebooks, usage, etc.'). There's no wasted text, and it's appropriately sized for a simple tool. However, it could be slightly more structured by explicitly stating it's a read operation or listing key stats, keeping it from a perfect score.

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

  Completeness2/5

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

  Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'statistics' entail (e.g., numerical counts, usage trends), whether the output is real-time or cached, or any prerequisites like authentication. For a tool that likely returns data, the lack of output schema means the description should compensate more, but it provides minimal context, leaving the agent with insufficient information.

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

  Parameters4/5

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

  The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, as there are none to document. It implies no filtering or options (e.g., date ranges or user-specific stats), which aligns with the schema. A baseline of 4 is appropriate since the description doesn't contradict the schema and the absence of parameters is clear.

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

  Purpose4/5

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

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('statistics about your notebook library'), and mentions example metrics ('total notebooks, usage, etc.'). It distinguishes itself from siblings like 'get_notebook' or 'list_notebooks' by focusing on aggregated statistics rather than individual items or lists. However, it doesn't explicitly differentiate from 'get_health' (which might overlap with system health vs. library stats), keeping it from a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify if this should be used for monitoring library health, reporting metrics, or as a prerequisite for other operations. With siblings like 'get_health' (possibly for system stats) and 'list_notebooks' (for detailed listings), the lack of explicit when/when-not or alternative recommendations leaves the agent to infer usage context.

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

• search_notebooksB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool searches and proposes notebooks, but doesn't describe key behaviors like whether it returns a list, how results are ranked, if there are limits on results, or what happens if no matches are found. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its operation.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the core functionality (searching by query) and includes a usage tip. It avoids unnecessary words, though the second part about proposing and asking could be slightly more integrated for optimal flow.

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

  Completeness3/5

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

  Given the tool has one parameter with full schema coverage but no annotations or output schema, the description is adequate but incomplete. It covers the purpose and basic usage but lacks details on behavioral traits (e.g., result format, error handling) and doesn't explain return values, which is a gap since there's no output schema to compensate.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the single parameter 'query' documented as a search query. The description adds value by specifying what the query can match (name, description, topics, tags), which provides semantic context beyond the schema. However, it doesn't detail query syntax or examples, so it meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool searches a library using a query that can match name, description, topics, and tags, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_notebooks' or 'get_notebook', which might offer alternative ways to find notebooks.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: to propose relevant notebooks for a task based on a search query, and then ask which to use. This implies it's for discovery and selection purposes. However, it doesn't explicitly state when not to use it or name alternatives like 'list_notebooks' for unfiltered listing.

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

• add_notebookA
  3.9/5.0
  Behavior4/5

  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. It effectively describes the tool's behavior: it requires explicit user permission, follows a mandatory multi-step conversation workflow, requires specific metadata collection, and only executes after confirmation. It also provides context about NotebookLM limits (free vs upgraded tiers), though it doesn't mention 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.

  Conciseness2/5

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

  The description is excessively long (over 300 words) with significant redundancy. While the workflow details are valuable, they could be more concise. The 'How to Get a NotebookLM Share Link' section, while helpful, is overly detailed for a tool description. The core purpose gets buried among procedural details and platform documentation.

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

  Completeness4/5

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

  For a 7-parameter mutation tool with no annotations and no output schema, the description provides substantial context about the tool's behavior, prerequisites, and usage workflow. It covers the conversational approach, permission requirements, and NotebookLM platform context. The main gap is the lack of information about return values or error conditions, which would be helpful given the absence of an output schema.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. However, it provides context about how to obtain the 'url' parameter (via NotebookLM share link process) and gives examples of metadata values throughout the workflow description.

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

  Purpose4/5

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

  The description clearly states the tool adds a notebook to a library, with the phrase 'add a notebook' appearing multiple times. It distinguishes from siblings like 'remove_notebook' and 'update_notebook' by focusing on creation rather than modification or deletion. However, it doesn't explicitly contrast with 'get_notebook' or 'list_notebooks', which are read operations.

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

  Usage Guidelines5/5

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

  The description provides explicit, detailed guidance on when to use this tool: only when the user explicitly asks to add a notebook, after completing a specific 6-step workflow (asking for URL, content, topics, use cases, proposing metadata, and getting explicit 'Yes' confirmation). It also specifies when NOT to use it ('Do not add without user permission', 'Do not guess metadata'), making alternatives clear.

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

• list_sessionsA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It describes the tool's behavior as listing active sessions with specific stats, which is helpful. However, it doesn't disclose other behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or pagination. The description adds some value but leaves gaps in behavioral context.

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

  Conciseness5/5

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

  The description is two concise sentences with zero waste. The first sentence states the purpose and output, and the second provides usage guidance. It's front-loaded with essential information and efficiently structured.

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

  Completeness3/5

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

  Given no annotations, no output schema, and 0 parameters, the description is moderately complete. It explains what the tool does and when to use it, but lacks details on behavioral aspects like response format, error handling, or dependencies. For a simple list tool, this is adequate but has clear gaps in context.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't mention any parameters, which is appropriate. Baseline is 4 for 0 parameters, as the description doesn't need to compensate for missing schema info.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'List all active sessions with stats (age, message count, last activity).' It specifies the verb ('List'), resource ('active sessions'), and what information is returned. However, it doesn't explicitly differentiate from sibling tools like 'close_session' or 'reset_session' beyond the 'list' vs. 'modify' distinction.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance: 'Use to continue the most relevant session instead of starting from scratch.' This tells the agent when to use this tool (to find existing sessions for continuation) versus alternatives like starting new sessions implicitly. It directly addresses the 'why' for tool selection.

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

• remove_notebookA
  4.2/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and excels at behavioral disclosure. It explicitly warns 'Dangerous', specifies the confirmation workflow requirement, clarifies what gets removed (from library, not the actual notebook), and provides concrete implementation guidance. This goes well beyond basic functional description.

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

  Conciseness3/5

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

  The description is appropriately front-loaded with the critical warning, but includes extensive workflow details and a full example. While all content is valuable for this dangerous operation, the multi-part structure with numbered steps and example could be more streamlined. Every sentence earns its place for safety, but it's not maximally concise.

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

  Completeness4/5

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

  For a destructive tool with no annotations and no output schema, the description provides excellent contextual completeness. It covers the dangerous nature, required workflow, what actually gets removed, and concrete usage examples. The main gap is lack of information about return values or error conditions, but given the safety emphasis, this is reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100% with the single parameter 'id' documented as 'The notebook ID to remove'. The description doesn't add any additional parameter semantics beyond what the schema provides, such as format examples or ID sourcing. With high schema coverage, baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool removes a notebook from the user's library, with the specific verb 'remove' and resource 'notebook'. It distinguishes from siblings like 'delete' operations by clarifying it 'does not delete the actual NotebookLM notebook', though it doesn't explicitly differentiate from other removal-related tools (none exist in siblings).

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

  Usage Guidelines5/5

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

  The description provides explicit, step-by-step guidelines on when to use this tool: only after user confirmation in a specific workflow (steps 1-4). It clearly states 'Never remove without permission or based on assumptions', offering strong exclusion criteria. The example further illustrates proper usage context.

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

• setup_authA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden and adds valuable behavioral context: 'Returns immediately after opening the browser. You have up to 10 minutes to complete the login.' It also includes troubleshooting steps that imply potential issues like browser conflicts. However, it doesn't detail error handling or return values, keeping it from a perfect score.

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

  Conciseness3/5

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

  The description is front-loaded with core functionality, but the troubleshooting section adds length that may not be essential for every use. Sentences earn their place by providing practical advice, but it could be more streamlined, e.g., by integrating troubleshooting into a separate note.

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

  Completeness4/5

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

  Given no annotations and no output schema, the description compensates well by explaining the tool's behavior, usage context, and troubleshooting. It covers authentication flow and sibling differentiation. However, it lacks details on return values or error responses, which would be helpful for an agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no specific parameter information beyond what's in the schema, such as explaining 'show_browser' or 'browser_options' usage. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific purpose: 'Google authentication for NotebookLM access - opens a browser window for manual login to your Google account.' It distinguishes from sibling 're_auth' by specifying 'first-time authentication or when auto-login credentials are not available' versus 'switching accounts or rate-limit workarounds.' The verb 'opens' and resource 'browser window' are concrete.

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

  Usage Guidelines5/5

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

  Explicit guidance is provided: 'Use this for first-time authentication or when auto-login credentials are not available. For switching accounts or rate-limit workarounds, use 're_auth' tool instead.' It also advises to 'Use 'get_health' tool afterwards to verify authentication.' This covers when to use, when not to use, and alternatives.

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

• update_notebookA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's interactive workflow (propose-confirm-execute), which is crucial behavioral context not inferable from the schema. However, it doesn't mention potential side effects like overwriting existing data 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.

  Conciseness4/5

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

  The description is well-structured with clear sections (pattern, examples, tip) and front-loads the core purpose. Every sentence serves a purpose, though the pattern section could be slightly more concise by integrating the examples more tightly.

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

  Completeness4/5

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

  For a mutation tool with no annotations and no output schema, the description provides strong contextual completeness through the interactive workflow pattern and examples. It covers the 'how' and 'when' effectively, though it could benefit from mentioning what happens on success/failure or error handling.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description lists the fields (topics, description, use_cases, tags, url) in the pattern section, but this adds minimal value beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the tool's purpose as updating notebook metadata based on user intent, specifying the verb 'update' and resource 'notebook metadata'. It distinguishes from siblings like 'add_notebook' (creation) and 'remove_notebook' (deletion) by focusing on modification of existing notebooks.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidelines through a step-by-step pattern: identify target notebook and fields, propose changes to user, and call tool only after explicit confirmation. It includes examples illustrating when to use the tool and mentions that multiple fields can be updated at once if requested.

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

• close_sessionA
  4.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a destructive operation ('Close') that terminates a session, and it provides the important behavioral guidance about asking first. However, it doesn't specify what 'closing' entails (e.g., whether data is saved or lost, whether it's reversible, what permissions are required), leaving some behavioral aspects unclear.

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

  Conciseness5/5

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

  The description consists of two concise sentences that each serve distinct purposes: the first states the core functionality, and the second provides crucial usage guidance. There is no wasted language or redundancy, and the most important information (what the tool does) is front-loaded.

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

  Completeness4/5

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

  For a destructive operation tool with no annotations and no output schema, the description does well by clearly stating the action and providing important behavioral guidance. However, it doesn't specify what happens after closure (e.g., confirmation message, error handling) or potential side effects, leaving some contextual gaps that could be important for an agent.

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

  Parameters4/5

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

  The schema description coverage is 100%, so the single parameter 'session_id' is fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, but with only one parameter and complete schema coverage, this is acceptable. The baseline for high schema coverage is 3, but the description's contextual guidance about session closure adds some value.

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

  Purpose5/5

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

  The description clearly states the specific action ('Close') and target resource ('a specific session by session ID'), distinguishing it from sibling tools like 'list_sessions' or 'reset_session'. It provides a complete verb+resource+identifier combination that leaves no ambiguity about what the tool does.

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

  Usage Guidelines5/5

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

  The description explicitly provides guidance on when to use this tool with the instruction 'Ask before closing if the user might still need it.' This creates clear context for usage and establishes a precautionary principle, helping the agent decide when this tool is appropriate versus when to seek confirmation first.

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

• list_notebooksA
  4.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It describes the operation (listing with metadata) and suggests a workflow (present options then ask), but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, or error conditions. It adds some context but lacks operational details.

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

  Conciseness5/5

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

  Two sentences with zero waste. The first sentence states purpose and output, the second provides usage guidance. Every word earns its place, and information is front-loaded appropriately.

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

  Completeness4/5

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

  Given zero parameters, no annotations, and no output schema, the description provides good context about what the tool does and how to use it. However, it doesn't describe the return format (structure of metadata) or potential limitations (e.g., maximum results), leaving some gaps for a list operation.

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

  Parameters4/5

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

  The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter information, so it appropriately focuses on usage guidance. A baseline of 4 is appropriate for zero-parameter tools when the schema is fully documented.

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

  Purpose5/5

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

  The description clearly states the verb ('List') and resource ('all library notebooks'), specifies the metadata returned (name, topics, use cases, URL), and distinguishes from siblings like 'get_notebook' (single notebook) and 'search_notebooks' (filtered search). It provides specific, actionable information beyond just restating the name.

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

  Usage Guidelines5/5

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

  Explicitly states when to use this tool ('to present options, then ask which notebook to use for the task') and implies when not to use it (when you already know which notebook to target, use 'get_notebook' instead). It provides clear context for agent decision-making.

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

• reset_sessionA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a destructive operation (resetting chat history) and specifies the session ID remains unchanged, which are important behavioral traits. However, it doesn't mention potential side effects like whether this affects other session data or if there are rate limits.

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

  Conciseness5/5

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

  The description is perfectly concise with two sentences that each serve distinct purposes: the first states what the tool does, the second provides usage guidelines. There's zero wasted language and it's front-loaded with the core functionality.

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

  Completeness4/5

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

  For a single-parameter destructive operation with no annotations and no output schema, the description provides excellent context about what the tool does and when to use it. The main gap is the lack of information about what exactly gets reset (just chat history or other session data) and what the response looks like, but the core functionality is well-covered.

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

  Parameters3/5

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

  The schema description coverage is 100%, so the schema already documents the single parameter 'session_id' adequately. The description doesn't add any additional parameter semantics beyond what's in the schema, which is acceptable given the high schema coverage.

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

  Purpose5/5

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

  The description clearly states the specific action ('Reset a session's chat history') and resource ('session'), with the clarifying detail 'keep same session ID' that distinguishes it from tools like 'close_session' which might terminate the session entirely. It provides a complete, unambiguous purpose statement.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool ('Use for a clean slate when the task changes') and includes a critical behavioral guideline ('ask the user before resetting'), which provides clear context and distinguishes it from other session-related tools like 'list_sessions' or 'close_session'.

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

• select_notebookA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool sets an active default (implying state change), is safe for auto-switching in clear contexts, and requires caution in ambiguous cases. However, it lacks details on permissions, error handling, or side effects (e.g., impact on other tools), leaving some gaps in transparency.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded, starting with the core purpose, followed by usage guidelines, auto-switching rules, and an example. Every sentence adds value without redundancy, and the bullet points enhance readability. It efficiently covers necessary information without unnecessary elaboration.

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

  Completeness4/5

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

  Given the tool's moderate complexity (state-changing with one parameter), no annotations, and no output schema, the description is mostly complete. It explains the purpose, usage, and behavioral context but omits details on return values or error cases. It compensates well for the lack of structured data, though slight gaps remain in full behavioral disclosure.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the parameter 'id' documented as 'The notebook ID to activate.' The description does not add meaning beyond this, as it doesn't specify format, source (e.g., from 'list_notebooks'), or validation rules. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Set a notebook as the active default (used when ask_question has no notebook_id).' It specifies the verb ('Set'), resource ('notebook'), and distinguishes it from siblings like 'get_notebook' or 'list_notebooks' by focusing on activation as the default. The description explicitly ties it to the 'ask_question' tool, enhancing clarity.

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

  Usage Guidelines5/5

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

  The description includes a dedicated 'When To Use' section with explicit scenarios (e.g., user switches context, asks explicitly, task change) and provides clear guidance on auto-switching vs. asking for confirmation. It distinguishes usage from alternatives by noting its role as the default for 'ask_question', helping the agent choose this over other notebook-related tools.

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

• cleanup_dataA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits: it explains the two-phase preview-then-confirm workflow, cross-platform compatibility, safety design with preview before deletion, critical browser closure requirement, and library preservation option. It doesn't mention rate limits or specific error conditions, but covers most essential behavioral aspects.

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

  Conciseness4/5

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

  The description is appropriately structured with clear sections (warning, categories, cross-platform note, preservation option, workflow, use cases). While somewhat lengthy, every sentence earns its place by providing essential information. The critical warning is front-loaded appropriately, and information is well-organized rather than repetitive.

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

  Completeness5/5

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

  Given this is a complex, potentially destructive operation with no annotations and no output schema, the description provides comprehensive context: it details what gets scanned/deleted (8 categories), safety mechanisms, prerequisites, parameters, workflow, use cases, and integration with sibling tools. For a tool with this level of responsibility, the description leaves no significant gaps.

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

  Parameters4/5

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

  With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the practical meaning of parameters: it clarifies that 'confirm=false' shows preview while 'confirm=true' executes deletion, and explains that 'preserve_library=true' keeps the notebook library.json file while deleting everything else. The recommended workflow demonstrates parameter usage in context.

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

  Purpose5/5

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

  The description clearly states the tool scans for and deletes NotebookLM MCP data files across 8 specific categories, distinguishing it from all sibling tools which handle notebook operations, authentication, or session management. It specifies 'deep cleanup' with preview functionality, making its purpose explicit and differentiated.

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

  Usage Guidelines5/5

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

  The description provides explicit usage scenarios (clean reinstall, troubleshooting auth issues, removing traces before uninstall) and a detailed recommended workflow with step-by-step instructions. It clearly states when to use this tool versus alternatives like setup_auth or re_auth for fresh sessions, and includes critical prerequisites (closing browsers).

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

• get_healthA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by describing what information is returned (health status components) and providing troubleshooting context. It doesn't fully disclose potential rate limits or detailed response format, but gives practical operational guidance.

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

  Conciseness5/5

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

  Perfectly structured with two paragraphs: first states purpose and primary use case, second provides troubleshooting guidance. Every sentence adds value with zero redundant information. The description is appropriately sized for its complexity.

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

  Completeness4/5

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

  For a zero-parameter diagnostic tool with no annotations or output schema, the description provides excellent context about what information is returned and when to use it. It could slightly improve by hinting at the return format, but covers the essential operational needs well.

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

  Parameters4/5

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

  With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and usage context.

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

  Purpose5/5

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

  The description clearly states the specific verb ('Get') and resource ('server health status') with explicit components included ('authentication state, active sessions, and configuration'). It distinguishes from siblings by focusing on system readiness rather than notebook operations or authentication management.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use guidance ('verify the server is ready before starting research workflows') and when-not-to-use alternatives (if authenticated=false with persistent issues, use cleanup_data + setup_auth instead). It directly names alternative tools for specific scenarios.

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

• re_authA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly outlines the tool's actions in a numbered list (closing sessions, deleting authentication data, opening browser for login) and details consequences like data deletion. It also covers troubleshooting steps and dependencies on other tools, providing rich behavioral context beyond basic functionality.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, usage guidelines, actions, troubleshooting) and uses bullet points for readability. However, it is moderately long due to the troubleshooting details, which, while helpful, could be considered slightly verbose. Every sentence adds value, but it's not maximally concise.

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

  Completeness5/5

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

  Given the complexity of authentication management and the lack of annotations and output schema, the description is highly complete. It covers purpose, usage scenarios, behavioral steps, troubleshooting, and references to sibling tools ('get_health', 'cleanup_data'). This provides sufficient context for an agent to understand and invoke the tool effectively without structured output details.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters ('show_browser' and 'browser_options') with their properties. The description adds no additional parameter semantics beyond what's in the schema, but it does imply the tool's primary use without parameters (e.g., default behavior for re-auth). This meets the baseline of 3 for high schema coverage.

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

  Purpose5/5

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

  The description explicitly states the tool's purpose with specific verbs ('Switch to a different Google account or re-authenticate') and distinguishes it from siblings by focusing on authentication management rather than notebook operations like 'add_notebook' or 'get_health'. It clearly identifies the resource (Google account/authentication) and action (switch/re-authenticate).

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use guidance with three bullet points covering rate limits, account switching, and broken authentication. It also references sibling tools ('get_health' for verification and 'cleanup_data' for troubleshooting) and includes a troubleshooting section with step-by-step alternatives for persistent issues, making it comprehensive for usage decisions.

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