Server Quality Checklist

Tool Scores

• get_quickmarksA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of conveying behavior. The verb 'List' clearly indicates a read-only operation with no side effects, but it doesn't add further context such as output ordering, potential authentication needs, or relationship to regular bookmarks.

  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, well-structured sentence that is front-loaded with the action and resource. Every word earns its place, and there is no wasted detail.

  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 simple list tool with no parameters and no output schema, the description is nearly complete: it states what is listed and clarifies the concept of quickmarks. A minor gap is the lack of differentiation from the sibling get_bookmarks, but overall it provides sufficient 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 tool has zero parameters, and the schema reflects this perfectly. Per baseline for 0 params, a score of 4 is appropriate; the description has no parameter details to add, but the schema already fully documents the absence of parameters.

  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 uses the specific verb 'List' and the resource 'quickmarks (named bookmarks)' in qutebrowser, making the tool's function clear. However, it doesn't differentiate from the sibling get_bookmarks, so it lacks explicit sibling differentiation.

  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?

  No guidance is provided on when to use this tool versus the similar get_bookmarks tool. The description only states what it does, not why to choose it over alternatives or any exclusions.

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

• move_tabA
  3.5/5.0
  Behavior2/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 only states the action and 'IPC only', omitting details about side effects, reversibility, required permissions, or error handling for invalid positions. For a mutation tool, this is insufficient.

  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, front-loaded sentence with no redundant words. It efficiently conveys the action, target, and a notable constraint (IPC only). Every word contributes meaning.

  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?

  For a simple tool with one parameter and no output schema, the description is adequate but minimal. It clearly states what it does but leaves gaps around behavioral expectations, such as what happens with invalid positions or whether the operation can be undone. The cryptic 'IPC only' could confuse an agent unfamiliar with the term.

  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 covers 100% of parameters with a detailed description of the position parameter (absolute, relative, end/start). The description adds the crucial context that the tool operates on the 'current tab', which explains why no tab identifier is needed. This goes beyond the schema's structural information.

  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 uses a specific verb 'Move' with a clear resource 'current tab' and a target 'position'. This clearly distinguishes the tool from siblings like focus_tab, close_tab, and open_tab. The '(IPC only)' qualifier adds implementation context without obscuring the core purpose.

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

  Usage Guidelines2/5

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

  No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention any reordering alternatives or conditions where this tool should be preferred. The 'IPC only' note hints at an internal constraint but does not explain when an agent should invoke this tool.

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

• focus_tabA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of transparency. It adds 'IPC only — this intentionally changes focus', which hints at a constraint and the primary effect. However, it doesn't clarify side effects (e.g., no page reload, no data loss) or the meaning/impact of 'IPC only' 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.

  Conciseness5/5

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

  The description is a single sentence that is front-loaded with the action. It contains no filler or redundant information, though 'IPC only' is somewhat cryptic, it is brief and does not detract from clarity.

  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 simple single-parameter tool with no output schema, the description and schema together provide sufficient context. It covers what the tool does and how the parameter works. It could benefit from a note on return behavior or preconditions, but these are not essential given the tool's simplicity.

  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 already provides a thorough description of the parameter (1-based, negative from end, 'last' for previous tab) with 100% coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 applies.

  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 action: 'Switch to a specific tab by index'. It specifies the resource (tab) and the method (by index), distinguishing it from siblings like open_tab, close_tab, and move_tab which perform different operations.

  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?

  There is no explicit guidance on when to use this tool versus alternatives. The description implies use for changing focus to an existing tab, but does not mention cases where other tools would be preferred or any prerequisites like listing tabs to get an index.

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

