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

With no annotations, the description carries the full transparency burden, and it delivers: it discloses main-world execution, per-navigation timing, persistence on future navigations, current-page scoping, and the race condition with synchronous inline scripts. This goes well beyond a generic 'registers a script' statement.

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?

Three sentences, each with a distinct job: what it does, why it beats evaluate, and when/how to call it. No filler; every sentence earns its place despite the rich technical detail.

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 purpose, timing, scoping, and comparison to alternatives, which is strong for a two-parameter tool with no output schema. It misses clarifying that at least one of script or function must be supplied, since the schema marks both optional; that ambiguity keeps it from a 5.

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% and both parameters already have meaningful descriptions ('Deprecated alias for function' and 'Function body/expression...'). The description adds no parameter-level semantics beyond the schema, so 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 opens with a specific verb and resource: 'Register JavaScript that runs before any page script, on every navigation.' It explicitly distinguishes itself from browser_evaluate by framing its proactive nature, so an agent can immediately tell what this tool does and how it differs from a likely sibling.

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 explicit timing guidance ('Call this BEFORE browser_navigate'), states the limitation ('no effect on a page already loaded'), and names the alternative browser_evaluate with the exact condition that selects between them (proactive init vs reactive evaluate). This is explicit when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It discloses the session-reuse behavior and return values, but it does not mention that POST/PUT/DELETE requests may cause side effects on the target server, nor does it address redirects, error handling, or whether the request executes within the browser page context.

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, front-loaded with the core action and key behavioral trait, followed by return value. 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 6-parameter HTTP tool with no output schema and no annotations, the description covers the essential return values and the unique session-reuse aspect, but it omits prerequisites (e.g., browser must be started), default method behavior, redirect handling, and side-effect warnings for mutating methods. These gaps make it incomplete for an agent deciding how to call it safely.

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 50%: url, method, and timeout lack descriptions, though url and method are self-evident. The description adds session-context value (why cookies/storage are reused), but it does not explain the timeout semantics or specify a default method when omitted. It only partially compensates for the schema 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 states a specific action ('Make an HTTP request') plus a distinctive resource/context ('reusing the browser session's cookies/storage'), and it mentions the return payload (status, headers, body). This clearly differentiates it from navigation, network-log inspection, and cookie-management siblings.

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 a clear use case: authenticated API calls without re-login. It implies when this tool is appropriate, but it does not explicitly name alternatives or say when not to use it (e.g., versus browser_evaluate or browser_navigate).

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 but discloses nothing beyond the action: no waiting behavior, scrolling, error handling, or visibility requirements. It says only 'Click an element,' which does not explain runtime behavior or side effects.

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

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

The description is a single, tightly written sentence with no filler words. It front-loads the action and scoping source ('from browser_snapshot'), making it 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?

Given no annotations, no output schema, and a frameSelector parameter that needs clarification, the definition is too sparse for an agent to call it reliably. Missing context includes what happens when no element matches, whether the click scrolls into view, and how timeout is applied.

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 selector, ref, and frameSelector with useful descriptions, and the description largely restates that information. Timeout is undocumented in both schema and description, so the 75% coverage is not fully compensated, but the description adds no real semantic value beyond what the schema supplies.

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 ('Click') and resource ('an element') with two explicit targeting methods: CSS selector or aria ref from browser_snapshot. It is unambiguous about the core action, though it does not explicitly contrast with sibling tools like browser_iframe_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 when-to-use or when-not-to-use guidance is provided; the description only restates the action itself. It fails to mention when browser_click should be preferred over browser_iframe_click or why frameSelector exists in the schema, leaving usage decisions entirely 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Close the browser session' without mentioning that all pages are closed, session state is lost, or that the browser must be restarted with browser_start afterward. The destructive finality is implied but not stated.

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 or redundant information. It is appropriately sized for a parameterless 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 core action is stated, and the tool is simple with no parameters or output schema, but the description omits important context such as the session being fully terminated and the distinction from browser_close_page. Slightly more detail would make it robust for an agent operating among many browser siblings.

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 an empty input schema, so there are no parameter semantics for the description to clarify. The baseline for 0-parameter tools 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 ('Close') and resource ('the browser session'), which clearly identifies the tool's function. It is implicitly distinct from browser_close_page, which targets a single page, but it does not explicitly name or contrast that sibling.

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 this tool versus browser_close_page or other browser lifecycle tools. The description does not explain that this ends the entire session or that browser_close_page should be used to close only the current page.

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. It conveys the basic close action but omits important consequences for a destructive tool: what happens on an invalid pageId, whether the last page closes the browser, and whether the action is reversible or loses unsaved 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?

A single, front-loaded sentence with no filler. It states the action first and then the optional behavior, packing all necessary information into minimal space.

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-output-schema tool this is nearly sufficient for correct invocation. The main gap is the lack of error/return behavior, which matters more because there are no annotations or output schema to supplement the description.

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 only provides type string, so the description's explanation of pageId and the active-page fallback adds the key semantic meaning. It could further clarify where a valid pageId comes from, but the essential behavior of the only parameter is well covered.

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 concrete action ('Close'), a specific resource ('page/tab'), and the targeting rule ('by pageId, or the active page if omitted'). It is clearly distinct from siblings such as browser_close and browser_switch_page.

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 explains the parameter-dependent behavior (pageId vs active page), so the agent knows when to rely on the default. However, it does not explicitly state when to use this tool over alternatives like browser_close, nor any exclusions or prerequisites.

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 'List captured console messages,' which implies a read operation but doesn't state whether it's read-only, whether it clears the console, or whether it returns a snapshot or a stream. The term 'captured' is vague and doesn't explain the capture process or any side effects. This is insufficient for a tool that could have non-obvious 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, concise sentence that front-loads the core action ('List captured console messages') and provides helpful examples in parentheses. There is zero fluff, and every word earns its place. It is optimally structured for quick comprehension.

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 is mostly adequate. It tells the agent what it does. However, it omits details about the return format, whether messages are ordered, or if there's any filtering capability. It also doesn't clarify whether 'captured' means all messages since page load or only new ones since the last call. This leaves some ambiguity for an agent deciding how to use the result.

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 no parameters, so the schema coverage is trivially 100%. Per the baseline for 0 parameters, the description doesn't need to explain parameter semantics. It adds no extra meaning beyond the empty schema, which is acceptable given there's nothing to describe.

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 lists captured console messages, with examples of message types (log/warn/error). This is specific and unambiguous, though it doesn't explicitly differentiate from sibling tools. The verb 'list' and resource 'captured console messages' are clear, but the lack of explicit sibling differentiation keeps it from 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 guidance is provided on when to use this tool versus alternatives. While there are no obviously similar siblings, the description doesn't mention any conditions for use, such as requiring prior capture or being the default for console inspection. It simply states what it does without context on when it's appropriate.

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 behavioral burden. It clearly discloses that the action is destructive and applies to all cookies in the current session, but it does not mention side effects such as logging the user out or invalidating authentication 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 sentence with no filler, front-loading the action and directly stating the scope. Every word contributes meaningful information.

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 no output schema, the description provides the essential information an agent needs: what action is performed and at what scope. The only minor ambiguity is what exactly constitutes the 'current session', but this is sufficient for straightforward 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 tool has zero parameters and the schema has 100% description coverage, so there is nothing for the description to add about parameters. This matches the baseline for a parameterless tool.

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 action ('Clear all cookies') and scope ('current session'), making the purpose immediately obvious. It does not explicitly name the sibling browser_cookie_delete as the alternative for removing a single cookie, but the phrase 'all cookies' clarifies the breadth.

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?

Usage is implied by the wording: use this when you want to clear all cookies rather than a specific one. However, there is no explicit guidance mentioning alternatives like browser_cookie_delete, browser_sessionstorage_clear, or when to avoid running this destructive 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?

No annotations are provided, so the description must disclose behavioral traits. It only says 'Delete cookies' without noting that this is destructive, irreversible, or what happens if the cookie does not exist. Lacks any side-effect or error context.

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 action and mentions the optional parameters. No wasted words, though it could be slightly more informative 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?

For a mutation tool with no annotations and no output schema, the description is under-specified. It does not mention return behavior, success/failure indications, or distinguish itself from browser_cookie_clear. The agent has no guidance on prerequisites or consequences.

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 only 33% (name has a description; path and domain do not). The description adds 'optionally narrowed by domain/path' but does not clarify the expected format or semantics of path/domain, leaving the agent to guess. Minimal value added 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 clearly states the action ('Delete cookies') and the primary resource ('by name'), with optional narrowing by domain/path. This distinguishes it from other cookie tools like get or set, though it does not explicitly contrast with the sibling 'cookie_clear'.

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 on when to use this tool versus alternatives such as browser_cookie_clear or browser_cookie_set. The description implies it is for targeted deletion but does not state conditions or when to prefer it over clearing all cookies.

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 behavioral transparency burden. It usefully discloses the null return when the cookie is absent, which is informative. However, it does not explicitly state whether the operation has side effects or any access constraints, though 'Get' implies a read-only 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?

The description is two short sentences with no filler. The primary action is front-loaded and the return behavior is stated efficiently. Every word contributes 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 simple one-parameter getter with no output schema, the description is nearly complete: it states the action, the selection criterion, and the return behavior. A small gap is not mentioning cookie scoping or that this only reads from the current context, but that is minor for this 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?

Schema description coverage is 100%, so the schema already documents the 'name' parameter. The description adds minimal additional meaning by indicating the cookie is selected by name, but it does not substantially expand 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 explicitly states the verb 'Get', the resource ('single cookie'), and the selection method ('by name'), which clearly distinguishes it from sibling tools like browser_cookie_list. It also specifies the return behavior, making its purpose 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 phrase 'single cookie by name' gives clear context for when to use this tool: when you need one specific cookie rather than listing all cookies. It does not explicitly mention alternatives, but the intent is clear enough for an agent to route correctly.

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 burden of disclosing side effects. The verb 'List' clearly signals a read-only operation with no destructive behavior, and 'current session' clarifies scope. It lacks explicit statements about return format or permissions, but the non-mutating nature is well 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 sentence that front-loads the core action ('List cookies in the current session') and appends the optional filters. Every word contributes value, and there is no redundancy 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 read-only list operation with two optional, fully documented parameters and no output schema, the description covers the essential behavior and scope. It does not elaborate on the return structure, but the tool name and verb 'List' imply a list of cookies, which is sufficient 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% for both parameters, so the schema already documents their types and filtering semantics (exact vs substring). The description merely restates that filtering is possible by domain and/or path, adding no meaning beyond the structured schema. 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 clearly states a specific verb ('List'), a resource ('cookies'), and the scope ('current session'), alongside optional filters. This differentiates it from sibling tools like browser_cookie_get, set, delete, and clear, which have obviously different operations.

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 listing cookies in the session, but it does not explicitly state when to prefer it over browser_cookie_get (which likely targets a specific cookie) or any other alternative. No exclusions or alternative conditions are given, leaving the agent to infer.

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 does disclose useful defaults: path defaults to / and active page origin is used as a fallback. It does not explain overwrite behavior, failure if no active page exists, persistence, or security restrictions that may affect cookie setting.

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 tight sentence front-loads the action and key defaults with no filler. Every phrase 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?

The essential target-selection rule is present, which covers straightforward invocation. However, with 9 parameters, no annotations, and no output schema, several flag semantics and failure behaviors remain implicit, leaving clear gaps for less common calls.

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 only 44%, and the description adds the important relationship between url, domain, path, and active-page fallback. It does not elaborate on name, value, secure, httpOnly, or sameSite, though their names are largely self-explanatory.

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 operation ('Set a cookie') and resource, with the optional flags scope clearly implied. It is distinguishable from sibling cookie_get/list/delete/clear tools because the verb 'set' names the write 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?

Provides concrete guidance on how to address the cookie: pass url, pass domain, or rely on the active page origin when neither is supplied. It does not explicitly discuss alternatives or when-not conditions, but the target-selection guidance is clear and actionable.

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 disclosing behavior. It states the action but omits any side effects, return values, waiting behavior, or whether it triggers events. It also does not explain the 'timeout' parameter or any iframe handling, leaving significant behavioral unknowns.

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 primary action and identification method. It contains no fluff and is appropriately sized for a tool with three parameters.

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 drag operation with nested source/target objects and a timeout, the description is minimal. It does not cover iframe handling (frameSelector), return values, error cases, or what constitutes a successful drag. Given the complexity of the schema and the lack of an output schema, the description leaves the agent without enough context to confidently invoke the tool 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 coverage is 67% (source and target have descriptions, timeout does not). The tool description aligns with the schema by mentioning CSS selectors and aria refs, but it adds little beyond what the schema already indicates. The timeout parameter is left undocumented in both schema and description, so semantics for that are unclear.

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 performs a drag action from a source to a target element, using CSS selectors or aria refs. This distinguishes it from sibling tools like browser_click or browser_fill. However, it does not explicitly differentiate from potential similar actions like browser_hover or browser_press_key, though drag is unique 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 the tool is used when a drag-and-drop interaction is needed, but it provides no explicit guidance on when to use it versus alternatives, nor any prerequisites or conditions (e.g., element visibility, supported drag targets). The usage context is inferred from the action name rather than 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?

No annotations are provided, so the description carries the full burden. It discloses the isolated stealth world default, the DOM-sharing/global-hiding behavior, the main-world alternative, and the ability to reach cross-origin iframes. It also flags 'script' as deprecated. These are important behavioral traits beyond the schema.

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 longer than average, but every sentence carries necessary information: the evaluation modes, the stealth-world behavior, the main-world requirement, and the iframe targeting. It is front-loaded with the core purpose and then adds detail in a logical order, so the density is justified.

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 5-parameter complexity and no output schema, the description addresses parameter selection, execution world, and iframe targeting thoroughly. The main gap is that it never states what the tool returns after evaluation (result value, formatting, promise handling), which an agent would need to know for downstream use. Still, the core calling context is well covered.

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 only 40%, with script, function, and expression left undocumented in the schema. The description explicitly explains what each of those three parameters expects and how to pass them, and it adds operational meaning to world and frameSelector. This fully compensates for the schema 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 opens with a specific verb and resource: 'Evaluate JavaScript in the active page.' It clearly distinguishes the tool's scope from the many other browser tools by focusing on JS execution, and it further clarifies variations (function body, expression, deprecated script) so an agent knows exactly what operation is offered.

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 concrete usage conditions: use world:'main' when page globals need to be read or called, and pass frameSelector to target a specific or cross-origin iframe. It does not explicitly name sibling alternatives to rule out, but the guidance is specific enough for an agent to select parameters correctly.

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 behavioral burden. It only restates the core action and does not disclose whether the upload waits for completion, whether local file paths must exist, whether existing file input contents are replaced, or what happens if no matching input is found. For a state-changing browser action, 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?

The description is a single efficient sentence with no filler. The verb, target, and locator approach are front-loaded, making the tool's purpose immediately graspable.

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 five-parameter tool with no annotations and no output schema, the description provides the essential operation and locator constraints, and the schema fills in most parameter details. However, it omits behavioral expectations such as waiting semantics and file-upload side effects, so it is adequate but not fully 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 80%, with ref, selector, paths, and frameSelector already described. The description adds the high-level mapping that CSS selector and aria ref are the two locator strategies, but it adds no detail about timeout behavior or multi-file upload semantics 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 ('upload'), identifies the exact resource ('<input type=file>'), and names the locator strategies (CSS selector or aria ref). This clearly distinguishes the tool from sibling text-entry and click tools like browser_fill, browser_type, and 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 description makes the intended use obvious: uploading files to a file input element, targeted either by CSS selector or aria ref. It does not explicitly name alternatives or exclusions, but the file-input context is sufficient to route an agent to this tool over the other browser interaction 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 carries the full burden of behavioral disclosure, yet it only states the verb 'fill'. It does not disclose that filling typically replaces existing field content, whether the tool waits or scrolls, how timeouts behave, or the iframe behavior represented by frameSelector in the schema. It is not misleading, but it is minimally transparent 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?

A single 11-word sentence that front-loads the verb and targeting scope with no filler words. Efficient structure, though the terseness trades away behavioral detail that is penalized in other dimensions.

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 five parameters, two mutually exclusive targeting modes, optional iframe targeting, a timeout, and zero annotations or output schema, this description is thin. It omits the frameSelector capability, text/timeout semantics, and any distinction from browser_type or browser_fill_form. An agent could infer much from the schema, but the description alone leaves significant gaps.

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 60% (ref, selector, and frameSelector are documented; text and timeout are not). The description adds marginal value by confirming that refs originate from browser_snapshot and that targeting is via CSS selector or aria ref, but the required text parameter and timeout remain undefined in both the description and schema. 'Fill an input' loosely implies text is the content, which partially compensates.

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 verb ('fill') and resource ('an input') and identifies the two targeting mechanisms (CSS selector or aria ref from browser_snapshot). It is clear at a glance, but it does not explicitly differentiate from closely related siblings such as browser_type, browser_fill_form, or browser_iframe_fill.

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 only usage cue is 'aria ref from browser_snapshot', which weakly implies a snapshot should be taken first. There is no guidance on when to choose this over browser_type (keystroke simulation), browser_fill_form, or browser_iframe_fill, and no exclusions or preconditions are 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?

No annotations are present, so the description must carry the behavioral disclosure burden. It only restates the fill operation and the per-field requirement, without explaining what happens on partial failure, whether existing values are overwritten, whether it waits for elements, or how frameSelector affects targeting.

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 filler and the main behavior is front-loaded. It is terse to the point of underspecification, but every phrase 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 no annotations, no output schema, and a nested field object with four properties, this short description leaves the agent unable to predict return behavior, error semantics, or correct field resolution. It should explain how selectors, refs, and names differ and describe batch behavior more thoroughly.

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 mentions 'selector or ref' and 'value', but omits the `name` alternative and the `timeout` and `frameSelector` parameters, and it states fields 'need' selector/ref even though the schema only requires `value` per item.

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 leads with a specific verb ('Fill'), a clear resource ('form fields'), and a batch qualifier ('multiple ... at once'), which separates it from sibling tools like browser_fill or browser_type. There is no ambiguity about what operation the tool performs.

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 no explicit when/when-not guidance or naming of alternatives such as browser_fill or browser_type. The 'multiple ... at once' phrasing only implies the intended use case, leaving the agent to infer the selection rule rather than being told directly.

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 clearly states the operation is a non-mutating search ('Search...'), the scope ('current page's aria snapshot'), and the output shape (nodes with refs and context). It could add explicit read-only language or clarify behavior on no matches, but the core behavioral traits are transparently 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?

One tightly structured sentence that front-loads the verb and resource, then delivers the return value and usage guidance. Every clause earns its place; there is zero redundancy 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 5-parameter tool with no annotations and no output schema, the description covers the essential context: what it searches, what it returns, and when to use it. It does not explicitly say the operation is read-only or explain what happens if no matches are found, but those omissions are minor given the schema's thorough parameter descriptions.

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 all 5 parameters (100% coverage), so the baseline is 3. The description adds little beyond the schema, briefly mentioning 'text or a regex' (matching query/regex) and 'surrounding context' (matching context), but ignores ignoreCase and maxMatches. This adds marginal value but does not compensate for anything the schema lacks.

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: 'Search the current page's aria snapshot for text or a regex.' It also names the return value (matching nodes with refs and surrounding context), clearly distinguishing it from siblings like browser_snapshot or browser_get_visible_text. This leaves no ambiguity about what the tool does.

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

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

It explicitly contrasts with a sibling: 'cheaper than a full browser_snapshot when you only need to locate an element.' This tells the agent both when to use this tool and what alternative to prefer in other situations. The guidance is direct and actionable.

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 the full behavioral burden. It only states that it 'collects' diagnostics, but does not disclose whether this is a pure read operation, whether it may trigger any browser events, how much data is collected, or what the returned structure looks like.

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, front-loaded with the action and target resource. There is no extraneous detail or repetition, making it efficient and easy to parse.

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 with no parameterscustom, and the description is understandable for selecting the tool. However, without an output schema or any description of the returned fingerprint values, the agent does not know what to expect from the call, leaving a moderate 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 has zero parameters samanage, so parameter semantics are not applicable. The baseline of 4 is appropriate because no additional parameter documentation is needed and the description does not mislead about 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 identifies the verb ('Collect') and the resource ('browser fingerprint diagnostics from the active page'). It is distinguishable from typical navigation, storage, and visibility tools in the sibling list, though the exact meaning of 'fingerprint diagnostics' could be slightly more explicit.

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 indication of when to use this tool versus alternatives like browser_evaluate, browser_get_visible_text, or browser_network_requests. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer the appropriate usage scenario.

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 burden. The 'get' verb implies a read-only operation, and the stripping-by-default for token efficiency is a useful behavioral fact, but the description does not explicitly address side effects, missing-selector behavior, or the exact shape of the returned HTML.

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 clause earns its place: the core action, the optional scoping, and the important default behavior.

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 read-oriented tool with three fully documented optional parameters, the description is largely sufficient: the return value is clearly implied as HTML, and the main options are covered. The absence of an output schema means a little more detail on return edge cases would be welcome, but the core contract is clear.

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 baseline applies and the schema already documents selector, maxLength, and removeScripts. The description adds only the token-efficiency rationale and the default stripping context, which is helpful but not required for parameter understanding.

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 ('Get') and the resource ('page HTML'), with an optional selector scope and the default stripping behavior. It is specific enough to be understood at a glance, but it does not explicitly distinguish itself from sibling read/snapshot tools such as browser_snapshot or browser_get_visible_text.

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 about when to use this tool versus alternatives, and it names no exclusions or preferred contexts. An agent must infer when to select browser_get_visible_html over browser_snapshot, browser_get_visible_text, or browser_evaluate.

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 disclosure. It accurately identifies the data source (document.body.innerText) and performance character ('lighter'), but does not comment on side effects (expected none), return format, or edge cases like blank pages or wait behavior. The description is truthful but adds only modest behavioral context beyond the obvious read operation.

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 fluff. It front-loads the core purpose and immediately adds the differentiating performance note. 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 getter with one well-documented optional parameter and no output schema, the description is sufficiently complete: it states what is returned (visible text), the source method, and a comparison to a related tool. It does not explain the return type (obviously a string) or truncation behavior, but the schema covers the truncation parameter, so the definition 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 input schema has 100% description coverage for the single parameter maxLength, including its default value. The tool description adds no parameter-specific meaning, but because the schema fully explains the parameter, the baseline of 3 applies without requiring compensation.

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: 'Get the visible text ... of the active page.' It also distinguishes itself from a heavier alternative by noting it is 'lighter than a full aria snapshot.' This makes the tool's purpose immediately clear and differentiable from browser_snapshot and similar siblings.

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 by framing it as a lighter alternative to a full aria snapshot, suggesting it is for cases where only visible text is needed. It does not explicitly name browser_snapshot or give a when-not-to-use condition, but the comparative hint provides clear context for selecting this over the heavier snapshot.

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 does not mention the default one-shot handler behavior, the effect of wait and timeout, what happens if no dialog is present, or any error conditions. The schema provides some parameter details, but the description itself is too skeletal to give an agent confidence about the tool's runtime behavior, especially since it mutates UI state (accepting/dismissing) without disclosing side effects or reversibility.

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, a single sentence with the core purpose front-loaded. There is no fluff or redundancy. It earns a 4 because while it is appropriately brief, it could have included a bit more operational context without becoming verbose, but the structure itself is optimal for quick parsing.

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), and the schema explains parameters well. However, the description lacks usage context such as 'call this when a dialog is blocking the page' or notes about the one-shot behavior. It does not explain the interaction with preceding actions or what happens when no dialog exists. For an agent to use it correctly, more context is needed, so completeness is only 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?

Schema description coverage is 100%, and the schema already explains all four parameters (wait, accept, timeout, promptText) with clear descriptions. The tool description does not add any additional parameter semantics beyond the schema. Per the rubric, the baseline is 3 since schema does the heavy lifting, and the description adds no extra value here.

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 ('Accept or dismiss') on a specific resource ('a JavaScript dialog') and enumerates the dialog types (alert / confirm / prompt). This is specific and distinguishable from sibling browser tools, which cover navigation, clicking, filling, etc., so an agent can easily identify when this tool applies.

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 a JavaScript dialog appears, but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It is clear from the name and description that this is the tool for dialogs, but there is no explicit routing or edge-case advice, so it falls short of a higher score.

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. It discloses the key distinction—passing an identifier removes a specific overlay, whereas omitting all arguments clears every highlight—which is a potentially broad destructive action. It doesn't specify behavior with multiple identifiers or no matching highlight, but the main side effect is covered.

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 the core action front-loaded and no filler. The sentence structure earns its place by covering both the base operation and the important all-clear default.

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 three optional params, the description is near-complete: it states the action, how to target, and the default all-clear behavior. Minor gaps like multiple-param precedence and return value keep it from a 5.

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?

All three parameters are already described in the schema, but the description adds the crucial relationship: they are alternative identifiers, and omission means a global clear. This adds real meaning beyond the individual field descriptions. It doesn't clarify whether multiple identifiers are combined or how conflicts resolve.

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 ('Remove') and resource ('highlight overlays'), and the second sentence distinguishes targeted removal from clearing all. This clearly differentiates it from the sibling 'browser_highlight' tool that adds overlays.

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 clearly states the two calling modes: pass one of label/selector/ref for a specific highlight, or omit all to clear every highlight. It does not explicitly name browser_highlight as an alternative or state when not to use it, 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?

With no annotations, the description carries the burden and it delivers: 'Does not affect page behavior' is a meaningful safety guarantee, and 'persistent' discloses the overlay's lifetime behavior. It could mention cleanup or timeout, but the core non-destructive nature is explicit.

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?

Three short sentences, each earning its place: the action, the use case, and the side-effect guarantee. The key functional constraint (selector or ref) is front-loaded with the verb.

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 visual overlay tool this is largely complete: the agent knows what to target, why to use it, and that it is safe. It stops short of describing return values or timeout behavior, but no output schema exists and the core invocation constraints are covered by the schema.

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 83%, so the schema already documents most parameters. The description adds no new parameter-level detail beyond noting CSS selector/aria ref, which the schema already states; the undocumented 'timeout' parameter is not explained in the description either.

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-resource pair ('Draw a persistent highlight overlay') and clarifies the target is an element identified by CSS selector or aria ref. It also states the intended purpose (screenshots/video focus), making it easy to distinguish from siblings like browser_hide_highlight and browser_take_screenshot.

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 explicitly says the tool is useful for screenshots and video recording to show agent focus, giving clear when-to-use context. It does not state when not to use it or name alternatives explicitly, but the inverse browser_hide_highlight is implied by 'persistent' and the label-as-key parameter.

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 burden. It clearly states the action ('hover') and the source of the target, but it does not disclose timeout behavior, whether the element is scrolled into view, what happens on failure, or whether any hover-driven UI changes are expected.

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, front-loaded sentence with no filler. Every word contributes to identifying the action and the accepted locator sources.

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 sufficient for a simple hover action, but it omits timeout semantics, iframe behavior details (though the schema covers frameSelector), and failure or waiting behavior. Given no annotations and no output schema, some operational context is left to inference.

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 descriptions already cover selector, ref, and frameSelector in detail; the tool description largely restates the selector/ref concept. With 75% schema coverage, the description adds no significant parameter semantics beyond the structured fields.

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 ('Hover') and a clear resource ('an element'), plus the two accepted locator forms (CSS selector or aria ref from browser_snapshot). This makes the tool's purpose immediately distinguishable from sibling interaction tools like browser_click or browser_fill.

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 you need to hover over an element) and notes the locator sources, but it does not explicitly contrast it with alternatives or provide exclusions. It does not mention the exactly-one-of-selector/ref constraint, though that is covered in the schema.

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 transparency burden. It communicates that this tool is a shorthand/legacy wrapper and that clicking inside an iframe is its behavior, but it does not disclose failure modes, navigation side effects, or timeout behavior. Some useful context is present, but not comprehensive.

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 deliver the essential point and the routing guidance without waste. The main purpose is front-loaded, and the preference note is placed in a parenthetical that does not distract.

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 legacy click helper, the description plus schema provide enough for an agent to call it correctly: required parameters are clear, purpose is clear, and the preferred alternative is named. It lacks only a deprecation or fallback-behavior note, but this is a minor gap 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 selector and frameSelector with clear descriptions, covering 67% of parameters. The description adds little about parameters beyond framing them in the iframe click scenario. The timeout parameter remains undocumented in both schema and description, preventing a higher score.

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 action and resource: clicking inside an iframe. It also distinguishes itself from the sibling browser_click by framing itself as a shorthand, and explicitly names browser_click as the preferred alternative.

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 usage direction: this is a shorthand convenience, while the preferred approach is browser_click with frameSelector. This explicitly tells the agent when to choose another tool over this one.

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 burden. It discloses that the tool is a shorthand and implies equivalence to browser_fill, but does not mention return values, waiting behavior, errors, or side effects. The core operation is clear, but the behavioral picture is 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?

