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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the check is loaded through the browser and therefore follows the configured proxy, which affects what rules are actually returned.

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, front-loaded with the core action and followed by the one non-obvious behavioral detail. Nothing is wasted.

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?

An output schema exists, so return values need no explanation, and the proxy/browser context is disclosed. However, the undocumented user_agent parameter leaves a real gap for a tool whose result is user-agent dependent.

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% for two parameters. The description implies the required url is used to derive the site, but it never explains the user_agent parameter or the fact that the effective rules depend on it (default '*'), which is the key semantic for a robots check.

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: checks robots.txt for the site of the given URL, and notes it also surfaces Crawl-delay. This is clearly distinct from siblings like read_url or navigate, though it doesn't name a sibling explicitly.

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 (check before fetching a URL) but never stated as a when-to-use rule, and no alternative or exclusion is given. An agent can infer the context but must do the work itself.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful framing that it inspects the 'live session' (i.e., current runtime state, not a static profile), but says nothing about prerequisites such as an open tab or whether values reflect the last navigation.

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, and the parenthetical examples do real work by naming the signals. The trailing ellipsis leaves the enumeration open-ended, which is slightly loose but far better than padding.

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?

An output schema exists and a zero-parameter surface is trivial, so the description does not need to explain return values. The only real gap is the precondition (an active browser session/tab), which an agent must guess before calling.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly signals a parameterless call by not implying any input 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?

States a specific verb ('Report') and resource ('automation-detection signals of the live session') and enumerates the concrete signals (webdriver flag, UA, WebGL, plugins), so the agent knows exactly what is returned. It does not distinguish itself from the nearby sibling fingerprint_info, which plausibly overlaps, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer this verifies stealth before/while scraping, but the description never says when to run it, whether a page must be loaded first, or that fingerprint_info is the alternative for static profile data. No exclusions or alternatives are named.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is largely covered, and the description usefully adds the "all"/"current context" scope. However it omits that this logs the user out of the context and is not undoable — meaningful caveats given the tool clears state wholesale. The tension with destructiveHint=false is worth noting but cookie clearing is recoverable session state, so it is not a true contradiction.

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; verb and scope arrive immediately.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Still, for a state-clearing tool the description doesn't say whether it applies across all tabs in the context or whether it requires a loaded page, leaving an agent to guess at invocation conditions.

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

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

The tool takes zero parameters, so the schema carries no semantic load the description must compensate for; the baseline for a parameterless tool applies. The description does add the one scope qualifier that matters (current context vs all contexts).

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 ("Delete") and resource ("cookies") plus a scope qualifier ("all", "current context"). It implicitly distinguishes itself from get_cookies/set_cookies, but never names those siblings or clarifies the boundary explicitly.

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 reach for this versus get_cookies/set_cookies, no prerequisite (must a page be loaded in the context?), and no mention of the consequences of wiping all cookies versus selectively removing them.

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?

Annotations already declare that this is not read-only, is open-world, and is not destructive. The description adds no behavioral context beyond that: it does not say whether clicking waits for actionability, may trigger navigation, or what side effects to expect. The selector syntax it provides is parameter semantics rather than behavioral disclosure.

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

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

The description is a single front-loaded sentence with no filler. It efficiently conveys the core action and target formats.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with 0% schema coverage the missing explanation of `double` and the absence of any click behavior detail leave this inadequate for a browser interaction tool.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It explains the selector parameter well by naming snapshot refs (e12) and CSS/text forms, but it completely omits the `double` boolean parameter, leaving half the parameters 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 states a specific verb (click) and resource (an element), and it specifies acceptable target formats (snapshot ref e12 or CSS/text selector). It does not explicitly distinguish itself from nearby siblings such as hover or type_text, so it is clear but lacks 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?

It implies that the tool is used for clicking, but it gives no when-to-use guidance, no exclusions, and no alternatives such as hover or type_text. An agent must infer the selection context from the tool name and sibling 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?

Annotations declare this a non-read-only, open-world, non-destructive operation; the description adds the meaningful context that persistent profiles survive, so the agent knows closing does not wipe stored identity/session state. It stops short of describing whether in-memory state is discarded or what the output contains, but the key data-loss question is answered.

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 short sentence with the action front-loaded and the important caveat parenthesized immediately after. 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?

For a parameterless teardown tool with annotations and an output schema, the description covers the essential fact (profiles persist) and the resource outcome. Only marginal additions -- behavior of active tabs or in-flight steps after close -- are missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. No misleading hints about arguments are given.

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 ('Close the browser') plus the side effect ('free resources'), which is distinct from the tab-level sibling tab_close. It does not explicitly name that sibling as different, so the differentiation is implied by the resource scope rather than stated.

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 (teardown / end of session) but never stated, and there is no guidance on when to use tab_close instead of closing the whole browser, nor on when closing would be inappropriate (e.g. mid-run_steps). An agent must infer the call conditions.

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?

Annotations only say it is a non-destructive, open-world mutation; the description adds the key operational facts: the browser restarts, profile='name' preserves cookies/logins while '' discards them, and reset_fingerprint clears overrides. It does not say whether restart interrupts in-flight sessions or what the response contains, but the side-effect disclosure is well above the annotation baseline.

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?

Front-loaded with the core action and restart semantics, then a dense semicolon-separated parameter map that is efficient for 20 fields. Dense but no filler sentences.

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?

Output schema exists so return values need no explanation, and the restart/persistence behavior is covered. However, for a 20-parameter tool with zero schema documentation, leaving locale/timezone/geoip and the proxy vs proxies pair unexplained is a meaningful gap for correct invocation.

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

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

Schema coverage is 0%, so the description carries the burden and does explain roughly two-thirds of the 20 parameters (profile, proxy, headless, capture_console, human_preset/human_config, fingerprint_seed, platform/gpu_vendor/hardware_concurrency/screen_*, brand, reset_fingerprint). It never explains locale, timezone, geoip, humanize, restart, or the distinction between 'proxy' and 'proxies' — a potentially costly ambiguity left unaddressed.

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 ('Change browser settings at runtime') and immediately clarifies the default read behavior of no arguments. It does not explicitly distinguish itself from siblings like new_identity, rotate_proxy, or fingerprint_info, even though fingerprint_seed overlaps conceptually with those.

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?

Gives concrete conditions: no args = show current, headless=False for captchas, proxy='' clears the proxy. Missing is any routing guidance versus new_identity or rotate_proxy, which an agent would plausibly confuse with profile/fingerprint/proxy changes here.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds non-obvious behavior beyond them: console events are suppressed by the stealth layer unless capture is enabled. This is exactly the kind of hidden-state disclosure structured fields cannot convey. It says nothing about how the buffer behaves when 'clear' is set, which is the remaining transparency 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 sentences, no waste: the first states scope and payload, the second states the prerequisite and the reason for it. Front-loaded correctly.

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?