• get_bookmarksA
  3.8/5.0
  Behavior2/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 only states 'List all bookmarks' without mentioning whether authentication is required, if any side effects occur, or what the return format looks like. While 'List' implies a read-only operation, no additional behavioral context is given.

  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 sentence with no filler words. It is front-loaded with the verb and resource, making it highly efficient and easy to parse.

  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 simplicity (no parameters, no output schema), the description is largely complete. It specifies the action and scope ('all bookmarks'), but does not mention the return structure or whether ordering is defined. For a minimal list operation, this is nearly sufficient.

  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 zero parameters, so there is nothing to explain. The description correctly does not add parameter details. The baseline for zero parameters is 4, and no further compensation is needed.

  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 uses a specific verb ('List') and resource ('bookmarks') with context ('qutebrowser'), clearly distinguishing it from sibling tools like get_quickmarks. It is a concise and unambiguous statement of the tool's primary function.

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

  Usage Guidelines3/5

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

  The context of listing bookmarks in qutebrowser is implied, but there is no explicit guidance on when to prefer this over alternatives such as get_quickmarks or search_history. The usage is clear from the resource named, but exclusions and alternatives are not stated.

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

• go_backA
  3.8/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 transparency burden. It discloses a non-obvious behavioral trait: when 'tab' is specified, it operates via CDP without changing focus. This is useful context beyond just 'go back'. However, it does not mention other potential behaviors such as history limits, what happens when no tab is specified, or error handling, leaving some gaps.

  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 only 24 words in two sentences, front-loaded with the core purpose. Every word earns its place—there is no redundancy or verbosity.

  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 simple two-parameter tool with no output schema, the description effectively conveys the core functionality and the key tab-specific nuance. It could explicitly state that without 'tab' it operates on the current focused tab, but this is reasonably implied. Given the low complexity, it is largely 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 coverage is 100% with both parameters documented, so the baseline is 3. The description adds a small amount of semantic value by explaining the tab parameter's CDP/no-focus behavior at the tool level, but it mostly repeats the schema description. The 'count' parameter gains no additional meaning from the description.

  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 action ('Navigate back in browser history') with a specific verb and resource, and additionally distinguishes itself from the sibling go_forward by explicitly mentioning the back direction. It also adds the tab-specific behavior, making the tool's purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (when navigating back in browser history) and provides a conditional usage note for the 'tab' parameter. However, it does not explicitly contrast with go_forward or navigate, nor does it state when not to use this tool. The guidance is adequate but not explicit.

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

• go_forwardA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of transparency. It discloses the CDP behavior and the 'without changing focus' trait, which adds useful context. However, it does not mention edge cases like running out of forward history, potential errors, or return values, leaving some behavioral aspects opaque.

  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 sentences, front-loaded with the primary action, and contains no filler. Every word contributes meaning, making it highly efficient.

  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 simple navigation tool with two optional parameters and no output schema, the description covers the core operation and the notable tab behavior. It omits edge cases but remains sufficiently complete for typical use. The lack of guidance about when to use it relative to siblings slightly reduces completeness.

  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 baseline is 3. The description avoids repeating parameter details; its only parameter-related clause ('If tab is specified, operates on that tab via CDP without changing focus') mirrors what the schema already says. No additional semantic value is added beyond the schema.

  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 action: 'Navigate forward in browser history.' It uses a specific verb and resource, and distinguishes itself from siblings like go_back and navigate. The additional detail about tab targeting further clarifies its scope.

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

  Usage Guidelines3/5

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

  The description implies usage for moving forward in history but does not explicitly contrast with alternatives such as go_back or navigate. It provides context for the optional tab parameter (CDP, no focus change) but lacks explicit when-to-use or when-not-to-use guidance.

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

• reload_pageA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It adds a specific CDP detail and notes that reloading via tab does not change focus. However, it omits potential side effects like losing unsaved state and does not clarify the default target when no tab is specified.

  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 extremely concise, consisting of two short sentences that front-load the core action. Every word adds value, with no redundancy or filler.

  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 simple reload tool with optional parameters and no output schema, the description covers the main purpose and a key behavioral nuance. It could mention the default behavior (reloading the active page) and the force option (already in schema), but is largely complete for its complexity level.

  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%, as both 'tab' and 'force' have descriptive text. The tool description adds no additional information about parameters beyond what the schema already provides, so the baseline of 3 applies.

  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 function with a specific verb ('Reload') and resource ('a page'), and further specifies tab-targeting behavior via CDP. This distinguishes it from sibling navigation tools like navigate, go_back, and go_forward.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (for reloading pages) but does not explicitly compare with alternatives or state when not to use it. The optional tab parameter gives context for a specific use case, but no exclusions or prerequisites are mentioned.

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