Two concise sentences with no filler. The core purpose and the preferred alternative are front-loaded, and every clause contributes 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 simple alias-like tool, the description is adequate to understand its role and avoid misuse. However, with no annotations and no output schema, behavioral and return details are left unspecified, and the description leans heavily on the recommendation to use browser_fill instead.

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 documents frameSelector and selector, but value and timeout are undocumented, leaving 50% coverage. The description adds no parameter-level meaning beyond what the schema already provides, so it does not compensate for the 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?

States a specific verb and resource: filling inside an iframe. It also explicitly defines itself as a shorthand and points to browser_fill, distinguishing it from browser_iframe_click and other browser 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?

Explicitly instructs the agent to prefer browser_fill with frameSelector, giving a clear alternative and preference. This is direct, actionable usage guidance rather than leaving the choice 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 burden of behavioral disclosure. It explicitly states what gets destroyed ('all localStorage' for the active origin), which is transparent about the destructive scope. However, it does not mention irreversibility, side effects on the active page, or the return value, which would add useful context for a destructive operation.

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, compact sentence that states the action, resource, and scope with no wasted words. It is front-loaded and immediately understandable.

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 no output schema, the description is largely sufficient: it identifies the action, resource, and origin scope. It could improve by noting that the operation is destructive and irreversible, but the core information needed to invoke the tool correctly is present.

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 baseline is 4. The description correctly adds no parameter detail because there is none. It appropriately focuses on the operation's scope 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 states a precise operation ('Clear') on a specific resource ('all localStorage') and scopes it to 'the active page's origin'. This clearly differentiates it from sibling tools like browser_localstorage_delete (which removes specific keys) and browser_sessionstorage_clear (different storage area).

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 conveys clear usage context: use this to remove the entire localStorage for the current origin rather than individual keys. It does not explicitly name alternatives or state when not to use it, but the 'all' scope strongly implies bulk clearing versus targeted deletion via browser_localstorage_delete.

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. 'Delete' clearly implies destructive action, but the description does not mention permanence, what happens if the key does not exist, whether it only affects the current origin, or the return value.

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 word earns its place, clearly conveying the action and the parameter's purpose.

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 destructive tool with no annotations and no output schema, this description is under-specified. It does not disclose side effects, error behavior, or return values, and it lacks guidance distinguishing it from closely related storage deletion tools.

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 mentions 'by key', which maps to the required 'key' parameter, but adds no detail about key format, validity, or behavior for non-existent keys. The schema already names the parameter, so the description adds minimal semantic 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 action 'Delete' with the resource 'localStorage item' and the exact scope 'by key'. This distinguishes it clearly from sibling tools like browser_localstorage_list, browser_localstorage_set, and browser_localstorage_clear.

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 guidance about when to prefer this tool over alternatives such as browser_localstorage_clear for clearing all items or browser_sessionstorage_delete for sessionStorage. The usage context is only implied by the name and basic description, with no exclusions or alternative routing.

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 burden. It usefully discloses that the tool 'Returns null if absent', which is valuable edge-case behavior. However, it does not state that the operation is read-only, side-effect-free, or scoped to the current page origin, leaving some behavioral context implicit.

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, efficiently worded sentence that front-loads the action and resource. It includes the most important behavioral note (null return) without any 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?

