Server Quality Checklist

Tool Scores

• get_console_logsC
  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 doesn't mention that capturing logs requires an attached/claimed tab, whether logs are cleared, what happens when no active tab exists, or the format of returned messages (severity levels, sources, etc.).

  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?

  A single sentence, zero wasted words. Immediately states the function and default scoping.

  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 tool with no annotations and no output schema, this is thin. Given the sibling context (browser automation suite with tab management, eval_js, cdp tools), a richer description would clarify how console logs relate to evaluated JS, whether logs persist across navigations, and what the return shape looks like.

  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 the schema already documents both parameters (limit with default, optional tab_id). The description adds minimal value beyond what the schema provides—it confirms 'active tab' as the default target when tab_id is omitted, but adds no additional format or behavior details.

  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 states a clear verb ('Return') plus a specific resource ('console log messages') scoped to 'the active tab'. It's clear what the tool does, though it doesn't explicitly differentiate from siblings like cdp_events or snapshot which could overlap conceptually.

  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 on when to use this tool vs alternatives. It mentions 'active tab' implying usage context, but doesn't explicitly state when to choose this over eval_js or cdp_send, nor any prerequisites like needing a claimed/active tab.

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

• name_sessionB
  3.1/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 states the visible effect (shown in UI) but doesn't disclose whether this affects tab claims, filtering, or any backend behavior. The connection between session name and tab ownership/claiming isn't clarified given the presence of 'claim_tab' among siblings.

  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?

  A single, clear sentence that fully conveys the tool's purpose with zero wasted words. The parenthetical mention of where the name is displayed is efficient and adds context without bloat.

  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 single-parameter setter with 100% schema coverage and no output schema, the description is mostly adequate. However, given the complexity of the sibling tool ecosystem (many browser management tools), a brief note on whether the session name affects operations like claim_tab or list_tabs would improve 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 coverage is 100%, and the description indicates the parameter represents a display name. However, it only says 'Short session name' in the schema and the description doesn't add format constraints, length limits, or character restrictions that would enhance agent understanding beyond what the schema 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 verb (Set), resource (browser session name), and where it's displayed (Codex/Chrome UI), making the tool's purpose unambiguous. It doesn't explicitly distinguish from siblings, but given the sibling list contains browser control tools, the session-naming purpose is clearly differentiated by its unique resource scope.

  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 on when to use this tool versus alternatives. The naming purpose is implicit but there's no statement about when naming a session is appropriate or helpful. Among many browser tools, there's no contextual framing for why one would set a session name.

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

• screenshotB
  3.1/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 does not mention output format, image encoding (base64 vs file path), what happens if no tab is active, permission requirements, or other behavioral traits. The description only restates core function without additional transparency beyond parameter names.

  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 concise sentence with no wasted words. It's appropriately short for a two-parameter tool. However, given the thin information content, one might argue it does too little, but for the information it conveys, it is efficiently structured and front-loaded with the primary action.

  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?

  This is a capture/mutation tool with no annotations and no output schema. The description doesn't explain what the output looks like (image format, where it's stored), which is a significant gap for a tool whose entire purpose is producing output. Given the low complexity (2 optional params), it's understandable but still under-specified for an agent needing to use the returned data.

  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 (tab_id and full_page). The description references tab_id but adds no detail beyond the schema's own descriptions. Baseline 3 applies since schema does the heavy lifting and the description doesn't add extra param meaning.

  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 'Capture a screenshot of the active tab (or tab_id)' uses a clear verb (Capture) and resource (screenshot of active tab). It distinguishes from siblings like snapshot (likely DOM/AX tree snapshot) and clarifies the tab scoping. Could more explicitly differentiate from 'snapshot' but the active-tab phrasing is reasonably distinct.

  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 it captures the active tab but does not state when to use it versus 'snapshot' or the browser_exec/eval_js alternatives for capturing content. No explicit when-to-use or when-not-to-use guidance, no mention of prerequisites like needing a page loaded. Minimal context for choosing between screenshot and snapshot.

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

