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

Annotations are absent, so the description carries the full burden. It discloses the action ('Call') but not side effects, validation behavior, possible errors, authentication needs, or response format. Calling a raw CDP method can mutate browser state, but the description does not warn about this.

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 filler. The main purpose is front-loaded, and the note about `params` as kwargs is directly relevant and compact.

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?

Although the input schema is simple, the absence of annotations, output schema, and usage context makes the description thin. It does not explain return values, errors, or when this raw tool should be preferred over the dedicated sibling tools, so the agent is left under-informed for 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?

Schema coverage is 0%, so the description must compensate. It adds one useful semantic detail: `params` are passed as keyword arguments. However, it provides no guidance on `method` values, how to construct params, or the relationship between the two, leaving meaningful gaps.

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 specifies the exact verb ('Call') and resource ('raw Chrome DevTools Protocol method'), and the word 'raw' clearly distinguishes it from the high-level sibling tools like browser_click or browser_navigate. An agent can immediately understand this is a low-level passthrough rather than a convenience operation.

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 for when to use this tool versus the many provided browser helpers. There is no mention of 'use this when no high-level tool exists' or any warning about when it is inappropriate, leaving the decision entirely to the agent.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the core action and button options. However, it never clarifies the coordinate system (viewport vs. page, device vs. CSS pixels), the side effects of clicking (navigation, form submission), or the behavior of the `clicks` parameter, leaving meaningful ambiguity for a mutating action.

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

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

Two short sentences, action first, with no wasted words. It is appropriately front-loaded, though it is lean enough to omit the `clicks` parameter entirely, which a slightly expanded description could have covered without becoming verbose.

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

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

The tool is simple (4 params, no output schema), so the description only needs to enable a correct basic call — which it does for x/y and button. But since there are no annotations and no output schema, the description is the sole behavioral source, and its silence on `clicks` semantics and the coordinate-system meaning leaves gaps an agent could trip on.

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 0%, so the description must compensate; it does add meaning to x/y ('screen coordinates') and to `button` (left/right/middle). But `clicks`, an integer parameter with default 1, is never explained — the agent cannot tell whether it means double-click or repeat count — and no ranges or pixel semantics are given for x/y.

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 — 'Click at screen coordinates (x, y)' — which is unambiguous and tells the agent this is a coordinate-based mouse action rather than an element- or key-based one. It also adds meaning to `button` by enumerating 'left'/'right'/'middle'. It stops short of a 5 because it never names sibling tools (e.g., browser_js or browser_press) to explicitly carve out 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?

No guidance is given on when to choose this tool over alternatives: browser_js/browser_cdp can trigger clicks programmatically, browser_press handles key presses, and browser_fill targets form fields, yet none of these routing decisions are addressed. There are no prerequisites, exclusions, or context hints, so the agent gets no information beyond the tool's own name.

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 present, so the description carries the full burden. It discloses the destructive action and the active-tab default, but it does not explain whether closing is reversible, what happens if it is the last tab, or what response the tool returns.

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

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

Two short sentences with no filler. The main action and the default behavior are stated directly and concisely, with the most important conditional behavior 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?

The default invocation is fully described and the operation is simple. However, for non-default usage with a target, the agent is left guessing about the target value's format, and with no output schema there is no stated expectation of return behavior.

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?

With 0% schema coverage for target, the description must compensate. It adds meaning by explaining the null case ('closes the active tab'), but it does not define what a string target value should be or where to obtain it, such as a tab ID.

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?

States the exact verb and resource: 'Close a tab.' It immediately clarifies the default behavior ('Without target, closes the active tab'), which also distinguishes it from tab-creation and navigation siblings like browser_new_tab and browser_switch_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?

Provides clear invocation context by explaining what happens when target is omitted. It does not explicitly name alternatives or when-not-to-use conditions, but the intended usage is unambiguous for this simple operation.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states what is returned, but does not mention potential side effects (likely none) or error conditions (e.g., no active tab). For a simple read operation this is adequate 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.

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

