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 input format but doesn't mention what happens on success/failure, whether the click waits for navigation, whether it scrolls the element into view, or any side effects. For a mutation-like interaction tool, 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.

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

One short sentence that front-loads the action and immediately explains the target format. No wasted words.

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

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

The tool has a single parameter with full schema coverage and an output schema exists, so the description doesn't need to explain return values. However, for an interaction tool with no annotations, it would benefit from stating behavior like waiting for page load or error conditions. It's adequate but not complete.

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

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

Schema coverage is 100%, so the schema already documents the target parameter well. The description adds a concise summary of the two accepted formats, but doesn't add much beyond the schema's own description. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Click') and resource ('an element'), and clarifies the two ways to identify the target (snapshot ref number or locator string). It doesn't explicitly differentiate from sibling tools like browser_hover or browser_type, but the action 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.

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

The description implies usage: use it when you need to click an element, and the target can be a ref or locator. It doesn't explicitly state when not to use it or mention alternatives like browser_hover for non-click interactions, but the context is reasonably clear.

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

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

With no annotations, the description fully discloses the behavioral consequences: it forgets all state (tabs, refs, console log) and behaves differently in CDP mode. This adds significant value beyond the minimal 'close browser' and warns agents of state loss and mode-specific behavior.

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

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

Two sentences with zero filler. The main action is front-loaded, and the CDP-mode exception is a separate, necessary sentence. Every word contributes to the agent's understanding.

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

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

For a zero-parameter tool with an output schema, the description fully covers what an agent needs to know: the shutdown action, the state loss details, and the CDP-mode deviation. Nothing crucial is missing.

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

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

The input schema has zero parameters and 100% coverage, so there are no parameter semantics to explain. Per the baseline for tools with no parameters, a score of 4 is appropriate; the description appropriately focuses on behavior instead.

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

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

The description uses a specific verb ('shut down') and resource ('browser') and explicitly states the scope ('forget all state (tabs, refs, console log)'). It distinguishes itself from siblings like browser_tab_close by indicating this closes the entire browser rather than a single tab, and from navigation tools by the shutdown action.

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

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

The description gives clear context about when this tool is relevant—ending a browser session—and provides the CDP-mode caveat that it detaches instead of closes. It does not explicitly name alternatives or state when not to use it, but the purpose is unambiguous enough for an agent to infer appropriate usage.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'Return' strongly implies a read-only operation, but the description does not explicitly state that the console is left intact or define what 'recent' means. This is a moderate gap for a tool that reads browser state.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase adds meaning: the action, the resource, the recency constraint, and the severity categories.

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

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

For a one-parameter, no-annotation read tool with an output schema, the definition is largely sufficient. The only minor omissions are an explicit no-side-effect statement and a precise definition of 'recent,' both unlikely to block correct invocation.

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

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

The only parameter, level, is fully described in the schema with allowed values and a default. The description's mention of 'errors, warnings, logs' aligns with those levels but adds no real semantic detail beyond what the schema already provides, so the baseline 3 applies.

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

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

The description names a specific action ('Return'), a concrete resource ('recent browser console messages'), and the message categories included. Among the browser_* siblings it is clearly the only console-inspection tool, so an agent can distinguish it without opening the schema.

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

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

The intended use is clear: call this when you need recent console errors, warnings, or logs during browser automation. It does not explicitly contrast with sibling tools or state when not to use it, but for a simple diagnostic read operation the context is sufficiently clear.

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

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

With no annotations, the description carries the burden, and it does disclose the core trait: arbitrary JavaScript executes in the page context and its result is returned. However, it does not explicitly warn that arbitrary JS can mutate page state or cause side effects, nor does it cover promise/async handling, which is a real gap for this powerful tool.

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

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

It is two sentences with one compact example; the core behavior is front-loaded and no words are wasted. The example is concrete and directly illustrates both a simple expression and an object-returning expression.

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

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

For a one-parameter tool with full schema coverage and an output schema, the description is nearly complete: it states what the tool does, where it runs, and when to prefer it. The missing caution about side effects and async behavior keeps it from being fully complete, but these are not blocking for the primary scraping use case.

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

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