• press_keyB
  3.2/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 burden. It discloses the core behavior (pressing keys together as a chord at the current focus) and gives examples. However, it doesn't reveal potential side effects, whether keys can be special/unsupported, whether the action blocks, or behavior when nothing is focused. For a relatively simple input tool the disclosure is adequate but thin.

  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 compact sentence with useful inline examples. It's front-loaded and every word earns its place. Slightly could be more structured but at this length it's concise and clear.

  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 low-complexity tool with 2 params (1 required), full schema coverage, and no output schema, the description is fairly adequate. It explains the core action and gives examples. However, it's missing guidance that would help an agent decide when keyboard input is appropriate vs type_text, and doesn't hint at what key names are valid (which could matter since keys array has free-form strings). The tab_id parameter's purpose (identifying which context) is left to schema only.

  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 documents both parameters fully (keys with items description, tab_id as optional). The description adds the chord concept ('press together') and example key names, which enriches the keys parameter slightly. But it adds nothing beyond what the schema provides for tab_id. Baseline 3 is appropriate given full 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 verb and resource: 'Press a key or chord at the current focus.' It gives concrete examples (['Enter'], ['Control','a']) that clarify the action. However, it doesn't explicitly differentiate from sibling tools like click or type_text, though the distinct action (keyboard input vs clicking) is reasonably self-evident.

  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 doesn't explain when to use press_key vs alternatives like type_text or click. It mentions 'at the current focus' which implies it operates on the currently focused element, but gives no guidance on prerequisites (e.g., needing a focused element/tab first), no comparison with type_text, and no exclusions. The context is implied but not explicit.

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

• type_textB
  3.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 explains the focusing behavior (click first), which is useful, but doesn't disclose side effects — whether typing replaces existing content, whether it triggers events/submission, or whether the selector case requires visibility. For an interaction tool with no annotations, this is a notable gap.

  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?

  One sentence, front-loaded with the core verb ('Type text'), and immediately clarifies the two modes of operation. Zero filler — every phrase earns its place. This is an ideal length for a simple action tool.

  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 3-param typing tool, the description covers the core mechanics: selector usage and focus behavior. However, given no annotations and no output schema, it would benefit from disclosing side effects (e.g., whether existing element content is replaced, whether it dispatches events). It's adequate for basic use but lacks behavioral depth for edge cases.

  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 documents all three parameters. The description adds meaning to the selector param (fills that element) and clarifies the no-selector case (types at current focus), which goes slightly beyond the schema. However, text and tab_id get no additional elaboration beyond what's already in the schema, so the added value is moderate.

  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 states a clear purpose: type text, with a selector filling that element or typing at current focus. It distinguishes itself via the selector/current-focus dichotomy, though it doesn't explicitly differentiate from sibling tools like press_key or eval_js. The verb+resource is specific enough for an agent to select it conceptually.

  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 gives a clear when-to-use: fill a specific element with a selector, or type at current focus (implying click first). However, it doesn't explicitly explain when to choose this over press_key or browser_exec, nor does it mention prerequisites like page load or focus state beyond the 'click first to focus' hint. No when-not-to-use guidance is given.

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

• new_tabB
  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 full burden. It says 'controlled tab' (implying browser automation context) and that it becomes active, but doesn't disclose side effects like what happens to the previous active tab, whether tabs are tracked, or what 'controlled' means operationally. 'Creating a tab' implies it won't destroy anything, but this is inferred rather than stated.

  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?

  Single sentence, zero waste. Every element earns its place: creation, control, optional URL, active-tab behavior. Front-loaded with the primary verb and action.

  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?

  The tool is relatively simple with one optional parameter and no output schema. The description covers the core behavior well. However, with no annotations, some behavioral context is missing - specifically the operational meaning of 'controlled' and whether opening a new tab has implications for the session. Given simplicity, this is adequate but could clarify tab lifecycle behavior.

  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?

  Schema coverage is 100% for the single param, so baseline is 3. The description adds value by clarifying that the URL is optional and that the tool navigates to it as part of tab creation, which is meaningfully more than the schema's 'Optional URL to open.'

  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 verb (Create), resource (controlled tab), and primary action (make it the active tab). It mentions optional URL navigation. However, it doesn't explicitly distinguish from sibling tools like list_tabs, goto, or claim_tab, though the core purpose is clear enough.

  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 this is for opening a new tab versus navigating an existing one (goto), but doesn't explicitly state when to use this vs alternatives. No exclusions or when-not-to-use guidance. The contrast with goto is implied but not stated.

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