For a simple one-parameter read operation with no output schema, the description is largely complete: it states the operation, the input, and a key return behavior. Minor context about storage scope or read-only safety could strengthen it, but the low complexity makes the current description nearly 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 coverage is 0%, so the description must give the parameter meaning. It does so minimally by explaining that the 'key' identifies the localStorage item to retrieve. This is enough for a single self-explanatory parameter, but no additional detail such as key format or behavior for empty strings is provided.

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 ('Get'), the resource ('localStorage item'), and the selection mechanism ('by key'), making the tool's purpose immediately understandable. It does not explicitly differentiate itself from siblings like browser_localstorage_list, but the phrasing makes the distinction 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?

No guidance is provided about when to use this tool versus alternatives such as browser_localstorage_list, browser_localstorage_set, or browser_sessionstorage_get. The description implies a simple key lookup but offers no context on prerequisites or exclusions.

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 states the read-only action ('List') and scope ('active page's origin'), which covers the core behavior, but it does not address edge cases such as empty storage, access errors, or whether the operation has side effects. For a simple list 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 sentence that is both concise and front-loaded: it names the action, the resource, and the scope without any filler. 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 tool, the description sufficiently communicates what the agent will receive ('key-value pairs') and the scope. It does not specify the exact return structure (e.g., array of objects), but the phrase 'list all localStorage key-value pairs' gives enough guidance for a straightforward read 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, and the schema is empty, so there is nothing to document. The baseline for 0 parameters is 4, and the description appropriately adds no parameter information because none exists.

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'), a specific resource ('localStorage key-value pairs'), and a clear scope ('for the active page's origin'). This distinguishes it from sibling tools like browser_sessionstorage_list, browser_cookie_list, and the localStorage get/set/delete/clear variants.

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 when you need to enumerate all localStorage entries for the current origin. However, it does not explicitly state when to prefer this over browser_localstorage_get or mention any exclusions or alternatives, so it 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does state that setting is scoped to the active page's origin, which is useful, but it fails to mention overwrite behavior, persistence, return values, or potential side effects.

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

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