• browser_fetchA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the request runs fetch() in the page context, inheriting cookies and auth tokens, and that it returns the response body. It doesn't mention potential CORS restrictions, redirect handling, or error behavior, but the core mechanism is transparent enough for basic understanding.

  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?

  Three concise sentences that immediately convey what the tool does, how it works, and what it returns. Zero waste, well-structured.

  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 fetch tool with full schema coverage and no output schema, the description is reasonably complete. It covers the execution model (fetch in page context, auth inheritance) and return value. It lacks discussion of edge cases like tab-not-found or CORS, but these are not critical for core 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?

  Schema coverage is 100%, so parameters are already well-documented. The description adds minimal parameter-specific insight beyond noting that the tab is matched by domain, which aligns with the 'tab' parameter's existing description. It doesn't add syntax or format details beyond the schema.

  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 it makes authenticated HTTP requests through a browser tab's session, using fetch() inside the page context and inheriting cookies/auth tokens. This distinguishes it from a plain HTTP request tool and specifies the resource (browser session) and action (fetch).

  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 implies the primary use case—accessing resources with the logged-in user's session and cookies—by explicitly mentioning 'authenticated' and 'inheriting all cookies and auth tokens.' However, it does not explicitly name alternatives like browser_fetch_auth or state when not to use this tool, so it lacks explicit exclusions.

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

• search_historyA
  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 discloses the core search behavior (URL or title) but does not mention output format, ordering, case-sensitivity, pagination, or potential rate limits. For a read-only search, the risk is low, but important behavioral details are omitted, making it minimally adequate.

  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, front-loaded sentence that efficiently communicates the purpose. Every word earns its place, with no redundancy or filler.

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

  Completeness4/5

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

  For a simple search tool with two optional parameters and no output schema, the description covers the core functionality well. The tool name and parameter schema fill in remaining gaps. However, the lack of annotations and explicit return-value details leaves some ambiguity, though it remains complete enough for typical use.

  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 coverage is 100%, meaning both parameters ('query' and 'limit') are already fully described in the input schema. The description adds no additional parameter semantics beyond restating that the query filters by URL or title, which is already present in the schema. Baseline 3 is appropriate.

  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 with a specific verb ('Search'), a clear resource ('browsing history'), and the search criteria ('by URL or title'). This accurately distinguishes it from sibling tools like get_bookmarks or navigate, though no explicit differentiation is needed since it's the only history search tool.

  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 implies when to use the tool: whenever the user needs to find items in browsing history by URL or title. It does not explicitly mention exclusions or alternatives, but the tool's unique purpose among siblings makes the context clear. Lacking explicit 'when not to use' guidance keeps it from a 5.

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

• browser_fetch_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 the full burden. It discloses that the tab is reloaded (a side effect) and that the request is made server-side, and notes the Bearer token limitation. It does not cover failure modes (e.g., no auth tokens found) or return behavior, but the disclosed side effects are significant and useful.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the core purpose, then mechanism, then limitation/example. Every sentence adds distinct value with no waste.

  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 tool with 6 params, no annotations, and no output schema, the description explains purpose, mechanism, and a limitation, but omits return format and error scenarios. It is reasonably complete but could benefit from a note on what is returned or what happens on auth capture failure.

  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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter-specific meaning beyond what the schema already provides; it only implicitly relates tab and url to the auth capture mechanism.

  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 makes an authenticated HTTP request using auth headers captured from a browser tab, distinguishing it from the sibling browser_fetch. It specifies the mechanism (reloading the tab to intercept fresh tokens) and gives an example (Outlook), making purpose unambiguous.

  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?

  Provides clear context: works for sites using Bearer tokens rather than cookies, and implies it should be used when browser_fetch would not have auth. However, it does not explicitly name browser_fetch as an alternative or state when not to use this tool, so it misses the 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.