Schema description coverage is 100% for the single js parameter, so the schema already documents what to pass and the JSON-serializable return constraint. The description adds a useful expression example and the scraping use case, but it does not substantially extend parameter semantics beyond the schema.

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

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

The description opens with a specific verb and resource: 'Run arbitrary JavaScript in the page and return the result.' It also differentiates itself from sibling browser tools by saying it is for scraping data the accessibility snapshot cannot express, so an agent can distinguish it from browser_snapshot and the DOM-interaction tools.

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

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

It gives an explicit use case: scraping data the accessibility snapshot cannot express, which points to browser_snapshot as the main alternative. It does not state exclusions such as 'do not use for navigation or clicking' or compare itself with browser_click/type, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It does disclose that the action targets the active tab and changes history position, but it does not mention edge behavior such as what happens when there is no previous history, whether navigation waits for page load, or whether the tab state may change.

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

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

The description is a single clear sentence with no filler or redundant information. Every word contributes to the meaning, and it is as concise as a zero-parameter tool requires.

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

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

For a zero-argument tool with an output schema, the description provides enough information to call it correctly. The main gaps are the lack of explicit sibling differentiation and edge-case behavior, but these are minor for such a simple operation.

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

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

The tool has zero parameters, so the schema trivially covers everything. The description correctly avoids inventing parameter details, and with no parameters to document, the baseline of 4 is appropriate.

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

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

The description uses a specific verb ('Navigate') with a specific resource ('active tab') and direction ('back in history'). This clearly distinguishes it from the sibling browser_go_forward and browser_navigate tools, so an agent can tell them apart without opening the schema.

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

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

The intended usage is implied: use this tool when you want to move backward in the browsing history of the active tab. However, it does not explicitly name browser_go_forward as the counterpart or state when not to use browser_navigate, leaving the routing to inference.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions the operation but does not disclose what happens when there is no forward history (e.g., no-op, error), whether the browser state changes, or any side effects. This is a significant gap 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.

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

The description is a single, clear sentence with no redundant words. It is front-loaded with the action and target, and every word earns its place. This is ideal conciseness.

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

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

Given the tool's simplicity (zero parameters, no required inputs), the description covers the basic purpose. However, with no annotations and an output schema present, it may be incomplete regarding return values or error behavior, which an agent might need for robust handling. Still, for a simple action, this is minimally adequate.

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

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

The tool has zero parameters, and schema coverage is 100% (vacuously). The description correctly implies that no parameters are needed, as it specifies the operation is on the active tab. No further parameter clarification is required, so a baseline of 4 is appropriate.

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

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

The description 'Navigate the active tab forward in history' clearly states the action (navigate) and the target (active tab, forward in history), distinguishing it from browser_go_back which moves backward. While it doesn't explicitly mention the browser context, the verb and resource are specific enough for basic understanding.

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

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

The description implies usage (when you want to go forward in navigation history), but does not provide explicit guidance on when to use this versus browser_go_back or when it is inappropriate (e.g., no forward history). No alternatives or exclusions are mentioned, so it meets the minimum viable threshold but lacks explicit routing to siblings.

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

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

With no annotations, the description bears full responsibility for disclosing behavior. It explicitly states the core side effect of moving the cursor, but it does not mention timing, whether hover state persists, or whether it waits for menus/tooltips to appear.

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

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

The description is a single efficient sentence with the action front-loaded and a relevant use-case parenthetical. Every word earns its place.

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

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

This is a simple one-parameter tool with an output schema, so the description does not need extensive detail. The action, target type, and intended purpose are clear enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, and the target parameter is already described as 'Snapshot ref or locator.' The description adds no extra semantic detail beyond the schema, which is acceptable given the high coverage.

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

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

The description opens with a specific verb and resource: 'Move the mouse cursor over an element.' The parenthetical '(for hover menus/tooltips)' clarifies the intended use case and distinguishes this from sibling tools like browser_click.

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

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

The parenthetical gives a clear context for use, but the description does not explicitly state when not to use this tool or name an alternative such as browser_click. Usage guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does disclose the key side-effect: conditional page creation versus active-tab navigation. It does not mention loading or waiting behavior, but for a simple one-parameter navigation tool this is reasonably transparent.

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

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