Output schema exists, so return values need no explanation, and the capture prerequisite is covered. However, for a tool whose only two parameters are undocumented, the description leaves an agent guessing at 'clear' semantics (buffer reset vs filter) and 'limit' behavior, which is the one thing it should have added.

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% for both parameters, so the description carries the full burden and provides nothing: 'limit' (default 50) is unexplained in meaning or bounds, and 'clear' is not mentioned at all despite implying a destructive buffer reset in a tool annotated readOnlyHint=true. The description adds no meaning beyond the raw schema.

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

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

States a specific resource and scope: recent console messages and JS errors of the current tab. An agent can distinguish this from list_network_requests or snapshot without opening the schema. It stops short of naming a sibling it is not, so not 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?

Gives a concrete precondition: configure(capture_console=True) must be called first, and explains why (CloakBrowser hides CDP console events). That is a real routing constraint rather than vague context. It does not say when to prefer this over evaluate or list_network_requests, so not 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?

Adds substantial behavior beyond what annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) convey: the fetch executes inside the current page, inherits session cookies and proxy, has cross-origin constraints, and is the only working path for downloads since native download handling is disabled. That is exactly the context an agent needs.

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?

Front-loads the action and the target semantics, then adds the cross-origin caveat and the rationale parenthetical. Dense but each sentence carries information; the parenthetical is slightly long but justifies its presence.

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?

An output schema exists, so return values need no explanation, and the definition covers session reuse and cross-origin behavior thoroughly. The only real hole is the unexplained `max_mb` cap and default filename behavior, which an agent would want to know before large downloads.

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 carry the weight; it explains `target` well (URL vs. selector/ref, href/src extraction) but says nothing about `max_mb` or `filename`, leaving two of three parameters undocumented in both schema and 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?

States a specific verb and resource ('Download a file into the output dir') and clarifies exactly what `target` accepts. It does not name its closest siblings (save_pdf, save_html, screenshot_file), but the purpose is distinct enough that an agent would not confuse it with 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?

Gives explicit routing guidance: cross-origin files require navigating to that site first, and 'use this instead' when clicking a download link, because CloakBrowser cancels native download handling. Strong for the main decision, though it does not cover when to prefer save_pdf/save_html over this 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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds real value beyond them: results are wrapped as untrusted page content, which is a critical prompt-injection warning the annotations do not convey, plus the environment-variable kill switch. It stops short of noting timeouts, async/promise handling, or which frame context the script runs in.

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, zero padding, with the operative capability and the return semantics front-loaded and the availability gate attached as a compact parenthetical-style clause.

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?

An output schema exists, so the description is not obligated to explain return values, and it already flags the untrusted-content wrapping and the disable condition. The remaining gap is execution semantics (async support, timeout, target frame), which matters for a script-running tool but is narrower than a fundamental omission.

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

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

Schema coverage is 0% and the single parameter is bare `script: string`, so the description must compensate. "JS expression or arrow function" does add meaningful shape information — it is not an arbitrary statement block — but the contract is still ambiguous: whether the arrow function is invoked for you, whether async/await works, and how the return value is serialized are all left to inference.

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?

A specific verb-plus-resource statement: run a JS expression or arrow function in the page and get the result back as JSON. It is clearly distinct from the sibling extraction tools (get_text, extract_structured, extract_tables) because it executes arbitrary code rather than a fixed extraction, though it never names those siblings explicitly.

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 supplies a real gating condition ("Disabled when CLOAK_ALLOW_EVAL=0") that saves the agent a failed call, but it gives no explicit when-to-use vs when-to-use-an-alternative guidance — nothing says to prefer extract_structured or get_text for routine scraping, or that this is the escape hatch for page-specific logic.

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?

Annotations already declare this as a safe read-only, non-destructive operation, so the bar is lower. The description usefully discloses the output shape and that pattern matches href or text, but it does not disclose that the default limit of 100 caps results or that unique=true deduplicates by default, despite saying 'All links'.

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

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

The description is two tight sentences with no filler and is front-loaded with the main result shape. Every phrase contributes either output structure or parameter 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?

An output schema exists, so return-value details need not be repeated. However, for a three-parameter tool with zero schema description coverage, the description leaves limit and unique semantics unexplained and does not flag the result cap implied by limit=100.

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

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

Schema description coverage is 0%, so the description must compensate. It explains pattern well as a regex matched on href or text, but limit and unique are completely undocumented in both schema and description, leaving two of three parameters without 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?

The description states a specific verb and resource: it extracts all links from the page and returns them as JSON objects with text and href. It does not explicitly differentiate this from sibling extraction tools such as get_text, get_html, find_in_page, or extract_structured, so it stops short of a 5.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives like find_in_page, get_text, or evaluate. Usage is only implied by the phrase 'All links on the page', 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?

Annotations already establish read-only, open-world, non-destructive behavior. The description adds what data is targeted and a reliability/cost comparison, but it does not explain pagination/truncation via offset/max_chars or the extraction scope.

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 dense sentences are front-loaded with the data types and followed by a practical comparison. There is little waste.

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?

An output schema exists, so the description need not document return values, and it does communicate the main product fields. However, with zero schema parameter descriptions, the omission of offset/max_chars behavior leaves the call semantics incomplete.

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

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

Schema description coverage is 0%, and the description never mentions offset or max_chars. The parameter names and defaults give minimal clues, but the description does not compensate for the missing schema documentation.

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 the specific embedded formats (JSON-LD, OpenGraph, microdata, common meta tags) and a schema.org Product summary, so the resource and output focus are clear. It does not explicitly distinguish itself from the sibling extract_structured, leaving some overlap.

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 offers an implied usage context by saying this is often more reliable and cheaper than CSS scraping on shops. However, it does not state when to choose this over extract_structured or other extraction siblings, nor does it give 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the extraction spec format ('css', 'css@attr', '@attr'), which is useful, but says nothing about pagination, the limit default, or what happens with zero matches.

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

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

The description is three lines long, front-loads the core purpose, and uses the remaining space for an immediately usable example. 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?

With an output schema present, the description needn't explain return values, and it covers the two required parameters thoroughly. The only omission is the optional 'limit' parameter and any note on behavior when no items match.

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 carry parameter meaning; it does so well for 'fields' and 'item_selector' via the syntax rules and a full example. The 'limit' parameter (default 50) is not mentioned anywhere in the description or schema, leaving one gap.

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

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

The description states a specific verb and resource ('Extract repeated items ... as JSON') and gives a concrete example (product cards), which differentiates it from sibling extraction tools like extract_tables or extract_links without ambiguity.

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

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

The phrase 'repeated items (e.g. product cards)' clearly signals when the tool applies, but it never names alternatives such as extract_tables or get_text, nor does it state exclusions. The context is clear though the routing guidance is left implicit.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds only the record shape, which duplicates the existing output schema, and says nothing about what happens at the max_rows/max_tables caps (truncation, flags, partial results).

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

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