• screenshotA
  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 the full burden. It discloses a key behavioral trait: capturing a specific tab via CDP does not switch focus. It also distinguishes the default IPC path. However, it does not mention potential side effects like file creation/overwriting or whether the capture is full-page or viewport-only, which would be additional useful 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 sentences, front-loaded with the main action, and zero wasted words. The conditional logic is conveyed efficiently without redundancy.

  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 simplicity, the description plus well-covered schema parameters are sufficient for an agent to invoke the tool. It lacks an explicit note about the output file behavior (e.g., overwriting, return value) and full-page vs viewport capture, but these are not critical gaps. Overall, it is complete enough for typical 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?

  Schema description coverage is 100%, so the baseline is 3. The description adds some conditional logic for the 'tab' parameter ('if specified') and the default behavior, but this largely mirrors the schema descriptions. It does not introduce significant new parameter semantics beyond what the schema already provides.

  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 'Take a screenshot of a page' with a specific verb and resource, and immediately distinguishes the two capture modes (specific tab via CDP vs currently focused tab via IPC). This uniquely identifies the tool among siblings like list_tabs and navigate, which have different purposes.

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

  Usage 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 each mode: 'If tab is specified' versus 'Otherwise captures the currently focused tab.' While it doesn't explicitly mention alternatives among sibling tools, there is no other screenshot tool, so usage guidance is effectively inherent. It lacks an explicit when-not-to-use statement but is otherwise informative.

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

• open_tabA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description bears full responsibility for behavioral disclosure. It explicitly discloses non-obvious behavior: the tab opens in the background and does not change focus. This adds significant value beyond the schema and is sufficient for a simple browser action, though it omits potential error cases or permissions.

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

  Conciseness5/5

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

  Two sentences, each earning its place. The first states the core action and target, the second clarifies the key behavioral nuance. No filler or redundancy. Perfectly front-loaded and 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?

  For a tool with one parameter, no output schema, and modest complexity, the description covers the essential purpose and behavior. The background-opening detail is crucial for user expectations. The sibling group includes navigation and focus tools, so the 'new tab' wording provides adequate context. Nothing critical is missing.

  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% (url has 'URL to open'), so the baseline is 3. The description's reference to 'specified URL' adds no additional meaning beyond the schema. No format, validation, or edge-case information is provided, so it stays at the baseline.

  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 uses a specific verb+resource: 'Open a new tab with the specified URL.' This clearly distinguishes it from siblings like close_tab, focus_tab, and navigate, as it explicitly denotes creating a new tab rather than modifying an existing one or navigating the current tab.

  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 by stating it 'Always opens in background (no focus change),' which implicitly tells when to use this tool instead of focus_tab or navigate. It lacks an explicit 'use this when' statement but conveys the practical scenario clearly, earning a 4.

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

• execute_jsA
  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 reveals key behavioral traits: CDP vs IPC, return value vs no return value, no focus change, and fire-and-forget nature. It does not cover error handling or potential side effects, but the disclosed information is substantial and accurate.

  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 exceptionally concise and well-structured. It leads with the core purpose in one sentence, then provides a clear conditional explanation in the second. Every word contributes value, with no redundancy or filler.

  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 and absence of an output schema, the description adequately explains return value behavior in both modes and the focus side effect. It omits details like error handling or page type restrictions, but these are not essential for an agent to invoke the tool correctly.

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

  Parameters4/5

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

  The schema already covers all three parameters with descriptions (100% coverage), setting a baseline of 3. The tool description adds meaning by explaining how the presence or absence of 'tab' alters execution mode and return value, and indirectly clarifies that 'quiet' is only relevant in IPC mode. This goes beyond the schema's individual parameter descriptions.

  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 with a specific verb and resource: 'Execute JavaScript in a page.' It distinguishes itself from all sibling tools, none of which execute JavaScript. The two execution modes (with/without 'tab') are also clearly explained, adding functional clarity.

  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 guidance on when to use each mode: with 'tab' for CDP execution returning a result, without 'tab' for IPC fire-and-forget with no return value. However, it does not explicitly mention alternative tools or exclusion criteria, 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.