A single, front-loaded sentence with no filler. Every word earns its place and the core operation and scope are immediately visible.

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 setter, the description plus input schema covers the essential invocation. However, without annotations or an output schema, and with no note about overwriting existing items or return behavior, it is minimally complete rather than fully contextualized.

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 adds no meaning to the 'key' and 'value' parameters beyond what their names imply. It does not explain storage type coercion or any constraints on keys/values.

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 ('Set') and resource ('localStorage item') and scopes it to 'the active page's origin.' This clearly differentiates it from storage siblings like browser_sessionstorage_set, browser_cookie_set, and localStorage read/delete operations.

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 guidance on when to use this tool versus alternatives such as browser_sessionstorage_set, browser_cookie_set, or browser_storage_save. It also does not mention when not to use it or any prerequisites.

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 only says the page will be navigated; it does not mention that the current page state may be lost, whether dialogs can block navigation, what the default wait behavior is, or what 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?

The description is a single focused sentence with no filler. It is front-loaded, easy to scan, 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?

The tool has no annotations and no output schema, so the description must do more work. It omits timing/wait behavior, parameter semantics for timeout and waitUntil, and any guidance on when this is preferred over sibling navigation tools. The description is minimally viable but not complete for correct invocation in varied situations.

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 mentions URL, matching the required param, but says nothing about the timeout parameter's units or default, and nothing about the meaning of the waitUntil enum values. With schema description coverage at 0%, the description fails to compensate for the 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 is clear: it names a specific verb ('navigate') and resource ('the active page') with a destination URL. However, it does not distinguish the tool from siblings like browser_new_page, browser_switch_page, or browser_navigate_back, so it stops short of full differentiation.

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. An agent cannot tell whether this should be used for new tabs, switching pages, or going back, because those distinctions are not addressed.

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 behavior disclosure. It essentially restates the tool name and does not mention what happens when there is no previous history entry, whether navigation waits for page load, or how failures are signaled.

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 with no filler, which is appropriately sized for a zero-parameter tool. However, it is concise primarily because it nearly restates the tool name rather than adding information-dense context.

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 core operation is stated, but completeness is limited by missing edge-case behavior and preconditions, such as what happens if history is empty or whether the current page state is preserved. No annotations or output schema exist to fill these gaps.

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 an empty input schema, so the description has no parameter semantics to add. The baseline of 4 for zero-parameter tools 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 action ('navigate back') and resource ('browser history'), making it clear this is history-back navigation rather than a URL-based navigation like browser_navigate. It does not explicitly contrast itself with sibling tools, but the 'back' qualifier removes most 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?