It is a single punchy line with the output shape front-loaded and no filler. However, the brevity crosses into under-specification — it reads as a schema fragment rather than a sentence that helps an agent decide to call it.

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?

An output schema exists, so return values needn't be re-explained, but two undocumented parameters at 0% coverage and zero usage context leave real gaps. For an extraction tool that paginates/limits results by default, the definition should say what the limits do.

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% for two parameters, so the description carries the full burden and does not meet it: max_rows and max_tables are never mentioned, nor are their defaults (50, 10) or whether exceeding them truncates or errors. The only implicit link is 'rows' hinting at row-level output.

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

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

The phrase 'HTML tables as JSON' states a concrete transform (table extraction to structured output) and the bracketed shape [{caption, headers, rows}] confirms what the tool produces. It doesn't distinguish itself from nearby siblings like extract_structured or get_html, so it stops short of a 5.

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

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

No guidance on when to prefer this over extract_structured, get_html, or find_in_page. There's no mention of prerequisites (e.g., that a page must be loaded/navigated first) and no exclusions, leaving the agent to infer usage 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?

Annotations already establish that this operation mutates state (readOnlyHint=false) and is non-destructive. The description adds valuable context the annotations do not cover: typed=True simulates human key-by-key input, which affects bot scoring; the default follows the humanize setting; and a submit click can be appended, which has its own side effect. It does not describe what happens when a selector fails or how navigation after submit behaves.

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 tight sentences, with the core operation and parameter map front-loaded before the optional behavior and the typed nuance. 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?

Since an output schema exists, return values needn't be explained, and the annotations cover the safety profile. The description still leaves error and partial-fill behavior and post-submit waiting unspecified, but everything needed to invoke it 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?

Schema description coverage is 0%, so the description has to carry the parameters, and it does: it gives the shape of fields, the optional-submit role of submit_selector, and the Boolean and default semantics of typed. The only gap is submit_selector's empty-string default and the 'ref' half of selector_or_ref.

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: fill several inputs at once, driven by a {selector_or_ref: value} map, with an optional submit click. This bulk-fill scope separates it from the single-input siblings type_text and click, though those alternatives are never named.

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?

"Fill several inputs at once" implies that the single-field case belongs to another tool, and the submit_selector gives a clear optional action. However, no sibling is named and no prerequisites or 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description usefully adds case-insensitivity and that offsets are relative to get_text. It does not disclose regex behavior, default match cap, or whether matches are truncated.

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 dense sentences, front-loaded with the action and the cost trade-off, no filler. Every clause carries information an agent can act on.

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?

An output schema exists so return values needn't be explained, and the get_text offset linkage is a nice touch. But with zero schema coverage, the four parameters remain largely unexplained, leaving a real gap for a tool with a regex switch and a cap.

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 carry all four parameters and it only alludes to one ('surrounding context'). regex, max_matches, and the query syntax are left entirely undefined.

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?

Specific verb (search) plus resource (page text) plus output shape (matching snippets), and it explicitly contrasts with reading the whole page, which routes it against the sibling get_text. An agent can distinguish it from snapshot/get_text/extract_structured purely from the description.

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?

'far cheaper than reading the whole page' gives a clear selection rule versus get_text, and the stated case-insensitivity removes a common ambiguity. It stops short of saying when to prefer regex mode or when a full read is still required.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine value by indicating it reports both the configured overrides and the actual live values — implicitly a comparison — but doesn't state whether the live values require an active browser session.

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 with no filler, and the dual-return nature is front-loaded. It is efficient, though the terseness is what leaves the usage gaps noted above.

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

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

With an output schema present, the description needn't explain the return shape, and the zero-parameter schema needs no coverage. The only real omission is the session prerequisite, which matters little for a read-only diagnostic.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The empty schema is consistent with the description's read-only inspection framing.

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 the two things returned (configured overrides and live browser-reported values) but uses a noun phrase with no verb, so the agent must infer this is a read/inspection tool. It also doesn't distinguish itself from the nearby check_stealth sibling, which plausibly covers overlapping territory.

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 statement of when to call this versus alternatives such as check_stealth or configure, nor any prerequisite or exclusion. The agent is left to infer usage entirely from the name and the returned-data hint.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that results are returned as JSON and can be filtered, but says nothing about pagination, cookie volume, or what happens if no context exists.

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

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

A single efficient sentence that front-loads the resource and appends the filter behavior. Nothing wasted.

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?

An output schema exists, so return values need no explanation, and annotations cover safety. The only remaining gap is the url_filter versus domain-substring ambiguity, which slightly undercuts a full picture for a simple read tool.

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

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

Only one parameter with 0% schema coverage, so the description must carry meaning, and 'optionally filtered by domain substring' does explain the filter's intent. However, it describes a 'domain substring' while the parameter is named url_filter, a mismatch that could mislead about what is actually matched.

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 clear verb (get) and resource (cookies of the browser context) plus return format (JSON), which distinguishes it from set_cookies and clear_cookies. It does not explicitly name those siblings, but the read nature is unambiguous.

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

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

There is no explicit guidance on when to use this versus set_cookies, clear_cookies, or save_session, and no stated preconditions (e.g., an active browser context). Usage is only implied by the verb.

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?

Annotations already cover safety (readOnly, non-destructive, open-world), but the description adds a genuinely important trait they don't: the returned content is untrusted page content, which flags prompt-injection risk. It doesn't mention truncation/large-output behavior implied by max_chars, so it stops short of a 5.

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, zero filler, with the core return value front-loaded and the routing hint immediately after.

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?

An output schema exists so return format needn't be described, and the untrusted-content warning is valuable. But for a 3-parameter tool with 0% schema coverage, an agent still can't tell how offset/max_chars interact with the HTML output (raw offset paging vs truncation), leaving a real gap.

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

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

Schema description coverage is 0% and the description only hints at 'selector' via 'of an element'. offset and max_chars — clearly truncation/paging controls on a potentially huge HTML payload — are left entirely unexplained, and defaults (selector=body, max_chars=8000) are never surfaced in prose.

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

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

States the specific resource precisely: 'Outer HTML of an element', naming the exact serialization (outer HTML, not inner text or markdown). It distinguishes itself from get_markdown by pointing at markup detail use. Slightly fragmentary and doesn't mention scope (whole page vs element) explicitly, keeping it off 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?

'Prefer get_markdown; use this for markup details' gives an explicit default and the condition that selects this tool instead. It doesn't address other near neighbors (save_html, get_text, extract_structured), so routing is clear for the main alternative only.

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?