Two concise sentences with no wasted words. The first states the core action, and the second adds the essential conditional behavior, making the definition easy to parse quickly.

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

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

For a one-parameter tool with an output schema, the description covers the essential behavior: open a URL and what happens with or without an existing page. A brief pointer to browser_tab_new for forced new-tab behavior would improve completeness, but it is not strictly required for correct calling.

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

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

The schema already provides 100% coverage for the single url parameter, so the baseline is 3. The description's 'Full URL to open' largely echoes the schema's property description and adds no additional semantic detail.

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

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

The description uses a specific verb and resource: 'Open a URL in the browser.' It also distinguishes its behavior from related tools by explaining that it creates a page if none exists and otherwise navigates the active tab.

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

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

There is clear behavioral context: a page is created only if none exists, otherwise the active tab is navigated. However, it does not explicitly mention when to prefer browser_navigate over siblings like browser_tab_new, browser_go_back, or browser_go_forward, so guidance on alternatives is only implied.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the key press targets the currently focused element, whether it can trigger navigation or other side effects, or any error behavior. This is a significant gap for a tool with zero annotation coverage.

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

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

The description is two concise sentences. The primary action is front-loaded, and the alternative guidance is valuable without redundancy. Every word earns its place.

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

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

For a simple one-parameter tool with an output schema, the description covers the essential action and provides a key usage distinction. It lacks a few behavioral details (e.g., focus requirement, side effects), but it is largely sufficient given the tool's simplicity.

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

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

The schema already documents the 'key' parameter thoroughly, listing named keys and single characters. The description adds no additional meaning beyond the schema. With 100% schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the action with a specific verb and resource ('Press a keyboard key on the page'). It explicitly differentiates from the sibling tool browser_type by noting that Enter after typing should use browser_type(..., enter=True), which helps the agent distinguish between the two tools.

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

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

The description provides an explicit when-not-to-use instruction: for Enter after typing, use browser_type instead. This gives clear guidance for one common scenario, though it does not mention other alternatives or general when-to-use criteria beyond the core action.

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

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

With no annotations provided, the description carries the full burden. It discloses the key behavioral aspect that the image is not shown to the model, and it states what is returned (absolute path and size). This is transparent and useful, though it could have mentioned file overwrite behavior or error conditions.

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

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

The description is concise, two sentences, with the core purpose and key exclusion front-loaded. Every sentence contributes value, and the structure is clear and scannable.

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

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

The description covers the main output (file path and size) and explicitly states it does not show the image, which is critical for an agent. While it doesn't mention prerequisites like needing a loaded page or error handling, the output schema likely covers return details, and the tool is simple enough that this is sufficient.

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

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

Schema description coverage is 100%, so the parameters are already documented. The description adds minimal extra meaning beyond the schema, such as referencing the screenshot directory. Since the schema covers the parameters, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's action (take a screenshot), the resource (current viewport), and the output format (PNG). It explicitly distinguishes from browser_snapshot by noting it does not show the image to the model, which differentiates it from the sibling tool.

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

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

The description explicitly tells the agent when to use this tool versus the alternative: 'Does NOT show the image to the model — use browser_snapshot for content.' This provides a clear routing decision and prevents misuse.

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

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

With no annotations provided, the description carries the behavioral transparency burden. It communicates the action and the two accepted match modes (value or label), but does not disclose details such as multi-select behavior, what happens on no match, or whether page events are triggered.

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

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

The description is a single, readable sentence that immediately conveys the action and target. There is no redundant information or filler.

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

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

For a simple two-parameter browser interaction tool, the combination of a clear description, complete schema coverage, and an available output schema provides enough context for an agent to invoke it correctly. Minor edge-case details, such as multi-select handling, are absent but not critical for basic usage.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (target and values) well. The description's mention of 'by value or label' adds slight context for the values parameter but does not go beyond the schema meaningfully.

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

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