No guidance is provided about when to use this tool versus browser_navigate, browser_new_page, or browser_switch_page. It also omits practical preconditions such as requiring an active page or a non-empty history.

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. It discloses that id is a stable identifier, that a legacy zero-based index is accepted, and that the details flag includes a response body preview. However, it does not mention error behavior (e.g., unknown id/index), side effects, or response format. The 'Get' verb implies read-only, but this is not explicit.

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 tight sentences: the first front-loads the primary purpose and source, the second clarifies the alternate identifier. No filler or redundancies, and every clause adds information the agent needs.

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 adequate for invoking the tool correctly (knowing id or index is accepted and details toggles preview), but with no output schema it leaves the return value underspecified. It does not describe what fields are returned, what happens when no identifier is provided, or any limit/retention behavior of the request list. More detail on the response shape would complete the picture.

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 67% (id lacks a schema description), but the description compensates by explaining the id as a stable identifier from browser_network_requests. It also adds the 'legacy' nuance to the index parameter, clarifying its relationship to the retained list. The details parameter's purpose is both in the schema and reflected 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?

The description uses a specific verb ('Get details') with a clear resource ('a single network request') and the source ('from browser_network_requests'). It also mentions the stable-id and legacy-index identification methods, which distinguishes it from the sibling list tool browser_network_requests.

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 points to the source (browser_network_requests) and explains the two accepted identifier forms, giving the agent enough context to know when to call it after listing requests. It doesn't explicitly name alternatives or exclusion conditions, but the provenance is strong enough to imply the list-then-fetch pattern.

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 burden. 'List' conveys a read-only intent and the activeOnly clause explains filtering, but it does not clarify how requests become captured, whether capture must be enabled first, or what the response contains.

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 fully conveys the core behavior and the parameter condition with zero 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 one-parameter list tool with no output schema, the description is mostly complete. It covers purpose and parameter semantics, but lacks explicit return-format and capture-precondition 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 coverage is 0%, but the description compensates by explaining the only parameter: activeOnly=true means in-flight only. The default false behavior is implied, though not explicitly stated.

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 uses specific verb-resource pair 'List captured network requests', making the tool's function clear. It does not explicitly contrast with sibling tools like browser_network_request, though the plural 'requests' and 'List' help differentiate it.

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 on when to choose this tool over alternatives such as browser_network_request or browser_network_state_set. The only usage instruction, 'Set activeOnly=true for in-flight only,' addresses a parameter rather than tool selection.

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 clearly states the cause-and-effect behavior: setting offline=true simulates offline, and offline=false restores connectivity. It does not detail persistence across pages or the impact on in-flight requests, but the core mutation is 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?

The entire description is one compact sentence with no filler. The behavioral meaning is front-loaded, and both parameter mappings are stated efficiently.

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-boolean setter with no output schema, the description gives enough information to invoke the tool correctly. It stops short of explaining scope or side effects in detail, but nothing essential is missing 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 0%, but the description fully compensates by explaining the single boolean parameter: true means simulate offline and false means restore connectivity. This gives the agent complete semantic understanding that the bare schema lacks.

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 ('Set') with a clear resource ('network state') and explicitly defines the two possible states: offline simulation and restored connectivity. This makes it easy to distinguish from read-only siblings like browser_network_requests or browser_status, even 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?

There is no guidance about when to use this tool versus alternatives that also affect network behavior, such as browser_route_block or browser_route_mock. The description only explains the parameter; it does not mention prerequisites, exclusions, or scenarios like testing offline behavior.

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 disclosure burden. It does mention that the new tab becomes active and that a URL can be optionally navigated to, but it omits side effects such as whether it waits for page load, failure behavior on invalid URLs, or how the new page is referenced afterward.

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, front-loaded sentences contain no filler. The core action ('Open a new page/tab and make it active') comes first, followed by the optional behavior in a separate sentence.

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 one optional parameter and no output schema, the description is reasonably complete. But it could go further: it doesn't describe what happens if the browser isn't running, whether the tool returns a page handle, or how loading errors are surfaced. These details matter given the rich sibling set around page management.

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?

Although schema description coverage is 0%, the description's phrase 'Optionally navigate to a URL' directly explains the single `url` parameter's purpose and optionality. The one parameter is effectively covered, adding meaning beyond the bare 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 states a specific verb ('Open'), a concrete resource ('new page/tab'), and a clear behavioral outcome ('make it active'). It distinguishes itself from sibling tools like browser_navigate by emphasizing 'new page/tab' rather than navigating in the current page.

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 usage context is implied: you would use this when you need a new tab/page and want it to be active. However, it doesn't explicitly mention when not to use it or name alternatives like browser_navigate or browser_switch_page, leaving some 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?