Annotations already declare read-only, non-destructive, open-world behavior. The description adds useful context beyond annotations, including untrusted content, main_only filtering, links cost tradeoffs, and pagination via offset.

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 compact and front-loaded: format and scope come first, followed by key option behavior and the find_in_page alternative. Every sentence carries useful 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?

An output schema exists, so return-value detail is not required. The description covers the main behavioral choices and pagination, but gaps around selector and max_chars keep it from being fully complete for a five-parameter tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains links modes, main_only, and offset well, but does not explain selector or max_chars, leaving two of five parameters undocumented 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 resource and output format: page or element content as compact markdown. It distinguishes itself from find_in_page, though it does not explicitly differentiate from siblings like get_text, get_html, or snapshot.

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 alternative for a common case: 'to look for one thing use find_in_page instead.' It also explains main_only and links behavior, but does not fully state when to choose this over get_text/get_html/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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the body is from a recorded response and comes from a listed request index, but it does not disclose truncation behavior despite `max_chars`/`offset` parameters.

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 definition is a single front-loaded sentence with zero filler. Every part of the sentence contributes to locating the resource and identifying the relevant index source.

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?

An output schema exists, so return-value details need not be explained. However, with 0% schema description coverage, the description should explain `offset` and `max_chars` behavior, especially truncation, and it does not. The tool is usable but under-described for its three parameters.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It clarifies that `index` refers to an item from `list_network_requests`, but says nothing about `offset` or `max_chars`, leaving two of three parameters undocumented beyond their names and defaults.

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 resource as the body of a recorded network response and ties it to the `index` from `list_network_requests`, which distinguishes it from that sibling. It is specific enough to select correctly, though it uses a noun phrase rather than an explicit verb.

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 mention of `index` coming from `list_network_requests` implies this tool is used after listing requests, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. Usage is inferable 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?

Annotations already cover the safety profile (readOnly, non-destructive, openWorld). The description adds genuinely non-obvious behavior: the content is returned as untrusted page content, and long output is paged with an offset token surfaced in the response. Truncation/resume mechanics are the real value-add here.

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 scope, followed by the paging rule. No filler, no restating 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?

An output schema exists and annotations cover safety, so the description needn't explain return shapes. It covers scope, untrusted-content handling, and pagination resume, though it omits explicit sibling disambiguation among the many read/extract 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 carry parameter meaning. It clarifies the 'default whole page' behavior (selector) and explains the offset continuation workflow, but says nothing about max_chars or what selector syntax is accepted, leaving the agent to infer from defaults.

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+resource (get visible text of an element, defaulting to the whole page) and clarifies the output framing ('wrapped as untrusted page content'). It doesn't distinguish itself from close siblings like get_markdown, get_html, or snapshot, so an agent cannot tell from the description alone which extraction tool to pick.

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 rather than stated: the paging instruction ('pass offset=N from the call again with offset note to continue') gives a concrete follow-up workflow. There is no when-to-use/when-not guidance and no reference to alternative text-extraction 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?

The annotations provide the necessary safety profile (non-destructive). The description itself is just a functional statement of intent. It provides minimal unique behavioral context beyond what is implied by the action 'go_back'.

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 definition is extremely concise and front-loaded, providing the essential action ('Navigate back') and the scope ('in history') in a single sentence with zero 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 zero-parameter browser action tool, the description is minimally complete. However, it lacks detail on whether this action is limited to one step back or traverses the entire history stack, which could be relevant in a complex agent workflow.

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?

Since the tool has zero parameters and 100% schema description coverage, the description does not need to compensate for the lack of schema detail. The brief sentence is functionally sufficient for a parameter-less 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 uses a specific action and resource ('Navigate back in history'), making the purpose clear. It is slightly less specific than a 5 because it doesn't explicitly differentiate itself from siblings like 'reload' or 'navigate' based purely on the 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 offers no guidance on when to use this tool relative to alternatives. Since 'navigate' and 'reload' are siblings, the AI agent might not know if this is for simple history traversal or if it should use the broader 'navigate' function.

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?

Annotations already declare that the tool is not read-only, not destructive, and open-world. The description adds some behavioral context by noting that it 'shows recent ones,' implying a read-like return, but it does not explain whether the chosen action applies to future dialogs only, whether recent dialog history is preserved, or what the output contains. With annotations covering the safety profile, the added context is useful but not complete.

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 the core configuration behavior front-loaded. The appended 'and show recent ones' mixes a second function into the same clause, but there is no filler or repetition.

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?

Because an output schema exists, the description does not need to explain return values. Annotations cover the general safety profile, and the parameter values are supplied. However, for a browser-automation configuration tool, the description never states the scope of the setting, its persistence, or how it relates to actual dialog occurrences during navigation, leaving moderate contextual 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 description coverage is 0%, so the description must carry semantic weight. It does by defining the accepted values ('accept' or 'dismiss') for the single action parameter, which the schema does not express as an enum. It does not explicitly name the parameter or describe how the default interacts with omitted values, but the meaning is clear.

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 combination: it sets how JS alert/confirm/prompt dialogs are handled and also shows recent ones. This is clear enough for an agent to select the tool without opening the schema, although there is no sibling tool dedicated to dialog handling, so explicit differentiation is unnecessary.

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 does not say when to use this tool versus alternatives, nor does it give any prerequisites or exclusions. It implies that the tool configures dialog behavior and reports recent dialogs, but an agent receives no guidance on when to call it or how it interacts with other browser-automation tools.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but the description adds no behavioral context beyond those fields. It does not mention whether hovering triggers UI events, requires visibility, or has any side effects, leaving the agent with only the annotation safety profile.

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 wasted words, but it is under-specified rather than appropriately concise. It is front-loaded but omits essential context, so efficiency comes at the cost of clarity.

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 and has both annotations and an output schema, which cover safety and return-value concerns. Still, the description leaves critical gaps around selector semantics and when to use hover, making it only minimally viable for an agent to invoke correctly.

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

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

Schema description coverage is 0%, and the description does not explain the required 'selector' parameter—its format, whether it accepts CSS or XPath, or how to identify the element. The agent gets no semantics beyond the parameter name.

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 clear verb ('Hover') and target ('an element'), making the action understandable and distinguishable from sibling tools like click or type_text. However, it does not differentiate itself further or clarify whether this is a browser-specific hover 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?

There is no guidance on when to use hover versus alternatives such as click or scroll, and no prerequisites or exclusions are mentioned. The agent must infer usage entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the meaningful scoping detail that results are limited to files saved via download_file, but says nothing about session lifetime, ordering, or pagination.

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 short sentence with no waste and the key qualifier (saved so far with download_file) front-loaded. It is a fragment rather than a full sentence, which is fine at this length but leaves no room for the missing usage 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?

An output schema exists and annotations cover the safety profile, and with no parameters the surface is small. The description supplies the one thing structured fields lack, namely that this lists files produced by download_file, making it 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?