The description states a specific verb ('Select') and resource ('an option in a dropdown (<select>)'), and clarifies that selection can happen by value or label. This clearly distinguishes it from sibling tools like browser_click or browser_type, which handle other interaction types.

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

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

The intended use is implied by the tool name and description: use it when you need to choose an option in a dropdown. However, it does not explicitly state when not to use it or mention any alternatives, so the guidance relies on inference.

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

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

No annotations are provided, so the description must carry the behavioral burden. It does disclose the key behavior: outputs a numbered accessibility tree with [ref] prefixes. However, it omits other important behavioral details such as whether it changes the page state (it likely does not, but that's not stated), the size or format of the output (beyond the accessibility tree), and the fact that the refs are volatile across actions. The suggestion to 're-run after every action' implies, but does not explicitly state, that refs become stale, which is a critical behavioral trait.

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

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

The description is short and front-loaded with the core purpose. The first sentence states the main function. The following sentences explain the [ref] convention and the recommendation to re-run, which are essential usage notes. It is efficient, though it could be slightly more explicit about behavior, but it earns a 4 for concise and purposeful structure.

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

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

The output schema is present, so the description doesn't need to explain return values in detail. The description covers the core functionality, the ref system, and the guidance to re-run after actions. Missing are explicit details on output size limits (though max_nodes hints at it), staleness warning, and state safety. However, given the presence of the output schema and the tool's relatively simple nature, it is mostly complete.

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

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

The schema for max_nodes is fully described (10-400, default 240), so the description does not need to add meaning. Since schema_description_coverage is 100%, the baseline score is 3. The description adds no additional parameter context, but it is not required; the schema is sufficient.

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

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

The description clearly states the tool's function: reading the current page as a numbered accessibility tree. It specifies the resource (current page) and the format (accessibility tree), and explains the unique [ref] numbering system, which distinguishes it from siblings like browser_screenshot or browser_status.

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

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

The description explicitly instructs when to use the tool: after every action, to get the current state. It also explains how to use the output: pass a ref to other browser_* tools that accept a target. This provides clear both timing and integration guidance, exceeding the baseline.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the tool reports state, implying it is non-destructive, but it does not explicitly confirm read-only behavior or describe what happens if no browser is running (e.g., error vs. empty response). This is a minor gap for a status-check tool.

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

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

Two sentences with zero waste. The primary purpose is front-loaded, and the usage guidance follows naturally. Every word earns its place.

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

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

Given the simplicity (0 params, output schema present) and the clear scope, the description is largely complete. It does not detail error behavior for a missing browser, but this is a minor omission for a status tool that likely returns a clear signal.

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

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

The tool has zero parameters, so the schema trivially covers 100%. There is nothing to add; the description does not need to elaborate on parameters. Baseline 4 is appropriate for no-parameter tools.

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

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

The description clearly states the verb 'Report' and the resource 'browser state' with specific details (current page URL, title, open tab list). It is not a tautology and is distinguishable from siblings like browser_tabs by its scope, though it does not explicitly name alternatives.

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

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

The description explicitly provides a usage scenario: 'Use this first if you are unsure whether a browser is running.' This gives a clear context for when to invoke the tool, though it does not explicitly mention when not to use it or name alternatives.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. The description states that it 'Defaults to the active tab,' which is a behavioral detail, and the parameter schema clarifies that omitting index closes the active tab. However, it doesn't disclose other relevant behaviors, such as what happens when the last tab is closed, whether the browser exits, or how the tab index is validated (e.g., what if index is out of range). For a destructive operation like closing a tab, more transparency would be beneficial.

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

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

The description is two short sentences, both of which are essential. It front-loads the core action and immediately clarifies the default behavior. There is no redundancy or unnecessary detail; every word earns its place. This is an example of concise, efficient writing.

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

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

Given the simplicity of the tool (1 optional parameter, no nested objects) and that an output schema exists, the description is fairly complete for basic usage. However, it lacks context on edge cases (e.g., closing the last tab, invalid index) or interaction with sibling tools. For a destructive tool, an agent might need to know these behaviors, but for simple tab close, this is adequate.

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

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

The schema has 1 parameter, but schema_description_coverage is 0% because the parameter 'index' has a description. However, the parameter description is minimal ('Tab index to close; omit to close the active tab.'). The tool's description adds the 'defaults to active tab' behavior, which complements the schema. Since there's only one parameter and the schema already explains it, the description adds little beyond reinforcing the default behavior. A score of 3 is appropriate as the schema is sufficient but not richly detailed.

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

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

The description clearly states a specific verb ('Close') and resource ('browser tab'), and specifies the default behavior (active tab). It is concise and unambiguous, though it doesn't explicitly contrast with sibling tools like browser_tab_switch or browser_tab_new. The name itself is fairly descriptive, but the description adds the key 'defaults to active tab' detail, which is not in the name.

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

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

The description implies usage by stating it closes a tab and defaults to the active tab, but it doesn't explicitly state when to use this tool versus alternatives like browser_tab_switch (to switch tabs) or browser_tab_new (to open a tab). For an agent, the context of closing is clear, but there is no guidance on selection among siblings, such as 'use browser_tab_switch to switch tabs'.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal that the tool opens a tab and switches focus, but it omits other useful context such as what happens to the current tab, whether page load is awaited, or any error behavior. It adds little beyond the name itself.

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

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

The description is a single short sentence that is front-loaded with the primary action and contains no filler. Every word contributes to understanding the tool's core function.

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

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

Given the tool's low complexity, one optional parameter, and a present output schema, the description covers the essential behavior well. The only notable gap is that it leaves some usage context—like when to prefer this over browser_navigate—to the agent; otherwise it is nearly complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; the URL parameter is already documented as 'URL to open in the new tab.' The default of about:blank is only present in the schema, not reinforced in the description.

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

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

Description states a specific action—open a new browser tab—and adds that it switches to it, which distinguishes it from siblings like browser_tab_switch and browser_navigate. The verb and resource are explicit and the behavior is unambiguous.

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

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

No guidance is given about when to use this tool versus alternatives such as browser_navigate for in-place navigation or browser_tab_switch for moving to an existing tab. The intended context is only implied, not stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' implies non-mutating read-only behavior and the field enumeration adds some value. However, it does not disclose ordering, whether the list spans all browser contexts, or whether any side effects apply; the description is adequate for a simple list tool but not rich.

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

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

The description is one short sentence that immediately gives the operation and the returned fields. Every word earns its place and no structured data is repeated.

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

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

Given the tool has no parameters and an output schema exists, the description covers the necessary invocation details for an agent. The main gap is the lack of explicit context about which tabs are considered 'open' and whether tab ordering is relevant, but this is minor for such a low-complexity, no-parameter tool.

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

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

The input schema has zero parameters, so the description does not need to compensate for parameter documentation; it correctly focuses on return content instead. Since there are no parameters to explain, the baseline of 4 is appropriate.

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

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

The description states a specific verb and resource ('List open browser tabs') and specifies exactly what is included in the result ('index, title and URL'). This is clearly distinguishable from sibling tools like browser_navigate or browser_snapshot, and there is no tautology or ambiguity about its scope.

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

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

The description offers no guidance on when to use this tool versus alternatives such as browser_status, browser_snapshot, or browser_tab_new, and no mention of browser context scope (e.g., current window vs all windows). The tool should either be paired with explicit when-to-use guidance or explicit exclusions, but none are present.

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

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

With no annotations, the description carries the burden, but it only conveys that the tool switches to an existing tab. It does not disclose behavior on invalid index, whether browser focus changes, or return value; however, 'switch to' implies selection/activation, providing minimal guidance.

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

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

One sentence with no filler, front-loaded with the action verb and resource, and efficiently references the tab source. Every word earns its place.

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

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

For a single-parameter tool with an output schema, the description is mostly complete. It lacks edge-case or error behavior context, but the schema and simple operation reduce the need for extensive prose.

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

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

Schema description coverage is 100% and already documents the index as 0-based and sourced from browser_tabs(). The description repeats this without adding new semantic detail beyond what the schema provides.

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

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

The description uses a specific verb ('Switch') with a clear resource ('existing tab') and source ('by its index from browser_tabs()'). It plainly distinguishes this tool from siblings like browser_tab_new and browser_tab_close by emphasizing 'existing'.

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

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

It states the key precondition: obtain the index from browser_tabs(). This implies the workflow without explicitly naming alternatives or when-not-to-use conditions, though 'existing tab' rules out new-tab creation.

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

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

With no annotations, the description carries the full disclosure burden. It does add one useful behavioral trait—replacing current content—but it doesn't mention focus behavior, waiting, or whether the action can fail for non-visible fields. This is adequate but not rich.

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

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

A single, front-loaded sentence with no filler. The key behavior is stated before any detail, and every word earns its place.

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

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

For a simple action with a complete input schema and an output schema present, the description is nearly sufficient: it names the action, the target, and the replacement behavior. The only real gap is the absence of sibling-routing guidance.

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

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

Schema description coverage is 100%, so the parameters (text, enter, target) are already meaningfully documented. The description adds no extra parameter semantics beyond saying the text replaces existing content, so the baseline of 3 applies.

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

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

The description states a specific verb ('Type'), a resource ('input field'), and a defining behavior ('replacing its current content'). This clearly distinguishes browser_type from siblings like browser_press_key or browser_click.

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

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

No guidance is given about when to prefer this tool over siblings such as browser_press_key or browser_evaluate, and no exclusions or alternatives are mentioned. The usage context is only implied by the action itself.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly communicates that the tool blocks until text is visible or the timeout expires, but it does not disclose what happens on timeout, whether it polls, or what 'visible' means beyond the schema's substring-match note.

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

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

A single sentence with no filler: it names the action, the target condition, and the termination condition. The most important information is front-loaded.

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

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

For a simple two-parameter wait tool with full schema descriptions and an output schema present, the description covers the essential behavior. The main gap is the unspecified post-timeout behavior, but the phrase 'or the timeout runs out' at least signals that the operation terminates.

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

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

The input schema already describes both parameters fully: the text is a substring match and the timeout has a default, maximum, and minimum. The description adds no new parameter-level meaning, so the baseline of 3 for 100% schema coverage is appropriate.

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

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

The description states a specific verb ('wait'), a specific resource ('a piece of text becomes visible on the page'), and a clear ending condition ('or the timeout runs out'). It distinguishes this from the sibling browser_wait_for_timeout, which waits for a fixed duration rather than for a condition to be satisfied.

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

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

The description implies the use case—blocking until text appears on the page—but does not explicitly say when to prefer it over browser_wait_for_timeout or how it relates to navigation and snapshot tools. There is no exclusionary guidance or named alternative.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Wait a fixed amount of time,' which is minimal. It doesn't disclose that the wait is blocking (preventing other operations), whether the wait is exact or subject to timing variations, or any side effects. This is a significant gap for a tool that pauses execution.

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

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

The description is a single sentence with no unnecessary words. It is front-loaded with the core action ('Wait a fixed amount of time') and then adds a helpful parenthetical example. It could be slightly more descriptive about behavior, but it is appropriately concise for such a simple tool.

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

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

Given the tool's simplicity (one parameter, no nesting), the description is somewhat minimal. However, the presence of an output schema (not detailed) and the clear parameter description help. But for a tool that causes a time delay, an agent would benefit from knowing that the wait is synchronous and potentially affects the current page state. Missing behavioral context lowers the score.

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

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

Schema description coverage is 100%, so the parameter 'ms' is fully documented in the schema. The description does not add any nuance beyond what the schema provides (e.g., that it's a wait duration). The description does mention 'fixed amount,' which reinforces the parameter's meaning, but adds little extra value.

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

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

The description states the tool waits a fixed amount of time, with a clear verb ('wait') and resource. It includes examples of use cases (page sleeps/progress bars), which adds clarity. It does not explicitly differentiate from siblings, but the siblings are mostly navigation/interaction tools, not other wait tools.

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

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

The description provides clear use cases ('page sleeps/progress bars') which imply when to use this tool. It doesn't explicitly state when not to use it, but the context of sibling tools (like browser_wait_for_text) suggests an alternative wait mechanism, though the description doesn't mention it directly.

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