No annotations are present, so the description carries the full burden. 'List' clearly suggests a read-only query, and the listed fields justify the operation. However, it does not explicitly state that the tool has no side effects or describe ordering/scope (e.g., whether it includes all windows).

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, front-loaded with the verb and resource, and every phrase adds meaningful information about what the tool returns.

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 read-only enumeration tool, the description is largely sufficient: it names the scope and the returned fields. It could add one line about being a prerequisite for page-switching tools, but that is not essential for a correct call.

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 zero parameters, so the description has no parameter-semantics burden. It appropriately describes output fields instead of inventing parameter meaning.

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 ('List'), resource ('open pages/tabs'), and the returned fields (ids, active state, URL, title). It is clearly distinguishable from sibling page/navigation tools, which act on pages rather than enumerate 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?

No guidance is provided on when to call this tool versus alternatives such as browser_status or browser_snapshot, and no mention that it can supply the page id needed for browser_switch_page or browser_close_page. The usage context is only implied by the verb 'List'.

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 full transparency burden. It discloses that private keys are omitted unless includePrivateKey=true, and that import requires all four key-material fields. However, it doesn't state whether the operation persists in the browser, whether it can overwrite an existing passkey, or any permission/security implications—significant gaps 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?

Three sentences, each with a distinct purpose: the primary action, the import condition, and the private key return behavior. No redundancy or filler; the generate/import distinction is front-loaded, and every sentence 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 no annotations and no output schema, the description covers the key conditional (import vs. generate) and the private key return behavior. It doesn't explain what a generated passkey returns or whether the credential is persisted, but for a 6-param tool with one required param, the instructions are sufficient for basic correct invocation. Minor gaps around side effects and output prevent a 5.

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 baseline is 3. The description adds meaningful context by specifying that import requires all four key-material fields, a condition not inferable from the schema alone. It also restates the includePrivateKey behavior, which is already in the schema, but the import condition justifies a 4.

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 ('Generate or import') and resource ('a virtual passkey'), and it distinguishes two modes of operation. However, it does not explicitly differentiate itself from sibling tools like browser_passkey_install or browser_passkey_list; the name helps, but the description alone doesn't fully clarify when to use this over siblings.

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 a conditional for import mode ('provide all four key-material fields'), which implies when import is appropriate, but it doesn't explicitly state when to generate vs. import, nor does it mention alternative tools or when not to use this tool. Usage context is present but not fully developed.

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 the full burden of behavioral disclosure. It simply says 'delete' without revealing whether the action is permanent, whether it affects only the current browser session, whether it can fail if the id is invalid, or what the return value/error behavior is. For a destructive mutation, this is a significant 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 sentence that is immediately actionable and front-loaded with the verb 'delete' and resource. Zero filler words; every word contributes to the meaning. It is an example of efficient, high-value description 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?