• finalizeA
  3.5/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 discloses that the tool cleans up session tabs and optionally keeps specific tabs with statuses 'deliverable' or 'handoff.' It does not disclose what happens to tabs not listed in 'keep' (presumably closed), whether the browser process terminates, or any confirmation/prompt behavior. It adds the key behavioral trait—tab cleanup with selective retention—but details on consequences are thin.

  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, tight sentence that conveys purpose, scope, and the optional keep functionality in under 20 words. Zero waste. It front-loads the main action ('End browser work') before the supporting detail about keeping tabs open.

  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 one-parameter tool with no output schema and full schema coverage, the description is adequate. However, it could clarify what happens to the browser session (is it destroyed? Can tabs be recovered after finalize?) and the meaning of the two status values ('deliverable' vs 'handoff') beyond the enum names. Given sibling tools like list_tabs and name_session exist, the description could benefit from explaining the relationship to session management.

  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%, and the 'keep' parameter has a clear description: 'Array of { tab_id, status } to keep open.' The description reinforces this by mentioning keeping tabs open with statuses 'deliverable' or 'handoff,' which maps directly to the enum in the schema. Since the schema already fully documents the parameter and the description echoes it, baseline 3 is appropriate—the description adds minimal beyond the schema.

  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: 'End browser work for now, cleaning up session tabs.' The verb 'finalize' combined with 'End browser work' makes the function unambiguous. It adds the scoping detail of cleaning up tabs and optionally keeping specific ones, which distinguishes it from the many browser navigation siblings.

  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 says this tool 'ends browser work for now,' which implies it should be used when wrapping up a browsing session. However, it doesn't explicitly say when NOT to use it or name alternatives—e.g., it doesn't contrast with name_session (for labeling) or list_tabs (for inspecting). The context of 'cleaning up session tabs' gives some situational guidance but no explicit exclusions.

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

• gotoA
  3.5/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 transparency burden. It does disclose that it can create a tab as a side effect when none is active, which is valuable. However, it doesn't disclose other behavioral traits like whether navigation replaces the current page context, whether it's destructive to page state, or whether a return/stale-tab situation is handled.

  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, both earn their place. First states the primary action, second handles the edge case of no active tab. Zero wasted words and appropriately front-loaded.

  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 2-parameter navigation tool with 100% schema coverage and a clear output-less model, this is mostly complete. However, it could benefit from clarifying the distinction from new_tab and fetch_url given the large sibling set, and from noting whether this tool blocks until page load or returns immediately. These are modest gaps.

  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 fully documents both parameters (url and tab_id). The description adds the nuance that tab_id is used when provided, otherwise the active tab is used. This is a mild addition but mostly restates what the schema already conveys with 100% 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 states a clear verb+resource: navigates a tab to a URL. It identifies the active tab as default target and mentions creating a tab if none is active. However, it doesn't explicitly distinguish from siblings like new_tab (which creates a tab) or fetch_url (which fetches without navigating), though the scope is reasonably clear.

  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 instruction 'Creates a tab if none is active' provides some guidance on the non-existent-tab scenario. However, it lacks explicit when-to-use vs when-not-to-use guidance, and doesn't mention when to use new_tab vs goto or how it relates to siblings like fetch_url or browser_exec for navigation purposes.

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

• clickA
  3.7/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 behavioral burden. It discloses reliability caveats for selector/text approaches, which is useful. However, it doesn't describe what happens on failure (no element found, multiple matches), whether clicks wait for navigation, or the return value/response format since there's no output schema.

  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, zero waste. Front-loaded with the primary action, then delivers a prioritized parameter recommendation in the second sentence. Every phrase earns its place.

  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?

  This is a moderately complex tool with 6 parameters, no output schema, and no annotations. The description covers the action and parameter-preference ranking well, but for a tool with multiple parameter mechanisms and no return-value documentation, it could note what the tool returns or signals on success/failure. Sibling list is rich, so some context on when to use click vs type_text/press_key/goto would improve 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 coverage is 100% with all 6 parameters documented in the input schema (x/y coords, text, tab_id, node_id, selector). The description adds value by ranking these mechanisms by reliability (node_id/coords preferred over selector/text). It doesn't add syntax or format details beyond schema, but the prioritization guidance is genuinely useful. Baseline 3 is appropriate given full 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?

  Description states specific verb+resource ('Click on the active tab') with clear scoping. It distinguishes itself slightly from sibling tools by its action (click vs navigate/type/snapshot), though it doesn't explicitly name alternatives. The mechanism guidance about node_id vs coordinates vs Playwright selector adds useful operational context.

  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?

  Description provides clear guidance on which parameter forms to prefer (node_id or x+y over selector/text) and why (Playwright may be less reliable when Codex shares the page). This is actionable, though it doesn't explicitly state when NOT to use click or name alternative tools—selecting among siblings (goto, type_text, press_key) is left implicit.

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