The description is a single, concise sentence that immediately states the tool's purpose. There is no unnecessary information, and the key output fields are 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?

Given the low complexity (no parameters, no output schema), the description provides enough information: it lists the three return fields. It does not elaborate on types or edge cases, but for a straightforward getter, it is sufficiently complete.

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

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

The tool has zero parameters, and the baseline for such cases is 4. The description does not need to explain parameters, and the schema is already empty. No additional parameter semantics are required.

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 (Return) and the resource (the active tab's targetId, url, title). It is specific and distinct from siblings like browser_list_tabs (lists all tabs) and browser_page_info (likely more detailed page info). The purpose is immediately understandable.

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 need current tab metadata, but it does not explicitly state when to prefer this over alternatives or when not to use it. No exclusions or alternative references are provided, though the context of 'active tab' makes the primary use case 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 of behavioral disclosure. It clearly discloses the conditional tab switch, but leaves 'stale' undefined and does not explain what happens if no real tab exists or how the replacement tab is chosen. Core behavior is stated, but side-effect details 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.

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

One sentence carries the action, target, and trigger condition with no filler. It is front-loaded 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 zero-parameter, no-output-schema utility, the description supplies the key context: when to run it and what it accomplishes. Slight ambiguity in 'stale' is the only notable gap.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to add. The 100% schema coverage makes this trivially complete, and the baseline of 4 applies.

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

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

The description uses a specific verb ('Switch') with a clear resource ('real (non-internal) tab') and an explicit condition ('if the current one is chrome:// or stale'). This distinguishes it from browser_switch_tab and other navigation tools. The purpose is immediately obvious.

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 exactly when to invoke the tool: when the current tab is an internal chrome:// page or is stale. It does not name alternatives or state when not to use it, so it falls short of a full 5, but the trigger condition is 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 full burden for behavioral disclosure. It only states the basic fill operation but does not mention side effects (e.g., clearing the field, triggering events), behavior on missing selectors, or whether it replaces existing text. The clear_first parameter is not mentioned, so the agent is unaware of the default clearing 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?

The description is a single, efficient sentence with no fluff. It is front-loaded with the action and key parameters. However, it could be slightly more structured to include parameter details without losing 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 simplicity of the tool, the description is still incomplete. It lacks information about the optional clear_first parameter, error handling, and differentiation from siblings like browser_type. With no output schema and no annotations, the agent has insufficient context to call the tool reliably.

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 0% description coverage, so the description must compensate. It explains selector and text implicitly but omits clear_first entirely. It also does not specify selector syntax (CSS, XPath) or any constraints on text. This leaves a required parameter undocumented in any form.

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 (fill), the resource (an input matched by selector), and the payload (text). It is a specific verb+resource but does not distinguish from sibling browser_type, which might also interact with inputs. Still, the purpose 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 on when to use this tool versus alternatives like browser_type. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage.

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

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 mentions 'Returns the navigation result' but provides no details on whether it waits for page load, error handling, or side effects like history updates. The tool mutates state (navigation), yet the description gives no safety or blocking information. This is a significant gap for a mutation 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, front-loaded sentence with no filler. It states the action and the return value efficiently. 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 tool's complexity (simple navigation) and lack of annotations and output schema, the description is inadequate. It omits critical details like whether navigation blocks until page load, what the 'navigation result' contains, and how errors are surfaced. The existence of sibling browser_wait_for_load suggests this tool may not wait, but that's not clarified. An agent would need more context to use it reliably.

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 0%, so the description must compensate. It says 'Navigate the current tab to `url`', which adds that the parameter is the destination. However, this is essentially restating the parameter name and adds no format, constraints, or examples. The description barely adds meaning beyond the parameter name itself.

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 ('Navigate') on a specific resource ('current tab') and specifies the target as 'url'. This distinguishes it from siblings like browser_new_tab (which opens a new tab) and browser_switch_tab (which changes focus). No ambiguity.

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 for navigating the current tab to a URL, but does not explicitly state when to prefer it over alternatives (e.g., browser_new_tab, browser_switch_tab). There is no exclusion or guidance on when not to use it, leaving the agent to infer based on the name and 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 carries the full burden of behavioral disclosure. It does state that the tool is browser-less and returns the response body, which are meaningful behavioral traits. However, it does not mention how non-2xx responses are handled, whether redirects are followed, or the effect of the timeout parameter—leaving notable gaps for a network call.

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 with no filler. The core action and result are front-loaded, and the optional header detail is presented right after. Every word earns its place, and the structure makes the tool easy to scan.

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 GET tool with no annotations and no output schema, the description covers the basic purpose and result but falls short on critical context. The timeout parameter is entirely unexplained, and error/redirect behavior is absent. The description is not complete enough for an agent to use the tool confidently in edge cases.

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 0%, so the description must compensate for all parameters. It explains headers well ("Optional `headers` dict for authentication or custom request headers"), but it entirely omits the timeout parameter, including its units and meaning, and url is left to be inferred. This is insufficient for a tool with three undocumented parameters.

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 and resource: "HTTP GET `url` (browser-less)" and names the result ("Returns the response body"). The "browser-less" qualifier distinguishes it from the browser-navigation siblings like browser_goto and browser_js, leaving no ambiguity about what this tool does.

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 context by saying "browser-less", signaling that this is for raw HTTP requests without a browser, but it never explicitly names alternatives or states when not to use it. An agent can infer the when, but it lacks the direct routing that would earn a 4 or 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 bears the full burden of disclosing behavior. It says the expression is evaluated but does not mention that JavaScript can mutate the page, whether a result is returned, how asynchronous expressions are handled, or what errors may surface. For an arbitrary-JS-execution tool this is a meaningful 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?

The description is a single compact sentence with no filler. It front-loads the core operation and handles the iframe variant in a parenthetical, with every word earning 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?

With no annotationsaint, no output schema, and incomplete parameter semantics, the description is too sparse for an eval tool. It omits the return behavior, constraints on expressions, and the exact meaning of `target_id`. An agent could call it safely only by guessing at these important details.

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

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

Schema description coverage is 0%, so the description must compensate. It adds that `target_id` refers to an iframe, but it does not clarify whether `target_id` is an id, a selector, or a frame reference, nor does it explain how `expression` results are returned or formatted. The addition is marginal beyond the schema's own property titles.

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 ('Evaluate') and a clear resource ('a JavaScript expression in the current tab'), with an explicit iframe variant via `target_id`. This distinguishes the tool from browser-level sibling tools such as browser_goto or browser_cdp.

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 clearly scopes the tool to the current tab and identifies the iframe condition via `target_id`. It does not explicitly name alternatives or when not to use it, but the intended context is clear enough for an agent to select it over 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 provided, the description must carry behavioral disclosure. 'List' conveys a read-only operation with no side effects, but it does not describe the return shape or whether the current tab is identified. More detail would reduce ambiguity.

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 four-word sentence states the operation with no filler. It is front-loaded and easily parsed by an agent.

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, non-destructive list operation, the description is largely complete for invocation. The lack of an output schema means a note on return format (e.g., tab IDs/titles, active tab) would be a minor improvement, but nothing necessary to call the tool 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 tool has zero parameters, so the description has no parameter burden. The baseline of 4 applies because there is nothing to document beyond the already-complete empty 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 uses a specific verb ('List') and a clear resource ('open page tabs'), making the operation unambiguous. The plural phrasing distinguishes it from sibling tools like browser_current_tab and browser_switch_tab, even without naming them.

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

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

The intended use is implied: call it when a list of all open tabs is needed. However, it gives no explicit guidance about when to prefer browser_current_tab or browser_switch_tab, or any exclusion criteria.

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 full responsibility for behavioral disclosure. It states the return value (targetId) but does not explain whether the new tab becomes active, whether it opens in the background, what happens with invalid URLs, or any side effects on the current tab. For a tool with no annotation coverage, this is insufficient.

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

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

A single, direct sentence with no filler. The key action and return value are front-loaded. Optimal length for 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 is simple (one optional parameter, no output schema, no annotations), the description is minimally adequate. It states the action and the return. However, it lacks context on how the new tab interacts with the existing browsing session (e.g., does it become active? is it added to the tab list?). For an agent that needs to manage multiple tabs, this is a notable gap.

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 0% – the 'url' parameter has no description in the schema. The description does not mention the parameter at all, leaving the agent to infer that 'url' is the address to open. Since it is optional and defaults to 'about:blank', the agent might not know the meaning or format expected. The description adds no value 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?

States a specific verb 'Open' and resource 'a new browser tab'. Clearly distinguishes from sibling tools like browser_goto (which navigates existing tab) and browser_switch_tab (which switches to an existing tab). The purpose is unambiguous.

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

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

The description implies the tool is for creating a new tab, but does not explicitly state when to use it versus alternatives (e.g., when you want to keep the current tab intact). It does not mention that this is the tool to use for a fresh browsing context or that it should be used when you need a separate targetId for later operations.

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 bears the full burden of disclosing side effects. It correctly implies a read-only operation but does not explicitly state that it makes no changes to the page or that it may fail if no tab is loaded. It only lists return fields without addressing error handling or edge cases, but for a simple metadata fetch the essential behavior is conveyed.

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 zero filler. The purpose and returned data are in the first clause, making it immediately scannable. 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 tool's simplicity (no parameters, no output schema), the description sufficiently covers what an agent needs to call it: it names the exact data items returned. It does not specify the output structure (e.g., nested vs flat), but that is a minor gap for a metadata retrieval tool, and the listed fields imply a clear contract.

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?

There are no parameters, so schema coverage is trivially 100%. The description correctly adds no parameter information because there is nothing to document. Per the rubric, a zero-parameter tool earns a baseline of 4, and the description does not detract from that.

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 ('Return') and the target ('current tab metadata'), and enumerates the specific data fields it provides (url, title, viewport, scroll sizes). This unambiguously differentiates it from sibling tools like browser_screenshot or browser_list_tabs, which serve different purposes.

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 no timing or alternative-selection guidance. It does not mention when to prefer this over browser_current_tab, browser_list_tabs, or any other sibling, nor does it state any prerequisites (e.g., an open tab). An agent must infer its use case solely from the name.

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 must disclose behavioral implications, but it only says 'Press a key' and defines modifiers. It does not state that the key press targets the focused element, may trigger navigation or shortcuts, or whether it waits for resulting page changes.

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 extremely concise, leads with the core action, and every word is informative. No filler or redundancy.

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

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

For a tool with no annotations and no output schema, this description is too thin. It lacks usage context, key-value guidance, and behavioral expectations, leaving an agent to guess at critical details for 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?

Schema description coverage is 0%, so the description must compensate. It fully explains the modifiers bitfield values (1=Alt, 2=Ctrl, 4=Meta, 8=Shift), which is valuable, but it does not specify accepted key strings or syntax for the required key parameter.

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 phrase 'Press a key' clearly identifies the action as a keyboard key press, which distinguishes it from siblings like click, type, and fill at a basic level. However, it does not explicitly state that it acts on the current page or name alternatives, so it falls short of a 5.

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 when-to-use or when-not-to-use guidance is provided; the description never mentions alternatives like browser_type or browser_click. An agent must infer when browser_press is appropriate instead of being told.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully adds that omitting path uses a temp file and that max_dim downscales results, which go beyond the schema. However, it does not explain what the `full` parameter does or what the return value looks like, leaving a meaningful behavioral gap for a tool with no annotation coverage.

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

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

The description is three short sentences with no filler. The core action is front-loaded, and every sentence adds a meaningful detail: format, path behavior, and max_dim behavior. It is appropriately sized for 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?

The description is minimally viable for a basic screenshot invocation, especially because all parameters are optional and the tool has no required inputs. However, the lack of an output schema and the absence of any explanation of the `full` parameter mean the description is not fully complete for edge cases like full-page captures or understanding the returned artifact.

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 0%, so the description must explain parameters itself. It covers path and max_dim clearly, but it never mentions the `full` parameter, which remains unexplained despite being part of the input schema. This is helpful but incomplete.

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 'Capture a PNG screenshot' states a specific verb and resource, making the tool's purpose immediately unambiguous. It also distinguishes itself from sibling browser tools by naming the output format (PNG) and the action (screenshot), leaving no room for confusion with navigation or recording 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 makes the core use case clear—when a screenshot is needed—but it does not explicitly discuss when to prefer this over sibling tools like browser_page_info or browser_start_recording. The usage context is implied rather than stated, and no exclusions or alternative routing guidance is provided.

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 must carry the behavioral disclosure burden. It does state the core behavior (scroll at a point by pixel deltas), but it does not clarify the coordinate system (viewport vs. page), scroll direction sign convention beyond pixel deltas, or what happens if coordinates are out of bounds. 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?

The entire description is one front-loaded sentence that states the action, location, and units without filler. Every clause adds operational value.

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 4-parameter, no-output-schema action tool, the description covers the core invocation but leaves the coordinate basis and edge-case behavior implied. An agent might call it correctly in a common case, but would not know viewport semantics or whether the wheel event is relative to the current scroll position.

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 0%, so the description compensates by naming all four parameters and explaining their roles: x/y as the scroll position and dx/dy as horizontal/vertical pixel amounts. It stops short of describing coordinate space and defaults (already in schema), but it provides meaning the bare integer schema does not.

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 ('Scroll') and identifies the exact target ('wheel at (x, y)') plus the units of action (`dy` vertical / `dx` horizontal pixels). This makes the tool's function immediately distinguishable from the other browser action siblings such as browser_click or browser_js.

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 states what the tool does but gives no guidance on when to prefer it over alternatives or any prerequisites/context. There is no 'use when...' or 'for other scrolling behavior use...' note, so an agent must infer usage from the tool name alone.

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 present, so the description carries the full burden of behavioral disclosure. It only states that recording starts and writes to a local directory, but does not explain what gets captured, how the recording session ends, whether existing recordings are overwritten, or what side effects occur.

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 concise sentence with no filler, but it is under-specified rather than efficiently complete. Key behavioral and parameter information is missing while the existing sentence could have been expanded without becoming verbose.

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?

With no annotations, no output schema, and two undocumented optional parameters, the description leaves a state-changing recording workflow largely unexplained. It omits the lifecycle relationship with browser_stop_recording and the meaning of the parameters, making it incomplete for 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?

Schema description coverage is 0%, and the description does not explain the optional name and title parameters at all. An agent has no way to know what values to provide or how these parameters affect the recording, so the description adds no semantic value beyond the property names.

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 names a specific action (start recording) and target (local directory), distinguishing it from the browser interaction tools. It does not explicitly contrast with browser_stop_recording, but the start/stop pairing is inferable from the tool name and sibling list.

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 when-to-use guidance, alternatives, or prerequisites are provided. The description does not mention that this should be paired with browser_stop_recording or that a browser session should be active, so usage must be inferred entirely from the name.

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 mentions the stop action and the return of a directory, but does not disclose side effects (e.g., whether the recording is saved, whether it is resumable, what happens if no active recording exists).

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. It states the action and the return value with zero redundancy.

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

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

For a zero-parameter tool, the description is largely adequate: it states the action and return value. However, it does not mention whether an active recording is required or what happens if one is absent, leaving minor ambiguity in edge cases.

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 the schema has 100% coverage of nothing, so the description adds no parameter semantics—but none are needed. The baseline of 4 applies because there are no parameters to document.

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 ('Stop') and resource ('active recording') and clearly distinguishes from the sibling tool browser_start_recording, which is the inverse action. It is unambiguous and tells an agent exactly what operation is performed.

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 wording implies the tool should be used when a recording is already active, likely after browser_start_recording, but it does not explicitly state prerequisites, exclusions, or alternatives. No when-not-to-use guidance is provided.

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 mentions the return value ('Returns the sessionId') but does not disclose what happens if the target is not found, whether the switch is synchronous, or whether the sessionId refers to the new tab's session. The behavior of matching by URL substring is ambiguous (e.g., case sensitivity, partial match).

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 concise sentence that front-loads the action and target format. It earns its place by adding the URL substring option and the return value, though it could be slightly more structured.

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

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

For a tool with no annotations, no output schema, and a single parameter with 0% schema coverage, the description is too thin. It does not explain error behavior, how to obtain a targetId (e.g., via browser_list_tabs), or what the sessionId is used for. An agent would likely need to experiment or consult other tools to use this 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 0%, so the description must compensate. It does clarify that `target` can be a `targetId` or URL substring, which adds meaning beyond the bare schema. However, it does not explain how to distinguish a targetId from a URL substring, what format a targetId takes, or how the substring matching works.

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 ('Switch') and resource ('tab'), and identifies the two accepted target formats: `targetId` or URL substring. It clearly distinguishes this from sibling tools like browser_new_tab and browser_close_tab, though it doesn't explicitly name them.

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

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

The description implies when to use this tool: when the agent needs to change the active tab and has a targetId or URL substring. However, it does not explicitly state when not to use it or mention alternatives like browser_list_tabs for finding the targetId or browser_current_tab for checking the active tab.

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 present, so the description carries the full burden. 'Insert text into the focused element' states the basic behavior but omits important behavioral traits such as whether it types keystrokes, appends at the cursor, clears existing content, or triggers input events. The term 'insert' is ambiguous relative to browser_fill.

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 focused sentence with no filler or redundant restatement of the tool name. It front-loads the action and target effectively and earns every word.

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

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

For a tool with no annotations, no output schema, and a large sibling set, more context is needed. It does not tell the agent about the required focused state, how to set that state, or how this differs from browser_fill and browser_press, so the description alone is incomplete.

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 0% and the only parameter is a string named 'text'. The description confirms the text is what gets inserted, adding a bit of meaning beyond the schema, but it offers no extra details like encoding, newline handling, or length limits. This is adequate, not exceptional.

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 action ('insert text') and resource ('the focused element'), so the tool's core purpose is unambiguous. It does not explicitly contrast with sibling tools like browser_fill or browser_press, but 'focused element' is a distinguishing qualifier.

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 no guidance on when to use this tool over browser_fill, browser_press, or browser_click. It also does not mention whether the element must already be focused or whether this tool focuses it first, leaving selection and sequencing 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, the description carries the full burden of behavioral disclosure. It does not state whether the file path must be absolute, whether the tool waits for the upload to complete, whether it triggers change events, or what happens if the selector does not match a file input. The description is minimal and leaves key behaviors unspecified.

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 wasted words. It front-loads the action and resource. However, it is so brief that it sacrifices useful detail, which is a minor structural tradeoff.

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

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

For a tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. An agent needs to know whether the path is local-only, whether the upload is synchronous, and what success/failure looks like. The sibling set includes many browser interaction tools, and this one lacks the context needed to use it reliably.

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 0%, so the description must compensate. It explains that `path` is 'the local file' and `selector` matches the file input, which adds some meaning beyond the bare schema. However, it does not clarify the expected format of `path` (absolute vs relative), whether it supports URLs, or the selector syntax (CSS vs XPath).

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 ('Set files') and resource ('a file input matched by `selector`'), which clearly distinguishes it from sibling tools like browser_click or browser_type. It could be slightly clearer that this is for uploading files via an <input type=file> element, but the core purpose 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 on when to use this tool versus alternatives like browser_type or browser_fill. The description does not mention prerequisites (e.g., the page must be loaded, the input must be visible) or exclusions (e.g., not for drag-and-drop uploads). An agent must infer usage from the tool name and sibling context.

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 must carry full behavioral transparency, but it only says 'Wait for seconds.' It does not disclose whether this blocks the page, whether it returns a value, or whether it has side effects. The behavior is implied but not elaborated.

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 extremely concise with no filler. The essential information, the wait duration, is front-loaded and every word contributes to meaning.

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

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

For a one-parameter tool, the description is minimally viable: an agent knows to wait for the given seconds. However, with no annotations, no output schema, and sibling tools that wait for specific conditions, the description leaves some context gaps about exact behavior and when to prefer this over alternatives.

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 description repeats the parameter name 'seconds' and indicates it is the wait duration, which adds minimal semantic value. However, schema description coverage is 0%, and the description does not provide constraints like minimum/maximum values or behavior when the default is used.

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

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

The description clearly states the operation: wait for a specified number of seconds. It distinguishes this as a time-based wait, but it does not explicitly differentiate itself from sibling tools like browser_wait_for_load or browser_wait_for_element, so it misses the top score.

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 provided about when to use a fixed delay vs. waiting for a load event or an element. There are no alternatives, conditions, or exclusions mentioned, leaving the choice of tool to the agent's 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 carries the full disclosure burden. It clarifies that `visible=True` requires rendering, which is useful, but it does not disclose timeout behavior (whether failure throws or returns), polling behavior, or what happens if the element never appears.

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 tight sentences with no filler. The main action is front-loaded, and the `visible=True` clarification is placed where it adds immediate value without bloat.

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 wait operation, the description plus schema defaults is mostly sufficient to invoke the tool. However, with no output schema, no annotations, and no explanation of timeout or failure behavior, an agent cannot predict how the tool responds under negative conditions.

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 0%, so the description must add parameter meaning. It explains `selector` and adds the rendered semantics for `visible`, but it omits `timeout` semantics such as units and default behavior, leaving an incomplete parameter picture.

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: wait for an element matching `selector` to appear, with an explicit `visible=True` nuance. This distinguishes it from sibling tools like browser_wait and browser_wait_for_load by targeting element presence rather than page load or a generic delay.

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 when to use the tool: when waiting for an element to appear. However, it does not explicitly contrast this with browser_wait, browser_wait_for_load, or other alternatives, and offers no exclusions or conditions for preferring a different tool.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the wait condition but does not disclose what happens on timeout (error? return?), whether it polls or uses an event, whether it returns any value, or whether it blocks indefinitely. The timeout parameter is in the schema but the description doesn't explain its behavior (e.g., default 15 seconds, what happens when exceeded).

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, concise sentence that front-loads the core behavior. It earns its place with no filler, though it could have added a brief note about timeout behavior without becoming bloated.

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 wait tool with one optional parameter and no output schema, the description is close to adequate, but the missing timeout semantics and lack of failure behavior leave an agent uncertain about edge cases. Given the sibling set includes browser_wait and browser_wait_for_element, a brief differentiation would improve completeness.

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 0%, so the description must compensate for the undocumented 'timeout' parameter. The description does not mention the timeout parameter at all, leaving the agent to infer its units (seconds? milliseconds?) and behavior from the schema's default of 15. This is a clear gap.

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') and a precise condition (readyState is 'complete'), which clearly identifies the tool's function. It is distinguishable from siblings like browser_wait and browser_wait_for_element because it targets page load state rather than a fixed delay or element presence, though it doesn't explicitly name those 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 implies usage: call this after navigation to ensure the page has finished loading. However, it does not explicitly state when to use this versus browser_wait or browser_wait_for_element, nor does it mention that it may be unnecessary for some SPAs or that readyState 'complete' may not mean all resources are loaded. The context is clear but exclusions/alternatives are not stated.

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