For a simple one-parameter destructive tool, the description is minimally adequate: it states the action and id format. However, it omits any explanation of success/error semantics (e.g., does it return a boolean, throw if not found?), reversibility, or scope (browser-specific passkey store). With no output schema and no annotations, these gaps hurt completeness for an agent making a real call.

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 provides a bare 'id' string with no description (0% coverage). The description compensates by specifying that the id must be a base64url credential id, which is crucial for correct invocation. It adds meaningful format information that the schema lacks, though it does not explain where to obtain the id or any length restrictions.

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 action (delete), a specific resource (one virtual passkey), and the exact identifier format (base64url credential id). This clearly distinguishes it from sibling tools like browser_passkey_create, browser_passkey_list, and browser_passkey_install. An agent can immediately tell what this tool does and how it differs from related operations.

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 this to delete a passkey') but does not explicitly state when to choose this tool over alternatives, nor does it mention any prerequisites such as the passkey needing to exist or the id being obtainable from browser_passkey_list. There is no 'when-not-to-use' guidance, leaving some inference required from the name and description.

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 burden. It does disclose that the tool modifies the current browser context and must be called before navigator.credentials is used. However, it does not mention idempotency, whether repeated calls overwrite existing authenticators, or how the installed authenticator interacts with browser_passkey_create/delete.

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, front-loaded sentences with no filler. The first sentence states the action, and the second provides the critical timing constraint.

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 setup operation with no output schema, the description covers the essential action and timing. It could strengthen completeness by relating this tool to sibling passkey operations, but the core calling context is sufficiently specified.

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 no-parameter baseline applies. The description adds relevant contextual information about the current browser context, but there are no parameter semantics to elaborate on.

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 ('Install') and resource ('Patchright's virtual WebAuthn authenticator') and scopes it to the current browser context. It is clearly distinguishable from sibling tools like browser_passkey_create, browser_passkey_list, and browser_passkey_delete.

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 states when to call the tool: before a page first uses navigator.credentials. This gives the agent clear timing guidance, though it does not explicitly discuss alternatives or when not to use the 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 provided, the description carries the full burden of behavioral disclosure. It explicitly warns that private keys are omitted unless includePrivateKey=true, which is important safety-sensitive behavior. It does not describe the return format, but that is less critical for a simple listing 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 two concise sentences with no wasted words. The core action and filters are front-loaded, followed immediately by the important privacy-related default behavior.

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 optional-filter listing tool with no required parameters and no output schema, the description provides sufficient detail: what is listed, how it can be filtered, and the sensitive private-key default. It is complete enough for an agent to invoke correctly without further 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 coverage is 67%, with rpId lacking a schema description. The description adds meaningful context by stating that results can be filtered by rpId or credential id, and clarifies that includePrivateKey controls private-key material exposure. This compensates for the schema 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 uses a specific verb 'List' with a clear resource 'virtual passkeys' and names the optional filters (rpId or credential id). This clearly distinguishes it from sibling tools like browser_passkey_create, browser_passkey_install, and browser_passkey_delete.

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 tool's purpose and optional filtering context clear. It does not explicitly state when to use it versus alternatives, but the verb 'List' and the sibling names make the intended use unambiguous enough for an agent to select it for read-only passkey enumeration.

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 reveals the focus-then-press sequence, but omits details about timeout handling, iframe resolution, special key support, side effects, or return 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 compact sentence with no wasted words. The action is front-loaded and the optional focus behavior is clearly appended without unnecessary detail.

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 five parameters, no annotations, and no output schema, one sentence is insufficient for reliable invocation. An agent would still need to infer accepted key strings, timeout semantics, return values, and how ref, selector, and frameSelector interrelate.

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 only 20%, so the description must compensate. It adds meaning by indicating selector and aria ref are optional focus targets, but it does not explain accepted key values or the meaning of timeout. These important parameters remain effectively undocumented.

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 primary action: pressing a keyboard key, with optional focusing on a selector or aria ref first. This distinguishes it from sibling tools like browser_click and browser_type, though it does not explicitly contrast single-key press with text entry.

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 no explicit guidance on when to use this tool versus browser_type, browser_fill, or browser_click. The optional focus behavior implies a common use case, but the description does not state conditions, exclusions, or 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?

With no annotations, the description carries the full burden of behavioral disclosure. It usefully clarifies that the resize targets the active page's viewport rather than the whole browser window, but it does not disclose side effects, constraints, or response behavior. This is adequate for a simple operation but not deeply 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?

The description is a single front-loaded sentence with no filler, repetition, or schema redundancy. Every word earns its place by clarifying the target and scope of the resize action.

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 tool with fully documented parameters and no output schema, the description and schema together cover the essential invocation details: what is resized, where it happens, and the two required values. Minor omissions like prerequisites or possible layout side effects do not critically undermine usability.

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%, with both width and height already documented as pixel values in the input schema. The description adds no additional parameter-level meaning, so 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 states a specific verb ('Resize') and a specific resource ('the active page viewport'), resolving the ambiguity in the tool name. It clearly distinguishes this from navigation, snapshot, and page-management siblings by scoping the action to the viewport of the active page.

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 phrase 'active page' implies that the tool applies to the currently open page, giving a basic usage cue. However, the description does not explicitly state when to use it, note prerequisites such as ensuring a page is loaded, or mention any alternative tools. Usage guidance 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, the description carries full responsibility for behavioral disclosure. It states that blocking applies to all pages, but does not clarify that the rule persists until cleared (via browser_route_clear), whether it affects only future requests, or what side effects occur. This is a significant gap for a tool that alters network 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 two sentences long, front-loads the core purpose, and includes a helpful example. Every word contributes value; there is 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 two optional parameters and no output schema, the description covers the main purpose and scope but omits important operational details such as how to undo the blocking (implicitly via browser_route_clear), whether the rule persists across navigation, and what happens to in-flight requests. Given the lack of annotations and output schema, this is incomplete but not severely so.

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 both parameters with full coverage (100%), including the default for urlPattern and the list of resource types. The description only restates the general concept of 'resource type and/or URL pattern' without adding new semantics or syntax details, so it meets the baseline but adds little 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 clearly states the action ('Block requests'), the target (resource type and/or URL pattern), and provides a concrete example (images/fonts/media). It also notes the scope ('Applies to all pages in the context'), making it distinct from sibling routing tools like browser_route_clear and browser_route_mock.

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 a practical use case ('speed up loads and shrink fingerprint surface') and states the scope, but does not explicitly mention when to use this tool over alternatives such as browser_route_mock or browser_route_clear. No exclusions or alternative conditions are provided, leaving some inference 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?

No annotations are provided, so the description carries the burden of disclosing behavioral impact. It clearly states that all active routes are removed, implying destructive behavior. It does not mention irreversibility, side effects on network interception, or return behavior, but for a 0-parameter clear operation the core behavior is transparent enough.

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 or redundant information. Every word adds meaning: 'Remove', 'all', 'active', 'block/mock routes' all contribute 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 0-parameter, no-output-schema tool, the description fully specifies the operation and its scope. There are no missing fields, return values to document, or additional configuration details required. An agent can call this tool correctly based solely on the description.

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 no parameters, and the schema is empty with 100% coverage. There is no parameter semantics burden on the description. The baseline of 4 applies because no parameter documentation is needed.

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 ('Remove') and a clear resource ('all active block/mock routes'). It differentiates itself from sibling tools like browser_route_block and browser_route_mock, which add routes rather than clear them. An agent can understand exactly what this tool does at a glance.

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 usage context clear: it removes all active block/mock routes. It does not explicitly name the alternatives or state when not to use it, but the contrast with route-setting siblings is strongly implied by 'block/mock routes' and 'Remove all.' This is sufficient for such a simple 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 discloses the key behavior: matching requests are intercepted and fulfilled with a canned response, bypassing the real endpoint. However, it omits important behavioral details such as whether the mock persists until cleared, whether it overrides existing routes, or how it interacts with browser_route_clear/browser_route_block. This is a meaningful gap for a routing 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 short sentences with zero filler. The first sentence front-loads the core action ('Mock matching requests with a canned response'), and the second adds a practical use case. Every word earns its place; there is no redundant repetition of the tool name.

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 route-mocking tool with fully documented parameters and no output schema, the description is largely complete. It states what the tool does and when it is useful. The only missing context is lifecycle and interaction with other routing tools (clear/block), which is a minor omission given the straightforward purpose and rich sibling set.

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% – every parameter (body, status, urlPattern, contentType) has a description in the schema. The tool description adds no parameter-level detail beyond the schema, so the baseline 3 is appropriate. The phrase 'canned response' loosely maps to body/status/contentType, but does not add meaning beyond what the schema already 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 and resource: 'Mock matching requests with a canned response (fulfill).' This clearly states that the tool intercepts network requests and returns a predefined response. It also differentiates itself from sibling tools like browser_route_block (blocking) and browser_route_clear (removing mocks) through the core 'mock/fulfill' behavior.

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 concrete context for when to use the tool: 'Useful for stubbing APIs or bypassing endpoints.' This tells an agent the typical scenarios, though it does not explicitly mention alternative tools or exclusion conditions. The context is clear enough to guide selection, but not as fully explicit as naming a specific sibling 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?

No annotations are provided, so the description must disclose behavioral traits itself. It only restates the world behavior already present in the schema ('isolated stealth world by default; set world:'main'...'), and fails to mention risks, side effects, return value, or error behavior—critical for an 'unsafe' code execution 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?

At two sentences, the description is concise and front-loaded with the core action and the browser_evaluate preference. The second sentence about world is relevant but duplicates the schema, so it is not entirely necessary. Overall, every sentence earns its place, though the duplication is a minor inefficiency.

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 executing arbitrary JavaScript, the description omits essential information: what the tool returns, whether it can disrupt the page, how errors surface, and security implications. With no output schema and no annotations, the agent is left to guess at critical behaviors, making the definition incomplete for safe and 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?

With schema description coverage at only 33% (only 'world' has a description), the description should compensate by explaining 'script' and 'args'. It does not—it only repeats the world guidance already in the schema. The description adds no meaning for the script or args parameters beyond their bare types.

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 the verb 'Execute' with a specific resource ('arbitrary JavaScript in page context'), and immediately distinguishes from browser_evaluate by saying 'Prefer browser_evaluate when possible.' This clearly identifies what the tool does and separates it from its closest sibling.

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 advises 'Prefer browser_evaluate when possible,' giving agents a clear directive on when to choose this tool over the alternative. It also explains the world parameter's behavior and when to set world:'main', providing practical usage context beyond the basic enum.

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 burden and covers key traits: results are written directly to disk, never returned in the response, base64 data prefixes are stripped automatically, and non-strings are JSON-stringified in text mode. It does not state whether existing files are overwritten or describe error/return behavior, leaving some side-effect 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?

The core purpose is front-loaded, but the description is a long, dense paragraph with a lengthy corruption warning and several parentheticals. Every part is relevant, but breaking it into clearer sentences would improve quick scanning.

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 is largely complete: it covers purpose, when to use it, encoding behavior, and the fact that the value is not returned. Minor gaps remain around file overwrite behavior, the exact response format, and clarifying that one of function/expression must be supplied.

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 describes path, world, and encoding, but function/expression have no schema descriptions. The description fills this gap by saying to pass 'function' or 'expression' (same as browser_evaluate) and adds encoding details beyond the schema: base64 prefix stripping and JSON-stringification of non-strings. It could more explicitly state that one of function/expression is 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 states a specific verb and resource: 'Evaluate JavaScript in the page and write the result straight to a file on disk.' It also distinguishes itself from browser_evaluate by emphasizing that the value never passes through the tool's response, making its purpose clear.

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 explicitly names browser_evaluate as the alternative and gives the exact condition for choosing this tool: when a large/opaque blob (base64, full HTML, big JSON) needs to leave the live page and enter a request body. It also warns against the corruption risk of reading via browser_evaluate and re-typing the value into another tool call.

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, and it does disclose meaningful behavioral traits: the CDP mechanism, headed/stealth compatibility, and the path-vs-base64 output split. However, it leaves gaps an agent would want before calling — what happens to an existing file at the path, what the base64 payload concretely looks like, and whether rendering is synchronous.

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 tight sentences, front-loaded with the core action and mechanism, followed by the output-mode behavior. Every clause earns its place; nothing is redundant 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?

Given there is no output schema and no annotations, the description covers the essential call decision (what it does, when it works, how output is returned) but omits details a caller might need for a professional use: the shape of the base64 return, file-overwrite behavior, and defaults for format/landscape. Adequate for a simple call, incomplete for robust use.

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 60%, with format and landscape having no schema descriptions. The description's only parameter-related content ('Saves to path, or returns base64 if path omitted') largely duplicates the path parameter's existing schema description, so it adds almost no meaning beyond the schema and does nothing to compensate for the two 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 names a specific verb ('Render') and resource ('the active page') with an explicit output format (PDF) and mechanism (CDP), which clearly scopes the operation and implicitly separates it from screenshot and blob-saving siblings. However, it does not explicitly name or contrast any sibling tool, so it falls short of full differentiation.

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?

Usage is implied: use this when you need a PDF of the current page. The note 'works in headed/stealth mode' adds a compatibility constraint that helps an agent predict success, but there is no guidance on when to prefer this over browser_take_screenshot, browser_save_blob, or other export tools, and no exclusions are 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'select options' and does not mention that the action changes DOM state, fires events, waits via timeout, or how frameSelector affects behavior. This is a meaningful gap for a browser 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, well-structured sentence with no filler. It front-loads the action and target, 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?

The schema documents most parameters, including iframe handling and value/label semantics, making the tool callable. However, with no annotations and no output schema, an agent gets little context about wait behavior or post-selection effects, so the description is only minimally 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 80%, so the baseline is 3. The description mentions 'CSS selector or aria ref' but adds no meaning beyond what the schema already documents; timeout behavior and value/label handling are left entirely to 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 uses a specific verb and resource: 'Select options from a <select> element.' It also names the two locator mechanisms, CSS selector or aria ref, which clearly distinguishes it from sibling click/fill/type 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 phrase 'from a <select> element' gives clear context for when to use this tool and implicitly distinguishes it from alternative interaction tools like browser_click or browser_fill. It does not explicitly name alternatives or exclusions, but the target element is unambiguous.

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 clearly discloses the destructive nature ('Clear all') and the exact scope ('active page's origin'), making the side effect explicit. It could add a warning about irreversibility, but the core behavior is 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?

A single, tightly written sentence that front-loads the action and scope with no filler. Every word contributes to understanding the tool's behavior.

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 destructive tool, the description is complete: it names the action, the target, and the boundary. An agent has enough information to invoke it correctly without additional context.

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 is empty with zero parameters, so there are no parameter semantics to explain. Per the baseline for zero-parameter tools, this is acceptable; nothing extra is needed from 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?

The description states a specific verb ('Clear'), a precise resource ('all sessionStorage'), and a clear scope ('for the active page's origin'). This distinguishes it from sibling tools like browser_sessionstorage_delete (single key) and browser_localstorage_clear (different storage).

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 implies when to use it: when all sessionStorage for the page's origin needs to be cleared. It provides the operative context, though it does not explicitly contrast with browser_sessionstorage_delete or mention when not to use it.

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 alone must disclose behavioral traits. It states that the action is a delete, but does not mention irreversibility, behavior when the key is missing, scope (page vs session), or side effects. This is thin for a destructive operation.

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, compact sentence that states the action and parameter without any wordiness. Every word earns its place, and the core behavior 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 one-parameter destructive tool, the description covers the essential action and parameter. However, without annotations or an output schema, it omits important behavioral context like irreversibility and missing-key behavior, which matters for safe 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. 'By key' clarifies that the single parameter identifies which sessionStorage item to remove, connecting the schema field to the operation. However, it adds no detail about the key format or value expectations.

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 ('Delete') and a clear resource ('sessionStorage item by key'), which precisely communicates a single-item deletion. This effectively distinguishes it from sibling tools like clear (all items) and get/set (read/write operations).

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 guidance on when to use this tool versus alternatives such as browser_sessionstorage_clear or browser_sessionstorage_delete. The distinction is only implicit from the name and wording, not explicitly 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully states that the tool returns null if the key is absent, but it does not mention the return type for present keys, page/origin context, or any other 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 sentence with no filler. The core operation is front-loaded and every word contributes to the 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 simple one-parameter getter, the description is close to adequate: it names the operation and the absent-key return behavior. However, with no output schema and no annotations, it omits the present-key return type and any context about which storage origin is accessed.

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 parameter documentation. 'By key' essentially restates the schema property 'key' without adding format, examples, or clarification of what counts as a valid key.

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 operation: getting a sessionStorage item by key. It also clearly distinguishes the tool from siblings like browser_sessionstorage_set, browser_sessionstorage_delete, and browser_localstorage_get.

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 no guidance on when to use this tool versus alternatives. It does not mention localstorage_get, sessionstorage_list, or any condition that would select this tool over a sibling.

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 itself carries the behavioral burden, and it does state the core behavior: a non-mutating listing operation restricted to the active origin. It does not disclose edge cases such as empty storage behavior or exact return formatting, but for a simple read-only storage listing these are minor gaps.

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 of nine words states the resource, action, and scope with no filler, repetition, or buried details. Every element 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 read with no output schema, the description is essentially complete: it names what is listed, which storage area, and the origin scope. It could add a sentence about return format, but 'key-value pairs' already implies the output shape.

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 is not required to add parameter-level detail; the baseline for a no-parameter tool is 4. The existing description contributes no parameter semantics, but none are needed.

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 the specific verb 'List' with the resource 'sessionStorage key-value pairs' and scopes it to 'the active page's origin', making the operation unambiguous. It is clearly differentiated from sibling tools such as browser_sessionstorage_get (single-key retrieval), browser_sessionstorage_clear (removal), and browser_localstorage_list (a different storage area).

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 guidance about when to choose this tool over alternatives or when not to use it. It does not mention sibling tools like browser_sessionstorage_get or browser_localstorage_list, so an agent must infer the intended use solely from the tool name and the generic 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention that setting an item overwrites an existing key, that sessionStorage is per-tab/origin, or any error conditions. The only added behavioral context is 'active page's origin', which is minimal.

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 states the action and scope with no unnecessary words. It is well-structured and 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 tool with two string parameters and no output schema, the description still falls short: it omits parameter semantics and usage alternatives. Without annotations or schema descriptions, the agent is left without enough information to call the tool confidently.

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 what 'key' and 'value' mean, how they should be formatted, or any constraints. With zero parameter documentation in both the schema and description, the agent cannot properly understand the inputs.

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 ('Set a sessionStorage item') and adds the scope ('on the active page's origin'), making the core purpose clear. However, it does not differentiate among the many storage siblings (localStorage, cookies), so it lacks explicit sibling differentiation.

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

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_localstorage_set, browser_cookie_set, or browser_storage_save. The description only states the action without any context or exclusions, leaving the agent to infer the appropriate choice from the 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 provided, so the description carries the burden. It discloses token-saving behaviors like /url line removal and data: URL collapsing, and implies a read-only operation via 'Return'. It does not describe the output shape or whether the snapshot is limited to interactive elements, but the ARIA snapshot concept is reasonably self-explanatory.

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: the first states the tool's output and token-saving behavior, the second explains exactly how to use the returned refs. Every sentence earns its place with no 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?

There is no output schema and no annotations, so the description must explain the returned snapshot and its purpose. It does mention refs and the distilled nature of the snapshot, but it does not cover the exact output layout, when to prefer this over text/HTML alternatives, or edge cases like maxLength truncation behavior beyond the schema.

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 maxLength and includeUrls are already documented. The description adds context about token efficiency but does not provide new parameter-level meaning 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 uses a specific verb ('Return') and identifies a distinct resource: a distilled AI-oriented ARIA snapshot. It also names concrete transformations (dropping /url lines, collapsing data: URLs), which clearly distinguishes it from sibling tools like browser_get_visible_text or browser_get_visible_html.

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 a clear downstream usage instruction: use [ref=eN] values with browser_click/fill/type/hover/press/wait_for. However, it does not explicitly say when to choose this tool over alternatives such as browser_get_visible_text, browser_find, or browser_evaluate.

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?

The description discloses non-obvious defaults, which is useful. However, with no annotations, it carries the full burden of explaining behavior, and it omits important side effects: whether starting is idempotent, what happens if a session already exists, whether a persistent profile is reused, and how the session is later cleaned up. For a stateful, resource-creating tool, this is a significant 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?

Two short sentences with no filler or repetition of schema content. The key information is front-loaded, and every phrase adds value by stating the action and the non-obvious defaults.

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 16 parameters, no output schema, and no return-value documentation, the description is far too thin. It does not say what the tool returns, how an agent knows the session is ready, or how the session relates to browser_status and browser_close. An agent could call it repeatedly or assume a session handle is returned when none may be.

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 only 38%, and the description mentions none of the parameters. It does not clarify ambiguous interactions like device vs mobile, browser vs channel, or how userDataDir relates to the default persistent profile. With over half the parameters lacking schema descriptions, the tool description needed to compensate and did 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 opens with a specific verb and resource: 'Start a browser session.' It also adds non-obvious launch defaults (patchright, chromium, headed, persistent profile). Among the large browser_* sibling set, it is clearly the lifecycle initializer and not confused with browser_navigate, browser_status, or browser_close.

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 phrase 'Start a browser session' implies that this is the entry point before using other browser tools, but the description never explicitly says 'call this first' or contrasts it with alternatives. There is no guidance about when not to use it, e.g. when attaching to an existing session via cdpEndpoint.

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 behavioral disclosure burden. It merely says 'return status' but does not clarify what status includes, whether it has side effects, or what the response format is. For a read-only tool this is under-specified; the agent cannot predict the output or side effects.

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

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

The description is one short sentence with no filler. It is maximally concise and front-loaded with the action. Every word earns its place, making it excellent in 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?

Given the lack of an output schema and annotations, the description must define what 'status' means. It does not—leaving the agent unsure of the return type, possible values, or even whether the operation could fail. For such a simple tool this is a notable gap, so completeness is low.

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 already documents that clearly. Per the rubric, 0 params earns a baseline of 4. The description does not need to elaborate on parameters since there are none, so this is adequate.

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