• list_user_tabsA
  3.7/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 burden of behavioral disclosure. It discloses ordering ('newest first'), scope ('across windows'), and authenticity ('real open Chrome tabs'), which is useful. However, it doesn't mention whether this is a safe read operation, latency implications, or whether it could trigger any tab-querying 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 sentences, zero wasted words. Front-loaded with the action and scope, followed by a practical usage pointer. Every clause carries meaning.

  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 tool with no output schema, the description is reasonably complete: it states what is returned (real tabs, newest first, cross-windows), how to act on results (id with claim_tab), and the tool's role in the workflow. It could name the sibling list_tabs explicitly to clarify the distinction, but the 'real' qualifier and claim_tab guidance offer enough 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, so there is nothing to document beyond the schema. The description appropriately focuses on output semantics (real tabs, ordering, cross-window), which is the primary semantic content the agent needs. Baseline 4 applies for 0-param tools.

  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 verb ('List'), resource ('user's real open Chrome tabs'), and scope ('across windows', 'newest first'). It distinguishes from siblings by specifying 'real' open tabs (vs list_tabs which may be a generic abstraction) and noting cross-window coverage.

  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 gives a clear usage pointer ('Use an entry's id with claim_tab to take control'), indicating the tab listing is a precursor to claiming. However, it doesn't explicitly distinguish when to use this vs list_tabs, nor does it state any exclusions or alternate contexts.

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

• cdp_eventsA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full behavioral burden. It discloses the buffered nature (truncation semantics), pagination cursors, return shape, and the full CDP access prerequisite. The description does well on eviction behavior and child target discovery, but doesn't mention rate limits, memory/fetch cost, or side effects of consuming events. It's solid but not exhaustive.

  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 dense but compact paragraph, front-loaded with purpose and access path. It packs pagination protocol, truncation semantics, child target discovery, and a prerequisite into ~4 sentences with no wasted words. Could be split for readability but is appropriately sized for the 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?

  This is a complex streaming/cursor-based tool with 7 params and no output schema, so the description must cover return semantics and usage protocol, which it does (cursor, hasMore, truncated). It explains pagination and child target discovery thoroughly. It falls slightly short on edge cases like how methods filtering interacts with pagination or what happens with timeout_ms when no match, but is largely complete for agent invocation.

  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, and the schema already documents all 7 parameters. The description adds context for after_sequence (cursor pagination semantics) and mentions methods/target_id/session_id indirectly through 'Discover child target selectors'. But it doesn't significantly extend parameter meaning beyond the schema beyond the cursor usage.

  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 reads CDP events from a tab via the cdp tab capability, with a precise resource (buffered CDP events) and access path (cdp tab capability, active tab or tab_id). It also names return schema fields, distinguishing it from siblings like cdp_send (which sends) and get_console_logs (which fetches console-specific logs). This is a specific verb+resource.

  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 gives clear operational context: how to page (use after_sequence while hasMore is true), what truncated means, and how to discover child target selectors. It mentions a prerequisite (full CDP access enabled). However, it doesn't explicitly state when NOT to use this tool or name alternatives for related tasks, though the child-target discovery note and cursor pagination guidance are genuinely useful.

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

• snapshotA
  3.9/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 burden. It discloses that it returns a 'filtered DOM listing' (indicating non-exhaustive output) and that node ids are used for later interaction. However, it doesn't disclose behavior like whether it scrolls, whether it captures only visible elements, potential performance cost on large pages, or whether it reflects the full DOM or just the current viewport.

  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 sentences with zero wasted words. The first sentence states what's returned and the second gives actionable usage guidance. Highly efficient and front-loaded with the core purpose.

  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 read-only introspection tool with one optional param and no output schema, the description is reasonably complete. It tells the agent what it gets and how to use the results. However, it doesn't clarify whether the 'filtered DOM listing' includes only clickable/interactable elements or also structured data about page state, and the absence of an output schema means the description could have explained the shape of the returned node ids more.

  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 only one optional param (tab_id) documented in the schema itself. The description adds the 'active tab' default behavior. With a single well-documented optional parameter and high schema coverage, the baseline 3 is appropriate; the description adds minimal additional meaning 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?

  Description clearly states the verb (Return), the resource (active tab's url/title/DOM), and specific scope (interactable elements with node ids). It distinguishes itself from siblings like screenshot (visual) and list_tabs (tab listing) by focusing on DOM interactable elements. The reference to node_id and click tool also differentiates its purpose.

  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 explicitly instructs using node_id with the click tool, providing clear downstream usage context. It implies snapshot is the precondition for interaction workflows. However, it doesn't explicitly state when NOT to use it or name a specific alternative (like when to use eval_js instead), though the sibling context makes this fairly inferable.

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

• list_tabsA
  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 must carry the behavioral disclosure burden. It communicates the read-only nature implicitly ('List') and clarifies scope against sessions, but doesn't disclose output format, ordering, or whether it reflects live state vs cached state. For a read operation, the disclosure is adequate though minimal.

  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?

  Single sentence, zero waste. Every word earns its place, and the phrase 'currently controlled by this browser session' adds meaningful scope qualification beyond a generic 'list tabs'.

  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 parameterless read-only listing tool with no output schema, the description is reasonably complete. It would benefit from mentioning what fields are returned per tab, but given the simple nature of the operation, the explanation is adequate. The sibling distinction (list_user_tabs) is the main context gap.

  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 with 100% schema coverage, so the baseline is 4 per the rubric. The description adds context about what 'tabs' means in this tool's scope (session-controlled), which clarifies the semantics of the implicit query being performed.

  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 clear verb+resource structure: 'List tabs currently controlled by this browser session.' It specifies the scope (session-controlled tabs) and distinguishes itself from the sibling tool list_user_tabs, which presumably lists tabs belonging to a different context/user.

  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 gives clear context about scope ('currently controlled by this browser session') but does not explain when to prefer this over list_user_tabs or claim_tab. The distinction from list_user_tabs is implied by the phrase 'this browser session' but not made explicit with guidance on which to choose.

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

• browser_execA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses that code runs in the MCP server's Node process (vs sandboxed in-page), that images returned/emitted are attached, and that `tab` defaults to current/selected or null. It does not mention error handling, consequences of throwing, or side-effectful behavior like navigation or tab mutation, but it makes the execution context clear.

  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?

  Two sentences, well-structured: the first scopes what's in scope, the second explains execution context and the escape-hatch role. The lead sentence is dense but the inline backtick list of namespaces is efficient. Minor redundancy with sibling names but no wasted prose.

  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?

  This is a power-user tool with no output schema and no annotations, so the description needs to cover execution environment, scope, and return behavior — which it does thoroughly. It could mention error/exception behavior and what happens with non-JSON returns, but for the stated purpose the description is reasonably complete given the tool's inherently flexible nature.

  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?

  Schema coverage is 100% and it has only 2 simple params. However, the description adds valuable context: `tab_id` binds as `tab`, and the `code` param is described as an 'Async function body' with an example (`return await tab.title();`). This exceeds baseline by providing execution model detail for the code parameter.

  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?

  Clear verb+resource: 'Run arbitrary async JavaScript against Codex's Chrome API.' It explicitly lists the in-scope namespaces (`agent`, `browser`, `tabs`, `user`, `tab`, `console`, `log`) and states it's the 'full-power escape hatch', which distinguishes it from sibling tools like eval_js (sandboxed) and cdp_send (CDP-level).

  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 on when to use it: when full control over the Chrome API is needed, beyond structured tools. It distinguishes from eval_js ('in-page JS must go through tab.playwright.evaluate, sandboxed') and notes Node APIs work here. However, it doesn't explicitly state 'don't use this when a simpler tool suffices' or list alternatives for common operations, slightly reducing the guidance completeness.

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

• claim_tabA
  4.1/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 burden of behavioral disclosure. It does state the effect (making the tab active), which is the key behavioral outcome. However, it doesn't disclose additional behaviors like whether it steals focus from the user, whether it changes the tab's position, or whether there's any impact on other open tabs beyond activation. The core mutation is disclosed but edge behaviors are not.

  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 conveys purpose and origin of the parameter without wasted words. It could arguably include a bit more guidance but there is zero fluff. Slightly more content (like what happens after claiming) would be valuable, but as written it's tight and front-loaded with the core action.

  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 covers the essential context: what it does (makes tab active), where the id comes from (list_user_tabs). Given the low complexity (1 param, no nested objects, no output schema), this is reasonably complete. It could mention whether the tool also brings the tab into a visible window, but for a simple action tool this is adequate.

  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 description adds meaning to the single 'id' parameter by specifying its source (list_user_tabs) and implicitly distinguishing it from other tab IDs possibly from list_tabs. While schema coverage is 100% (the schema already explains 'id from list_user_tabs'), the description confirms the semantic meaning that this id is for an existing user tab, adding slight value 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 verb (take control), the resource (existing Chrome tab), and the specific action (make it the active/foreground tab). The parenthetical note 'id from list_user_tabs' ties the source of the required parameter to a specific sibling tool, distinguishing it from other tab operations. This is a specific, well-scoped 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 Guidelines4/5

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

  The description names the prerequisite source (list_user_tabs) for the id parameter, which gives some usage context. However, it doesn't explicitly state when NOT to use this tool versus siblings like list_tabs, new_tab, or goto. There's clear context but no exclusionary guidance about alternatives.

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

• browser_documentationA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, but the tool is a read-only documentation lookup with zero parameters, so behavioral disclosure needs are minimal. The description accurately conveys it returns reference material and is non-destructive by nature, though it doesn't describe output size or format.

  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, zero waste. The first sentence defines the deliverable precisely and the second provides actionable guidance. Every word earns its place, and it's appropriately front-loaded with the core purpose.

  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 documentation-retrieval tool with no output schema, the description is complete for its function. The only minor gap is not describing what the returned documentation contains structurally (code snippets, examples, etc.), but given the tool's simple nature, this is adequate.

  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 with 100% schema coverage (there are no parameters to document). Per the rubric, 0 params = baseline 4. The description appropriately doesn't need to add parameter semantics since there are none to explain.

  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 returns the full Chrome (browser use) API reference for the live browser/tab object graph. The verb 'Return' plus specific resource ('full Codex Chrome API reference') makes the purpose unambiguous, and it's clearly distinguished from siblings which are operational browser tools.

  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 includes an explicit instruction to 'Read this before writing browser_exec code,' which establishes its role as a prerequisite for a sibling tool. It provides clear context for when to use it, though it doesn't enumerate exclusions or describe when NOT to use it relative to other documentation sources.

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

• cdp_sendA
  4.3/5.0
  Behavior3/5

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

  No annotations were provided, so the description carries the full behavioral burden. It does disclose meaningful behavioral traits: CDP is scoped to the tab's current origin, attaching shows the 'started debugging' bar, and it requires full CDP access enabled. However, it doesn't describe what the response looks like, failure modes, or the relationship between session_id vs target_id and target_id. Decent disclosure but not exhaustive for a raw power tool.

  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 well-structured paragraph front-loaded with the core purpose, followed by practical usage notes. Every sentence earns its place, but it's slightly dense—four sentences packed with guidance. Still appropriately sized for a complex low-level tool; 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?

  Given no annotations and no output schema, the description covers a lot: prerequisites, origin scoping, event observation pattern, and higher-level alternatives. For a complex 6-parameter tool with nested objects and no output schema, this is reasonably complete, though it could clarify response/return semantics and error behavior. The description compensates well for the missing structured metadata.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the tab_id targeting mechanism and how cdp_events/cursor interplay works with sending commands, which goes beyond the schema's bare descriptions. It also explains the session_id/target_id distinction contextually with 'attached child target.' Though the high-level event workflow is described, it doesn't elaborate on params semantics beyond what the schema 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 is specific: it sends a raw CDP command to the active tab or specified tab via the browser's cdp capability, explicitly scoped for developer/debugging use. It clearly distinguishes this low-level tool from the 'higher-level tools for ordinary automation.' The verb+resource+scope are all precise.

  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?

  Excellent guidance: tells users to navigate to the intended http(s) page first, explains origin scoping, warns about the 'started debugging' bar, explicitly says to prefer higher-level tools for ordinary automation, and describes the cdp_events cursor workflow for observing events. Also notes the full_cdp_access_enabled prerequisite. This is thorough when-to-use/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.

• eval_jsA
  4.5/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 and does substantial work: it discloses the READ-ONLY sandbox, the fetch/DOM-mutation/setInterval restrictions, the window allowlist, JSON projection depth/size limits, top-level await support, and the chrome-error:// page warning. This is rich behavioral disclosure for a tool with zero annotations, missing only explicit reversibility/permission details.

  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 information-dense and front-loaded with the core purpose, then progresses to constraints and usage guidance. It's longer than minimal but every sentence adds unique value (limitations, alternatives, warnings), with no filler or 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 absence of annotations and output schema, the description compensates well: it covers the return projection limits, sandbox constraints, network-data alternative, and edge-case warning. It doesn't describe exact return value shape or error behavior, but the tool's expressed behavior is adequately specified for a 2-param evaluator with no output schema.

  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 has 100% coverage, so baseline is 3. The description adds meaningful value beyond the schema: it elaborates on the 'code' parameter by explaining it can be an expression OR `() => ...` function source, and that top-level await is supported. It also clarifies invocation semantics beyond mere parameter names.

  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+resource: 'Evaluate JavaScript in the page via Playwright and return the result'. It distinguishes from siblings by specifying JSON-projection limits (depth<=8, strings<=200k chars) and the READ-ONLY stripped sandbox, which differentiates it from browser_exec and related automation tools.

  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 specifies when to use this tool (DOM reads, getComputedStyle, scrolling) and when NOT to (no fetch/network, no DOM mutation), explicitly directing users to 'use fetch_url or goto for network data'. This gives clear alternatives among siblings.

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

• fetch_urlA
  4.5/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 the session reuse (user's cookies), that it avoids touching the active tab, that it may fail in specific environments, and names the fallback path. It doesn't describe return format (but no output schema exists), yet the key behavioral traits are covered.

  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 dense, single-block paragraph that front-loads the core purpose and mechanism first, then usage guidance, then failure modes. It's information-rich with no filler, though slightly long; the sentence combining purpose and fallback is efficient. Minor structure improvement possible by splitting into sub-points.

  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 moderately complex tool with 3 params, no output schema, and no annotations, the description covers purpose, usage context, parameter options, failure modes, and fallback - a thorough treatment. It doesn't describe the return structure, which would be valuable, but the core usage decision is well covered.

  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?

  Schema coverage is 100% and each parameter has a schema description (defaults, enum values, batch-size advice). The description adds meaningful context about content_type values ('text', 'html', 'domSnapshot') and reiterates the batching constraint, going slightly beyond schema to explain practical usage.

  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+resource ('Fetch rendered content for one or more URLs') and specifies the mechanism (via browser.tabs.content, using the user's Chrome session without touching the active tab). It distinguishes itself from siblings like goto+scroll+snapshot and eval_js by positioning it as a faster bulk/JSON fetching approach.

  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 it ('ideal for JSON endpoints or reading pages in bulk') and when NOT to ('fall back to goto + eval_js' if tabs_content is unsupported or content-blocker blocks). It also contrasts with goto+scroll+DOM scraping as the slower alternative, giving clear decision guidance.

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

• scrollA
  4.7/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 behavioral burden. It discloses that it 'returns before/after scroll position, pageHeight, and nearBottom' and reveals a key behavioral nuance about virtualized lists skipping content. It does not explicitly state side effects or whether it's read-only, but for a scroll tool this is largely inferable. It adds meaningful behavioral context beyond the bare operation.

  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 front-loads the core purpose in the first sentence, then uses a compressed but readable enumeration of modes, and ends with a single practical caveat about virtualized lists. Every sentence earns its place; there is no filler or repetition. Appropriately sized for a 7-parameter multi-mode tool.

  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?

  Despite having 7 parameters and no output schema, the description is remarkably complete: it explains all four invocation modes, discloses return values (before/after scroll position, pageHeight, nearBottom), and provides guidance on the trickiest scenario (virtualized lists). Given the tool's moderate complexity and lack of annotations/output schema, this is thorough enough for an agent to select and invoke 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?

  Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema by grouping parameters into distinct usage modes (node_id for scroll containers, x+y for wheel events, selector for scrollIntoView). It also clarifies that scrollY is the primary delta with a default of 600, contextualizing the parameter semantics beyond raw field 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 opens with a specific verb+resource: 'Scroll the active tab by a delta (positive scrollY scrolls down).' It then enumerates four distinct modes (page scroll, node_id container, x+y wheel-at-point, selector scrollIntoView), clearly distinguishing this scrolling tool from siblings like goto, click, and eval_js. The purpose is unambiguous and well-scoped.

  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 lists when to use each mode: 'pass node_id to scroll inside a specific scroll container, x+y to send a mouse wheel at a viewport point, or selector to scrollIntoView a specific element.' It also provides proactive guidance on virtualized lists, recommending small steps and extraction between steps. This is explicit, actionable usage guidance superior to most tool descriptions.

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