• list_tabsA
  4.4/5.0
  Behavior4/5

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

  The description discloses that CDP provides fresh title/URL data and that it falls back to session file data, enriching with indices. This adds behavioral context beyond just listing and is transparent about data sourcing, especially with no annotations provided.

  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, front-loaded with the primary function, and each sentence adds value – no fluff. The structure efficiently conveys purpose and behavioral nuance.

  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 0-parameter, read-only list tool, the description covers the output fields and data-freshness behavior. It does not specify the exact return format (e.g., array of objects), but is otherwise sufficient given no output schema or annotations.

  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 zero parameters, and the description adds meaning by detailing the output fields (indices, URLs, titles, active state) and data source. With no parameters to document, the baseline is 4, and the description sufficiently compensates.

  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 'List all open tabs with indices, URLs, titles, and active state' – a specific verb and resource. It distinguishes from sibling tools that open/close/focus/move tabs by specifying a listing operation.

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

  Usage Guidelines4/5

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

  The description implies the tool is for enumerating tabs and gives no exclusions or alternatives. However, the purpose is clear enough that an agent can select it when needing an unfiltered list of open tabs; sibling tools are action-oriented, so context is clear.

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

• navigateA
  4.4/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the burden of behavioral disclosure. It clearly reveals the underlying mechanism (CDP vs IPC) and the focus-preserving nature when a tab is specified. However, it does not mention error handling, load waiting, or permission requirements, which are relevant for a navigation tool.

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

  Conciseness5/5

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

  The description is concise, consisting of two short sentences that immediately convey the core action and the two distinct navigation modes. Every word earns its place, with no redundant information.

  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 tool with only two well-described parameters, the description covers the essential behavioral distinction and does not need to explain return values absent an output schema. It omits edge cases like tab not found or navigation failure, but overall it is sufficiently complete for its complexity.

  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 already describes both parameters well (tab as URL/title substring with CDP semantics, url as target URL). The description adds a conditional relationship between them, explaining that the choice of transport depends on whether tab is provided, which enriches the parameter semantics beyond what the schema states.

  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 it navigates a tab to a URL, and explicitly distinguishes between navigating a specified tab via CDP and the current tab via IPC. This differentiates it from sibling tools like open_tab or reload_page, which serve different navigation purposes.

  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 explicit guidance on when to use the tab parameter (to navigate a specific tab without changing focus via CDP) versus when to navigate the current tab via IPC. It does not name alternatives such as go_back or reload_page, but the context makes the appropriate use clear.

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

• close_tabA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description bears the full burden and discloses important behavioral traits: CDP does not change focus, while IPC fallback will briefly change focus. This is beyond the obvious 'close' action and helps the agent anticipate side effects.

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

  Conciseness5/5

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

  Two concise clauses within one sentence, front-loaded with the action and resource. Every word contributes information without redundancy.

  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?

  For a simple two-parameter tool with no output schema or annotations, the description covers the core action, both invocation mechanisms, and the key behavioral difference (focus change). It is sufficiently complete for an agent to use effectively.

  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 already provides descriptions for both parameters, but the tool description adds the crucial distinction that 'tab' uses CDP (no focus change) and 'index' uses IPC (focus change). This enriches the semantic meaning beyond the raw schema.

  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 closes a tab, with the specific mechanism of matching by URL/title via CDP and an IPC index-based fallback. It is distinct from siblings like focus_tab or open_tab.

  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 implies when to use each mode (CDP for non-focus-changing close, IPC fallback when index is needed) and notes the side effect of focus change. It does not explicitly contrast with alternatives like focus_tab, but the context is clear enough.

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