Zero parameters, so the baseline is 4; there is nothing the description could add about inputs and it correctly stays silent.

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 resource (files downloaded) and ties it to the sibling tool that produces them (download_file), making it distinguishable from extract_links or save_pdf. The verb 'list' is implied only by the tool name, not stated in the description itself.

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 statement of when to call this versus alternatives such as read_url or extract_links, nor any prerequisite or exclusion. The agent must infer usage 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?

Annotations already declare this as a safe, read-only, open-world read operation. The description adds useful scope and a chaining hint, but it does not say what order results are returned in, how many are returned by default, or whether only responses are included.

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

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

The description is short and front-loads the main scope before filtering and chaining details. The phrase 'Use the `i`' is slightly cryptic, but overall the structure is efficient.

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?

An output schema exists, so return value details are less necessary, and annotations cover safety. However, with all three input parameters undocumented in the schema, the description should do more to explain limit behavior and the request-versus-response scope.

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 carry parameter meaning. It usefully explains url_pattern as a regex and resource_type with example values, but leaves limit completely unclarified and does not specify default or ordering semantics.

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 resource and scope: recent network responses of the current tab. It also names filtering dimensions and a follow-up relationship with get_response_body, though it does not explicitly resolve the name's 'requests' wording versus the description's 'responses' wording.

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 clear context for use: inspect recent tab network responses, filter by URL regex/resource type, then use the returned index with get_response_body to read an API reply. It does not name exclusions or compare against siblings like console_logs or 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this mutates state without being destructive; the description's mention of cookies and localStorage is consistent with that. It doesn't disclose whether existing cookies/storage are overwritten, whether the browser must be at a matching origin, or what happens on a name miss – relevant context for a state-mutating 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 front-loaded sentence that identifies the action, payload, and target, 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?

An output schema exists, so return values need not be explained, and the core action is clear. However, for a state-mutating restore tool the description leaves the 'name' selector undocumented and omits overwrite behavior, which an agent needs to call 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 coverage is 0%, so the schema documents nothing about the single 'name' parameter, and the description never mentions it at all – no indication that it selects which saved session to restore or that it defaults to 'default'. This is the main gap in the definition.

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 (restore) and resources (cookies and localStorage) with a clear scope (current browser), and anchors itself to the sibling save_session, so an agent can distinguish it from set_cookies or get_cookies without opening the schema.

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

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

The pairing with save_session makes the usage condition clear (rehydrate a previously saved session), but it never states prerequisites such as an already-open browser or what to do if no saved session exists, and it doesn't contrast with set_cookies as an 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?

Beyond the readOnly/openWorld annotations, the description adds two behaviors an agent could not infer: results are gated to what the user enabled, and returned note text is untrusted data whose embedded instructions must be ignored. That injection-defense warning is genuinely valuable. It still omits how results are ordered/paged or what an empty query does.

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, front-loaded with the capability and ending with the safety warning, with no filler. The first sentence is slightly dense with parenthetical examples but still earns its 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?

An output schema exists, so return-value explanation is rightly omitted, and permission gating plus untrusted-content handling are covered. Missing are the semantics of the 'limit' param, how site and query combine, and the behavior when neither is supplied — for a 3-param tool with zero schema documentation, that leaves real 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 0% with three undocumented params, so the description must compensate: 'site' and 'query' are recoverable from the two described modes, but 'limit' (default 10) is never mentioned and no format examples are given. Partial compensation only.

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 the resource (stored memory about a site: stats, working browser settings, page types, notes) and a second mode (search over saved notes), so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from the close siblings memory_status and memory_request_access, so a 4 rather than 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?

The two modes (site lookup vs note search) are implied by 'about a site ... or a search over saved notes', which gives some selection guidance. However, it never says when to prefer this over memory_status/memory_request_access, nor what to do when access has not yet been enabled, so usage is only implied.

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

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

Beyond the annotations, it discloses important behavior: the user is prompted through the client, memory remains off by default, the agent cannot enable it directly, and a fallback returns instructions if the client cannot show the prompt. These details materially help the agent understand the consent flow and limits.

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 front-loaded with the core action and then adds the key default-state and fallback behavior in two compact sentences. There is no redundant or filler language.

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 empty input schema, existing annotations, and the presence of an output schema, the description covers everything an agent needs: what the tool does, that memory is opt-in, that the agent cannot self-enable it, and what happens when the prompt is unavailable.

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 there is no parameter semantics burden and the schema is effectively complete. The description does not need to explain inputs, and the baseline for zero-param tools is 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 action and resource: ask the user whether site memory may be enabled and what it may store. It also clearly differentiates this consent-request tool from memory read/status operations by saying the agent cannot enable memory itself.

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 clear context that memory is off by default and nothing is remembered until the user agrees, which strongly implies when this tool is needed. However, it does not explicitly name alternatives such as memory_status or memory_recall, so it falls short of full when/when-not routing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context about the status facets (enabled categories, scope, retention, effort, stored data), but does not disclose authorization requirements, rate limits, or data freshness.

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 with no wasted language, front-loading the core idea that this reports what memory is currently allowed to do.

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

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

With an output schema present and zero parameters, the description does not need to explain return values in detail. It sufficiently covers the scope of the status report, though it could state more explicitly when an agent should call it relative to other memory 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?

The tool takes no parameters, so the baseline is 4. There is nothing for the description to clarify beyond the fact that it is a zero-argument status query, which is implicit from 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 identifies a specific resource—current memory permission/status—and enumerates the facets it reports: enabled categories, scope, retention, effort, and stored data. It is clearly more than a tautology, but it does not explicitly distinguish itself from siblings memory_recall or memory_request_access.

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: an agent would check this before attempting memory operations. However, the description gives no explicit when-to-use guidance, no exclusions, and does not name the alternative tools memory_recall or memory_request_access.

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?

Annotations only declare not-read-only, open-world, non-destructive. The description adds real operational context: private-address blocking gated by CLOAK_ALLOW_PRIVATE=1, the returned fields, a BLOCKED? bot-challenge hint, and that retries=N re-tries with a fresh identity.

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?

Front-loads the action and scheme restriction, then stacks behavior and parameters without filler. It is dense in a way that rewards careful reading but every clause carries 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 4-parameter, open-world navigation tool with an output schema, it covers invocation, defaults, blocking rules, retry semantics, and the sibling handoff. Return values are already in the output schema, and the description only adds the BLOCKED? hint on top.

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 carry all four parameters, and it does: url format/blocking, retries as fresh-identity re-attempts, wait_until with its four enum values, and settle_ms as auto-selected from prior site experience unless set.

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 ('Open a URL') plus scope constraints (http/https, private addresses blocked). It explicitly distinguishes itself from the read_url sibling, so an agent can route without opening either 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?

Names the alternative explicitly: 'To open AND read a page in one call, use read_url.' That is a clear selection rule, though it does not cover other navigation-adjacent siblings (tab_new, reload, go_back) or state when this tool alone is insufficient.

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?

Annotations declare this mutates state without being marked destructive; the description adds the key behavioral fact that the browser restarts, plus the non-obvious override of a persistent profile's pinned seed. It stops short of saying what the restart loses (session, cookies), which is the main side effect an agent should know about.

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 primary behavior front-loaded and no filler. The trailing clause 'while it is set' is slightly ambiguous about where the seed is set, costing a bit of crispness.

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

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

With no inputs and an output schema present, the description covers the essentials: what changes, that it restarts, and the seed-override interaction. What is missing is the consequence of the restart on existing session state.

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

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

The tool takes zero parameters, so the schema carries little burden and the baseline is 4. The mention of an 'explicit seed' relates to profile config rather than an argument here, so there is nothing more the description needs to add.

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 gives a specific action and resource: generate a fresh browser fingerprint from a new random seed and restart the browser. It is distinct from rotate_proxy/fingerprint_info by implication (fingerprint vs. proxy vs. inspection), but does not explicitly name or contrast with those 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?

'Use after a block' gives a clear triggering condition for when to call it. There is no explicit guidance on when NOT to use it (e.g., versus rotating a proxy after a block) or what prerequisites exist.

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?

Annotations already declare that the tool is not read-only, may interact with an open world, and is not destructive. The description adds only key-format examples and does not explain where the keypress is directed, whether it can trigger navigation or dialogs, or any other side effects beyond what annotations provide.

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 definition is a single short sentence with no filler. The action is front-loaded and the examples are compact while still clarifying the parameter format.

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?

An output schema exists, so return values need not be explained. However, for a browser key-press tool, the description should clarify focus requirements and typical outcomes. It is minimally adequate but leaves meaningful contextual 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 single parameter has 0% schema description coverage, so the description must carry the burden. It usefully gives examples of valid key values and combo syntax, but it does not document modifier ordering, accepted key names beyond the examples, or whether case matters.

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: pressing a key or key combination. It gives concrete examples such as Enter, Escape, Control+A, and PageDown, making the purpose clear. It does not explicitly differentiate itself from siblings like type_text or click, which prevents 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?

The description provides examples of key values but gives no guidance on when to use this tool instead of alternatives such as type_text, click, or fill_form. It also omits prerequisites like ensuring the right element is focused before pressing a key.

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?

Adds real behavioral context beyond annotations: 'Blocked pages return just the status line' tells the agent how failure looks, and the mode/query switches are disclosed. However, annotations say readOnlyHint=false and the description never explains that loading a URL mutates browser state (current page/tab), nor does it cover caching (use_memory), retry behavior, or wait semantics for a 12-parameter open-world 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?

Front-loaded with the primary purpose and the sibling it replaces, then parameter notes in descending importance. It is dense and telegraphic but nearly every clause carries information; only the fragment style slightly hurts readability.

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?

An output schema exists, so return values needn't be described. But for a 12-parameter, open-world fetch tool with helper siblings, omitting truncation (max_chars/offset), main_only, and wait/settle semantics leaves genuine gaps an agent will hit on long or JS-heavy pages.

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 carries the full burden, yet it explains only 3 of 12 parameters (mode, query, with_refs). Nine parameters — offset, max_chars, main_only, links, retries, settle_ms, use_memory, wait_until — are completely undocumented anywhere, leaving the agent to guess at truncation, pagination, and timing behavior.

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+resource ('Open a URL and read it') and immediately scopes it against the sibling pipeline ('use instead of navigate + get_markdown'). An agent can tell exactly what this does and why it exists alongside navigate/get_markdown.

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 names the alternative it replaces (navigate + get_markdown) and gives conditional usage for query ('returns only the matching snippets … instead of the whole page') and with_refs. It stops short of stating when NOT to use it (e.g., when you only need find_in_page on an already-loaded page, or when snapshot is the right 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds only that the reload applies to the current page, without explaining side effects such as form resubmission or loss of unsaved state, permission needs, or whether cache is bypassed.

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 wasted words. It is appropriately sized for a no-parameter action tool.

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

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

Given the low complexity, zero parameters, existing output schema, and annotations covering the safety profile, the description is largely sufficient for correct invocation. It could be stronger by noting when to prefer reload over navigate or go_back, but it is not incomplete for the call itself.

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 schema is complete by definition and the baseline is 4. The description does not need to explain parameter semantics.

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: 'Reload the current page.' It is clear what the tool does, but it does not explicitly distinguish it from sibling navigation tools such as navigate, go_back, or read_url.

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, nor does it mention prerequisites or exclusions. The agent must infer its role 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?

Annotations already declare non-read-only, open-world and non-destructive, so safety is partly covered. The description adds genuinely new behavior: it blocks until a Done click, renders a banner, and requires a visible window. It omits what happens on timeout expiry, which is the one behavioral 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, front-loaded with the purpose, followed by the single critical prerequisite. 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?

An output schema exists and covers return values, and the blocking/banner behavior is explained. However, the timeout parameter's semantics are unexplained, which matters for an agent that must decide what value to pass and how to react if the human never clicks.

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

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

Schema description coverage is 0%, so the description must compensate for the two undocumented parameters. It says nothing about 'message' or 'timeout_s' (e.g. whether timeout aborts, errors, or continues), leaving the agent to guess from defaults alone.

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 ('Pause for a human') and names the exact scenarios (captcha, login, 2FA). This clearly separates it from automatic-wait siblings like wait_for and click, which cannot handle human interaction.

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?

Gives concrete triggering conditions (captcha, login, 2FA) and a hard prerequisite: configure(headless=False) must be set first. It does not name alternatives or exclusion cases, but the usage context is explicit.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutation and network profile is covered. The description adds that the operation 'restart[s]', which is meaningful behavioral context beyond the annotations. It does not say what the restart clears (page state, cookies, session) or whether the call waits for completion, which are the details an agent actually needs.

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 the action first and the prerequisite reference second. No filler and nothing redundant with the schema or annotations.

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?

An output schema exists, so return values need not be explained. However, for a zero-parameter operation that mutates the browser environment and restarts it, the description should at least hint at state loss or whether the restart is synchronous. Adequate but with a clear gap for a restart-class tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema shows. Baseline 4 applies; the description correctly doesn't waste space documenting non-existent arguments.

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: 'Switch to the next proxy in the configured list', with the scope (configured list) that distinguishes it from the `configure` sibling which defines the list. It doesn't explicitly differentiate from other environment-changing siblings like `new_identity` or `load_session`, so it falls just short of a 5.

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

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

The parenthetical 'see configure proxies=[...]' supplies a clear prerequisite: the proxy list must first be configured. Usage context is therefore clear, but there is no explicit guidance on when not to rotate (e.g., mid-navigation) or which sibling to prefer for other identity changes.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description discloses a key behavioral trait: 'Stops at the first failure,' which tells the agent about partial execution semantics. It also explains that then/then_chars appends the resulting page after the run, which is useful context on side effects. It doesn't state that successful earlier steps remain applied after a mid-run failure.

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?

Purpose is front-loaded in the first clause, followed by a compact step grammar with zero filler. The terse DSL notation is efficient but slightly cryptic on first read; still, every token carries 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?

An output schema exists, so return values needn't be described. Given the tool's complexity (arbitrary action batching), the description covers step grammar, target resolution, failure behavior, and the optional page-append option. What's missing is the shape of failure reporting and confirmation that prior steps persist after stopping.

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

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

With 0% schema description coverage, the description must carry the full burden, and it does: it enumerates every step action type with its fields (click/hover {target}, type {target,text,submit?}, fill {fields,submit?}, press, select, scroll, wait, goto, back), defines 'target' as a snapshot ref or selector, lists legal then values, and explains then_chars. The density is high but a few details (scroll amount units, wait ms semantics) are left implicit.

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+resource ('Run several page actions in one call') and immediately names the value proposition (saves round trips). This cleanly separates it from the many single-action siblings (click, hover, type_text, fill_form), so an agent can tell instantly that this is the batching entry point.

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

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

The parenthetical 'saves round trips' makes the intended context clear: use when you have multiple sequential page actions to perform rather than calling the single-action siblings repeatedly. It does not explicitly state when NOT to use it (e.g., when you need to inspect page state between steps), so it falls short of the explicit when/when-not/alternatives bar.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, and an output schema exists, so the safety profile and return shape are covered elsewhere. The description adds one useful behavioral fact (the entire page HTML, not a fragment / selector subset) but omits whether an existing file is overwritten, what the output dir actually resolves to, and whether the browser must be navigated to a page first. Note a mild tension: the tool persists a file to disk while annotations claim readOnlyHint=true — consistent with sibling export tools treating file emission as non-mutating, but worth flagging.

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

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

A single front-loaded sentence with zero filler and the destination stated up front. It is efficient rather than padded, though its brevity edges into under-specification rather than tightness.

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 structurally simple (one optional param, output schema present), so the description is nearly sufficient to call it. It still leaves gaps an agent must resolve elsewhere: what "output dir" means in this server's configuration, overwrite behavior, and how the saved file is reported back.

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 is one parameter (filename, defaulting to page.html) and schema description coverage is 0%, so the description is the only place semantics could be supplied — yet it never mentions the filename parameter or its default. An agent must open the schema to learn it can rename the artifact or that omitting the argument yields page.html.

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?

"Save the full page HTML to the output dir" names a specific verb (save) and resource (full page HTML) plus a destination, so the action is unambiguous. It does not, however, distinguish itself from the sibling get_html (which presumably returns markup inline) or save_pdf/screenshot_file, leaving the save-vs-retrieve distinction to the reader's inference from the name.

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

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

No when-to-use guidance, no prerequisites, and no named alternatives. The only implied usage cue is the phrase "to the output dir," which hints at persistence, but nothing tells an agent to prefer this over get_html when it just needs the markup in context.

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

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

The description usefully discloses that output is written to the output dir, but that write side effect is in direct tension with the readOnlyHint=true annotation. It also says nothing about whether existing files are overwritten or what the returned payload 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?

Two short sentences, zero waste, with the hard precondition (headless only) surfaced immediately alongside the core 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?

An output schema exists, so return values need not be explained. Still, for a file-producing tool the description omits overwrite behavior and filename/path handling, which is the main thing an agent must get right.

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 is one parameter with 0% schema description coverage; the description never mentions 'filename', its default 'page.pdf', or whether it accepts relative paths versus full paths. The 'output dir' phrase hints at path resolution but does not resolve it.

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 ('save') and resource ('the page as PDF') plus the output location, so an agent knows exactly what the tool produces. It does not name a sibling alternative (screenshot_file, save_html) for disambiguation, keeping it below 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?

'(headless mode only)' is a genuine precondition that narrows when the tool works, which is better than nothing. However, it gives no guidance on when to prefer this over save_html/screenshot_file, nor what to do in non-headless sessions.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true; the description adds context beyond that by warning that the resulting file contains credentials equivalent to being logged in and must be kept private, plus the non-profile browser behavior. It doesn't say where the file lands or how it is named/overwritten, but the security disclosure is the high-value part.

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, zero waste; the primary action comes first and the security caveat and sibling reference follow immediately. Nothing repeats the name or annotations.

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?

An output schema exists, so return values need not be described. The description covers purpose, the recovery path (load_session), the security implication, and the non-profile browser nuance — enough to call it correctly; only file location/naming specifics are absent.

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% for the single 'name' parameter. The phrase 'to a named file' hints that the parameter names the file, but it does not explain the default ('default'), file naming conventions, or overwrite behavior, so compensation for the coverage gap is only partial.

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?

Specific verb+resource: 'Save cookies and localStorage of the current browser to a named file'. It explicitly separates itself from sibling cookie tools (get_cookies/set_cookies) by describing a persisted session file, and even names the consuming tool, load_session.

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 — reuse a login later via load_session — and notes it works on a throwaway non-profile browser, which is exactly the situation where its sibling alternatives would not suffice. It stops short of stating exclusions or prerequisites (e.g., whether a page must be loaded first).

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?

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot express: default downscaling to 1024px, JPEG quality-55 encoding, and that annotate=True overlays snapshot refs (e12). It does not, however, say what is returned (an image payload vs a reference), whether output is inline or a URL, or how large captures behave — meaningful gaps for a tool whose whole output is a binary asset.

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?

Four sentences, front-loaded with the cost warning and the alternative routing before any parameter detail. No filler, and the parenthetical parameter notes are compact rather than repetitive.

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-only capture tool with no output schema and six undocumented parameters, the description covers the decision-relevant surface: why to use it, default sizing/encoding, and annotation. It falls short only on full_page semantics and on whether the result is inline image data or a file reference.

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

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

With 0% schema description coverage the description must carry all parameter meaning, and it documents four of six well: max_width (1024 default, 0 = full size), format ('png' for lossless), quality (1-100), and annotate (draws refs). selector is only implied by 'one element' and full_page is never mentioned, leaving two parameters to guesswork.

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 first sentence names the exact resource and scope: a screenshot of the page or a single element. It immediately distinguishes itself from extractive siblings (snapshot, get_markdown, find_in_page), so an agent knows this is the visual-capture tool and not the content-reading one.

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

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

It states an explicit cost-based selection rule — images are expensive, prefer snapshot/get_markdown/find_in_page, use this only when layout matters — naming three concrete alternatives and the condition that selects each. That is about as decisive as when-to-use guidance gets.

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 annotations declare readOnlyHint=true, meaning the tool should not modify its environment. The description says it 'saves the image into the output dir', which is a filesystem write. That directly conflicts with the read-only annotation, so the behavioral signal is misleading.

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 tool's purpose and key behavioral distinction. No filler, and the parenthetical format detail is useful.

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?

An output schema exists, so the return path need not be fully explained. But with 7 undocumented parameters, the description is not complete enough to guide correct invocation, especially for non-default options like selector, full_page, quality, and annotate.

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% across 7 parameters. The description adds meaning only for max_width and the format-follows-extension behavior; it leaves selector, full_page, quality, annotate, and filename unexplained.

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: it saves a screenshot image into the output dir and returns the path. It also clearly distinguishes this from the sibling screenshot tool by explaining that no image enters the context.

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 screenshot via 'Like screenshot but...' and gives the selecting condition: use this when you want no image in context and a file path returned. It does not spell out when-not cases, but the alternative is named.

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?

Annotations already declare destructiveHint=false and openWorldHint=true, lowering the bar. The description adds that an element can be brought into view via selector, but it does not explain why readOnlyHint is false for what looks like a view operation, nor whether the scroll is instant or smooth, whether it triggers lazy loading, or whether it waits for the viewport to settle.

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

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

A single front-loaded sentence with no filler; the primary mode (pixel scrolling by direction) precedes the element-into-view variant. Efficient, though the brevity is partly the source of the semantic gaps noted above.

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?

An output schema exists, so return values need not be described. But for a three-parameter tool with 0% schema coverage and no title, the description leaves the selector/direction interaction and the distinction from `scroll_to_load` unaddressed — enough to call it, not enough to call it 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 coverage is 0%, so the description must carry the parameters — and it partially does: 'by pixels' defines `amount` units, '(down|up|top|bottom)' supplies valid `direction` values the schema lacks as an enum, and 'scroll an element into view' explains `selector`. It never clarifies how `selector` interacts with `amount`/`direction` (are they ignored when a selector is given?) or that `amount` defaults to 800, so the compensation is incomplete.

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

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

The description names a specific verb (scroll) and resource (page/element) and enumerates the four directional modes, so the core action is unambiguous. It does not, however, distinguish itself from the sibling `scroll_to_load`, which an agent could easily confuse with this tool.

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

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

Usage is only implied by the directional vocabulary; there is no explicit statement of when to pick this over `scroll_to_load`, `find_in_page`, or `hover`-then-scroll workflows. No preconditions or exclusions are given.

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?

Annotations already declare openWorldHint=true, destructiveHint=false, and readOnlyHint=false. The description adds useful behavioral detail about repeatedly scrolling until page height stops growing, but it omits the max_scrolls cap and pause behavior, which materially affect how the loop actually runs.

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 the action and termination condition front-loaded. There is no redundant or wasted text.

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 and has an output schema plus annotations covering safety and openness. However, because the schema has no parameter descriptions, the description should explain pause_ms and max_scrolls and clarify whether the loop is capped before the page stops growing; it does not.

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 by explaining the two parameters. It does not mention pause_ms or max_scrolls at all, leaving their semantics entirely dependent on parameter names and defaults.

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, 'Scroll to the bottom repeatedly', plus the termination condition and the scenario ('infinite scroll'). It is clear enough to distinguish this from a simple one-off scroll, though it does not explicitly name the sibling tool.

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

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

The phrase '(infinite scroll)' implies the intended use case, but the description does not state when not to use it or explicitly compare it with alternatives such as scroll or wait_for. Usage is therefore implied rather than fully guided.

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 annotations already disclose that this is a mutating operation (readOnlyHint=false) but not destructive, with open-world behavior. The description adds that selection targets a <select> and can use either a value or visible label, but it does not explain edge cases such as invalid options, change-event triggering, or whether the selector must target a select element.

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 wasted words and no redundant restatement of the name or schema.

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

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

The output schema means return values need not be explained, and annotations cover safety characteristics. However, for a mutation tool with zero schema descriptions, the definition leaves selector semantics and important interaction behavior (such as whether change events fire or what happens on a missing option) unspecified.

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 carry parameter meaning. It usefully clarifies that 'value' can be either the underlying value or the visible label, but it leaves 'selector' unexplained beyond the common term, so compensation is only partial.

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: 'Select an option in a <select>'. It is clear what the tool does and distinguishes itself from generic sibling actions like click or type_text, though it does not explicitly call out those alternatives.

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

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

The phrase 'by value or visible label' implies how the tool is used, but there is no explicit guidance on when to prefer this over click, fill_form, or type_text, 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that: it does not say whether cookies are merged with or replace existing ones, what scope/session they attach to, or whether a navigation is required. The Playwright format note is parameter guidance, not behavioral disclosure.

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, with no filler. Nothing could be removed without losing the format hint.

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?

An output schema exists, so return values need no explanation, and the format hint covers the input. But for a state-mutating session tool with a nested-object parameter and no schema descriptions, the definition omits whether cookies merge or overwrite and what context they bind to, leaving a real gap for correct invocation.

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

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

Schema coverage is 0% and the schema only describes an array of untyped objects, so the description carries the full burden. It does this well by naming two accepted shapes (name/value/domain/path and name/value/url) and anchoring to the documented Playwright cookie format, though the trailing "..." leaves the remaining optional fields unspecified.

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+resource ("Add cookies"), which is unambiguous and easily distinguished from get_cookies/clear_cookies by name. It stops short of explicitly contrasting with those siblings, so it lands at clear-but-not-differentiating.

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 statement of when to use this versus get_cookies, clear_cookies, or load_session, and no prerequisites (e.g., must a tab be open, does it apply before navigate?). The usage is only inferable from the tool name and the format note.

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?

Annotations already establish read-only and non-destructive behavior, and the description adds important traits: refs remain stable while the page is loaded, iframe refs are encoded as f2e5, diff behavior changes depending on mode, and truncated output is signaled. This is rich behavioral context beyond the structured annotations.

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 dense but front-loaded: purpose and ref format come first, followed by scope, diff semantics, and cutoff advice. It is appropriately sized for a three-parameter tool, though the sentence structure is somewhat run-on.

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 existing output schema and annotations, the description supplies the remaining operational context an agent needs: how refs work, what scope does, how diff modes behave, and what to do when results are truncated. Nothing essential for correct invocation appears missing.

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

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

Schema description coverage is 0%, so the description must carry parameter semantics, and it does: scope='#css' limits results, diff=None/True/False are each defined in terms of change-only vs full output, and max_items is tied to cutoff handling. All three parameters are meaningfully explained.

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

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

The description clearly states a specific verb and resource: listing clickable/typeable elements as ref-tagged labels. It also explains the ref format and iframe ref notation, making the tool's purpose concrete, though it does not explicitly differentiate this listing tool from siblings such as get_text or extract_links.

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