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

No annotations are provided, so the description carries the full burden and does so well: it discloses domain-scoping behavior, the deferred visibility of the cookie until the next request, and the replace-existing-name semantics. These are behaviors an agent could not infer otherwise.

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?

Nine short clauses that each add distinct operational information, front-loaded with the core action and followed by prerequisites and post-conditions. No redundant restatement of the tool 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?

For an 8-parameter mutation tool with no annotations and no output schema, the description covers the essential behavioral context: prerequisite navigation, deferred cookie visibility, refresh requirement, and replacement semantics. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so all 8 parameters are fully documented in the schema with examples (e.g., '.example.com' for domain, Unix timestamp for expiry). The description elaborates on the domain/current-page constraint but adds no per-parameter syntax beyond what the schema already provides. Baseline 3 is correct.

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 ('Set a cookie in the browser') with concrete examples of intent (session, feature-flag, skip login). Clearly distinguishes from the sibling get_cookies and delete_cookie mutators.

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

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

Provides explicit when-to-use examples and a critical prerequisite ('navigate to a page on that domain first'). Also states the post-condition action ('refresh or navigate afterwards') so the agent knows what to do next.

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

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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses the blocking behavior (other page actions fail until handled), that accept/dismiss are irreversible ('this cannot be undone'), that every action returns the dialog's text, and the send_text→accept sequencing. This is exactly the behavioral 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?

A single dense paragraph that is front-loaded with the purpose before moving to per-action semantics, failure mode, and the sibling distinction. Every sentence carries distinct information 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?

Although there is no output schema, the description explicitly states that every action returns the dialog's text, and with no annotations the blocking/irreversibility semantics are fully covered. Nothing an agent needs in order to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by mapping each enum value to an outcome (accept=OK, dismiss=Cancel) and adding the sequencing constraint that send_text types into a prompt() 'before you accept it'. Marginal but real added value over the already-complete schema.

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

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

States a specific verb (Handle) and a precisely scoped resource (native browser dialog opened by alert(), confirm(), or prompt()), and explicitly distinguishes it from custom in-page modals, which it routes to the click sibling. An agent can identify this tool and its boundary versus siblings without opening any 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?

Gives explicit when-to-use (a native dialog is open, which blocks other page actions), when-not (custom in-page modals are not native dialogs — use click on their buttons), and a failure condition ('Fails if no dialog is open'). Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the implicit wait for element existence, the edge-case rule that a missing attribute equals an empty string, and the failure semantics (tool error showing expected vs actual). Remaining gaps are minor, such as interaction with timeoutMs beyond the schema default.

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 dense sentences, front-loaded with the core assertion behavior, followed by edge-case and failure semantics. No filler or redundancy.

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

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

With no output schema, the description usefully explains the success/failure outcome (tool error with expected vs actual) and the wait/missing-attribute behavior, which is enough to invoke it correctly. It could say slightly more about how the wait interacts with timeoutMs, but nothing critical is missing.

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

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

Schema description coverage is 100%, so every parameter (mode, name, expected, selector, timeoutMs) is already documented in the schema. The description restates the mode semantics and examples but adds no syntax or format detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

States a specific verb (check/assert) applied to a specific resource (an element's attribute or property) with concrete examples ('a button is disabled', an input's value). It is clearly distinguishable from siblings like get_attribute (reads a value) and assert_text/assert_visible (different assertions).

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 'Test step:' prefix and the enumeration of comparison modes give clear context for when this assertion tool applies, and the examples make the use case concrete. However, it never names alternatives or exclusions (e.g. use get_attribute to read rather than assert, or assert_visible for visibility), leaving that routing to inference.

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

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

With no annotations the description carries the full burden and does so well: it discloses the visibility wait, the single-check behavior (no retry on text change), the pass payload (actual text), and the failure mode (tool error with expected vs actual). This is rich behavioral context beyond anything in the schema.

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

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

Four sentences, front-loaded with the core action, and each sentence adds distinct value (semantics, wait behavior, result contract, alternative). 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 nested-selector assertion tool with no output schema and no annotations, the definition covers the pass/fail contract, timing behavior, and sibling routing. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so the schema already documents all five parameters including mode enum, trim default, and timeout. The description restates the mode options but adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('check that an element's visible text equals, contains, or matches a regex') and immediately differentiates itself from the sibling get_text. An agent can identify the tool's role 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?

Frames the tool as an acceptance check and names the alternative explicitly ('Use get_text to just read text without a pass/fail'), giving a clear when-to-use and when-not condition. The single-check semantics ('does not wait for the text to change') further disambiguate it from wait_for_element.

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

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

With no annotations present, the description carries the behavioral burden and does so well: it states the pass condition ('passes as soon as it is displayed') and the failure mode ('fails as a tool error if it is missing or stays hidden'). It does not say whether the page/browser state is preserved on failure or whether the error message identifies the selector, leaving a small gap for a mutation-adjacent, blocking assertion tool.

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

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

Three sentences, zero filler, front-loaded with the purpose, then the pass/fail semantics, then the sibling comparison. 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?

No output schema exists, but the description communicates the return-by-exception semantics directly, and the rich input schema covers parameters. What is missing is failure-side context (does the browser stay open, is a screenshot available after the tool error), which matters for an assertion tool inside a test flow.

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

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

Schema description coverage is 100%, so the schema already documents the selector shape, locator strategies and timeoutMs bounds/default. The description adds only that the timeout governs 'becomes visible' timing, which is a minor enrichment over the schema's own text. Baseline 3 applies when the schema does the heavy lifting.

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+condition: check that an element becomes visible within timeoutMs. It names concrete examples (success banner, cart badge) and explicitly distinguishes itself from the sibling wait_for_element and from the pass/fail assertion family (assert_text, assert_attribute).

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?

Frames the tool as a 'test step' and explicitly contrasts it with 'wait_for_element with visible: true, but phrased as a pass/fail assertion', which tells the agent when to pick this over the wait tool. It stops short of spelling out the inverse condition (use wait_for_element when you don't want the run to fail), so selection guidance is clear but not exhaustive.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the 10-step cap, the default fail-fast semantics, that stopOnError can be flipped to collect all errors, and the result shape ('lists every executed step with its details or error'). It also flags a real constraint the schema cannot express — selectors only, no capture_page refs. It stops short of saying what happens to browser state after a mid-batch failure or whether a session must already exist.

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

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

Three sentences, front-loaded with the capability and its limits before moving to usage and failure behavior. Every sentence carries distinct information — actions supported, when to prefer it, and what happens on failure — with no filler or repetition of the tool name.

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

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

For a complex orchestration tool with zero annotation coverage and no output schema, the definition covers the essentials: step cap, allowed actions, failure semantics, and result contents. The remaining gaps are the unstated preconditions (an active browser session) and the side effects left behind by a partially executed batch, which matter for a mutation-heavy 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it states the accepted action vocabulary, that step fields mirror the standalone tools, and — critically — that capture_page references are not valid selectors here, a restriction absent from the JSON Schema. The 1-10 bounds and stopOnError default are restated rather than added, which keeps this from a 5.

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

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

The description opens with a specific verb and scope ('Run up to 10 steps in one call') and enumerates exactly which actions are batched (navigate, wait_for_element, wait_for_page, click, type, select_option, execute_script). By tying each action back to 'the same fields as the standalone tool', it cleanly distinguishes batch_execute from the ~38 single-step siblings like click, type, and select_option.

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 positive context — 'known linear flows such as a login or form fill, to save round trips' — which implicitly rules out flows that need branching or intermediate inspection. However, it never explicitly states when NOT to batch (e.g. when a later step depends on reading an earlier step's result, use the standalone tools), so the exclusion is left to inference.

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

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

With no annotations, the description carries the full burden and it delivers the single most critical behavioral trait: refs are scoped to this snapshot and go stale after navigation or major page changes. It doesn't cover permissions, rate limits, or result-shape details like whether truncation occurs when maxElements is hit, so it falls 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?

Densely front-loaded: what is captured, the ref convention, how to consume refs, the staleness caveat, and the routing away from screenshot/get_page_source. Every sentence carries actionable information 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?

For a no-output-schema tool the description does explain the returned artifacts (stable refs and reusable selectors) plus the invalidation rule, which is enough for correct invocation. Minor gap: no note on truncation behavior on large pages or what happens if a page has no interactive elements.

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 only one parameter (maxElements) and the schema already documents it fully at 100% coverage, including default 200 and the 10-500 range with tuning guidance. The description adds nothing about it, which is acceptable given the schema does the work—baseline 3.

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 (snapshot) and resource (the page's visible interactive elements and headings), then enumerates exactly what is captured (links, buttons, inputs, selects, textareas, ARIA roles, h1-h4) and what is produced (e1, e2 refs plus selectors). It also differentiates itself from siblings like take_screenshot and get_page_source.

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 tells the agent to pass a ref to click, type, get_text, select_option, interact, or scroll instead of guessing selectors, mandates re-capturing after navigation or major page changes, and names screenshots/get_page_source as inferior alternatives for understanding page content.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses that the element is scrolled into view, that it waits for visibility and enablement, and that failure returns the reason. It does not describe what a successful click returns, which is a minor remaining 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?

Three sentences, each front-loaded with actionable information: primary behavior first, then alternative routing, then failure mode. No filler or redundancy.

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

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

Given no output schema and full input-schema coverage, the description covers the essential behavioral contract: waiting, scrolling, targeting, and failure reporting. It would be fully complete if it briefly stated the success return or side-effect expectation, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so all three parameters already have detailed schema-level documentation (including ref staleness after navigation). The description adds only high-level targeting context and does not meaningfully extend parameter semantics beyond the schema.

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

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

States a specific action (click an element), the waiting behavior (visible and enabled), and the two targeting mechanisms (selector or ref). It also names sibling tools (retry_click, interact) for adjacent use cases, so an agent can distinguish it without opening other schemas.

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 says when to use this tool versus alternatives: use retry_click for intermittent failures from overlays/animations/re-rendering, and use interact for double-click, right-click, or hover. It also names the fallback behavior on timeout, giving complete 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?

With no annotations provided, the description carries the full disclosure burden and does so well: it flags the operation as irreversible ('cannot be undone'), names concrete side effects (logging the user out, resetting consent banners and preferences), and explains the deferred timing of the effect with a required follow-up action.

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

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

Three tight sentences ordered by importance: what it does, what gets destroyed, then how to make the change take effect. No padding, and the destructive warning is front-loaded.

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

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

For a one-parameter destructive tool with no annotations and no output schema, everything an agent needs is present: the effect, its irreversibility, the collateral consequences, and the post-call action required to observe the result.

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

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

Schema description coverage is 100% and the single parameter's description already documents the omit-to-delete-all semantics, so the schema does the heavy lifting. The description restates the omitted-name behavior but adds no new syntax or format detail beyond 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 and resource (delete_cookie) and immediately distinguishes two modes: one cookie by name, or all cookies for the current page when name is omitted. This clearly separates it from siblings like add_cookie and get_cookies without needing to name them.

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

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

Gives clear operational context: omit the name to clear everything, and refresh (history) or navigate afterwards because the page only notices on its next request. It does not explicitly name or exclude alternatives like get_cookies or add_cookie, so it stops short of full when/when-not routing.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses synchronous execution, that arguments are positional, that the script 'runs with the page's privileges and can change the page' (mutation risk), and the real-event caveat. It stops short of error behavior, sandboxing/isolation, or what happens on exceptions.

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, front-loaded with the core action and return contract, then usage, then the safety/alternative caveat. No filler and no repetition of sibling concerns.

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?

No output schema exists, so the description must explain return values — it does ('return its result', plain JSON values via the schema). For an arbitrary-code-execution tool with zero annotations, it covers scope, mutation risk, and alternatives well, though error/failure semantics remain unstated.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reiterates the positional-argument convention and the return-statement requirement, which the schema already documents; it adds emphasis but little new syntax or format detail.

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

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

States a precise verb+resource ('Run synchronous JavaScript in the current page and return its result') and immediately pins down the contract with '(use a return statement)'. It is unmistakably distinct from siblings like get_text or get_attribute, since it is the only arbitrary-code escape hatch.

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 positive selection criteria ('reading several values in one call, or page state no other tool exposes (localStorage, computed styles, element counts)') and an explicit exclusion with a named alternative ('for user actions such as clicking and typing, prefer click and type so real events fire'). Both when-to-use and when-not-to-use are covered.

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

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

With no annotations, the description carries the full burden and does disclose two non-obvious behaviors: it blocks until the element exists, and it reports existence state plus displayed/enabled flags. It does not say what happens when the element never appears (error type, mention of timeoutMs as the bound), which is the one meaningful gap for a waiting lookup.

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

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

Three sentences, all load-bearing: what it returns first, then when to use it, then the two sibling alternatives. No restatement of the name or filler.

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

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

No output schema exists, so the description usefully enumerates the returned fields, which is the right compensation. For a selector-based lookup with a fully documented schema, the only unstated item is failure behavior on timeout, a minor completeness 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 100% and both parameters (nested selector with by/value, timeoutMs) are fully documented in the schema itself. The description only implicitly touches timeoutMs via 'waits for it to exist' and adds no locator-strategy guidance beyond what the schema already gives.

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 ('look up one element') plus the exact return fields (tag, visible text, displayed/enabled), which no sibling provides. It also names the two siblings an agent might confuse it with, so the tool is distinguishable without opening any 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?

Gives explicit use cases ('confirm a selector matches the intended element, or inspect an element before acting') and explicit alternatives with the condition that selects them: capture_page when no selector is known, wait_for_element when only waiting is needed. Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does disclose the key non-obvious trait: the switch is stateful and persists until changed or a new page load. That is exactly the kind of side effect an agent must know. It does not cover failure behavior (e.g., frame not found, timeout handling beyond the schema's timeoutMs) or return values, so it falls short of full transparency.

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 purpose and impact on other tools, then the action semantics, then the lifetime rule. No filler; every sentence contributes actionable 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 stateful 5-parameter tool with a nested selector object, no annotations, and no output schema, the description covers purpose, per-action semantics, and the state lifetime plus how to revert. It omits error/timeout behavior and any indication of what a successful call returns, which keeps it just short of fully complete.

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

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

Schema description coverage is 100%, and the schema already documents action, index, nameOrId, selector, and timeoutMs with the precedence rules ('used when no selector is given'). The description restates the action meanings and the selector/index/nameOrId alternatives but adds no format, precedence, or fallback detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb+resource ('Move into or out of an iframe') and immediately scopes it against siblings by noting elements inside a frame cannot be found by other tools until you switch in. An agent can distinguish this from window, click, or find_element without opening any 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?

Gives an explicit trigger (elements inside embedded widgets, rich-text editors, payment fields are invisible to other tools) and a clear cleanup rule ('switch back with default when you are done inside the frame'). Each action value is defined inline, so the when-to-use and how-to-exit guidance is complete.

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

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

With no annotations, the description carries the full burden and does well: it discloses the existence-wait (independent of visibility), the null return when unset, and the property-beats-attribute precedence rule. It does not mention default/hard timeout behavior or failure modes when the element never appears, which the schema only partially covers.

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 dense sentences, front-loaded with the core action and examples, then the wait/return semantics, then the sibling routing. Every clause 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?

No output schema exists, so the description must explain returns, and it does ('the value, or null if it is not set'), alongside wait semantics and alternatives. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond it by explaining the live-property-wins rule ('value' gives the text currently in an input), which clarifies how the 'name' parameter resolves at runtime.

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 ('Read') and resource ('attribute or property of an element') and illustrates with concrete cases (value, href, disabled, checked, aria-expanded). It also explicitly names the sibling it is not (get_text) 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?

Gives explicit alternatives with selection conditions: get_text for visible text, assert_attribute for value assertions as a test step. It also states the wait/visibility precondition ('Waits for the element to exist (it does not need to be visible)'), leaving nothing to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses that read includes httpOnly cookies invisible to page JavaScript, and enumerates the returned fields (name, value, domain, path, expiry, flags). Read-only nature is implied but the safety profile is not explicitly declared.

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 tightly packed sentences, front-loaded with the operation and scope, then capability disclosure, then use cases. No filler; 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?

For a single-parameter read tool with no output schema, it covers scope, return values, and motivation adequately. Only the explicit read-only/safety signal is left to inference, which is minor given the 'read' framing.

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

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

Schema description coverage is 100%, so the schema already documents the sole 'name' parameter including the omit-to-read-all behavior and an example. The description restates this dual mode, adding little beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb (read) and resource (cookies) with clear scope ('the current page') and dual mode ('all of them, or one by name'). It is immediately distinguishable from siblings add_cookie and delete_cookie.

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 use cases ('check that a login created a session cookie, or to copy one into another session with add_cookie') and routes to the add_cookie alternative. Stops short of stating when-not to use it, but the context is clear.

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

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

No annotations are provided, so the description carries the behavior burden. It tells the agent the return includes query string and fragment, which is meaningful. However it does not state whether this is a synchronous read, whether it reflects the active frame vs top-level document, or what happens when no page is loaded — gaps for a zero-arg read tool with no 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?

Two sentences, front-loaded with the return definition followed immediately by the usage/alternative. No filler words, every clause earns its place.

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

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

For a zero-param read tool with no output schema, the description covers the return shape (URL plus query string and fragment) and the primary use case. It stops short of covering mode of operation (sync/async, frame scope, no-page behavior), which would be needed for a perfect score given the absence of annotations and output schema.

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

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

Zero parameters, so the baseline is 4. The description appropriately focuses on behavior rather than params; the 'current tab' scope is implicit context that helps interpret the call in a multi-tab session, but no param compensation is required.

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

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

States a specific verb ('Return') and resource ('the URL of the current tab'), and specifies the scope ('including any query string and fragment'). It is clearly distinguishable from its sibling get_title and from navigate/wait_for_page without opening any 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?

Explicitly names the use case ('confirm where a click or redirect landed') and names the alternative for the adjacent need ('to wait until the URL changes, use wait_for_page'). Both when-to-use and which-alternative are provided.

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

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

No annotations exist, so the description carries the full burden, and it does well: it discloses that the result is the live DOM, that output is truncated at maxLength, the return shape (HTML, full length, truncated flag), and that the payload is 'large and noisy'. It does not quantify expected payload size or performance cost, which keeps it just under the top mark.

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, front-loaded with what is returned before the caveats and alternatives. Every clause earns its place: none is redundant with the schema or with a sibling-name-only listing.

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 output schema and no annotations, the description still tells the agent what comes back (HTML, full length, truncation flag) and how to route away when that is not what is wanted. Nothing needed to invoke this single-optional-parameter tool correctly is missing.

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

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

Schema coverage is 100% and the maxLength description already gives range and default, so the schema does the heavy lifting. The description's 'cut off at maxLength characters' adds the truncation consequence but no format or syntax detail beyond the schema, making 3 the correct baseline.

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 ('Return the page's current HTML'), and immediately qualifies it as the live DOM including script mutations, which is exactly the distinction an agent needs. It names the sibling alternatives (capture_page, get_text, get_attribute) so the tool is separable without opening any 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?

Explicit routing: 'to find elements to act on, prefer capture_page; to read specific text or values, use get_text or get_attribute,' plus a positive case for raw markup (meta tags, hidden fields, inline data). Both when-to-use and when-to-prefer-alternatives are covered.

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

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

With no annotations, the description carries the behavioral burden and does so well for a read tool: it discloses that it waits for the element to become visible before returning, that it excludes hidden text, and that output is trimmed by default. It does not mention the timeout ceiling or pagination-style edge cases (e.g. what happens if the element never becomes visible), which the schema's timeoutMs only partially covers.

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 front-loaded sentences with zero waste: purpose, then visible-text qualifier, then targeting and sibling routing. Every clause earns its place and the most important constraint (visible, not hidden/value) comes first.

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?

No output schema exists, and the description compensates by stating that it returns the element's text, trimmed by default. Combined with the visibility-wait behavior, cursor-targeting guidance, and sibling routing, an agent has everything needed 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 description coverage is 100%, so all four parameters are already fully documented in the schema. The description reinforces ref-vs-selector targeting and the trimmed-by-default behavior but adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a precise verb+resource ('Read the visible text of an element') and immediately scopes it with the key qualifier 'what a user sees, not hidden text or an input's value.' It explicitly contrasts itself with get_attribute and assert_text, so an agent can distinguish it from siblings without opening any 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?

It names both alternatives and the exact condition that selects each: get_attribute for input values or attributes, assert_text for pass/fail text assertions. It also tells the agent how to target the element (selector or a ref from capture_page), leaving nothing to inference.

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

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

No annotations are provided, but this is a zero-parameter read-only getter, so the behavioral burden is inherently light. The description discloses what the value represents (the browser-tab title), which is the main behavioral fact an agent needs; it says nothing about failure modes when no page is open, keeping it just 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, and the return semantics are front-loaded before the alternative-tool hint. Every clause 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 no output schema, the description must convey the return value, and it does ('the current page's title / text shown in the browser tab'). It does not cover edge cases such as a title-less or not-yet-loaded page, so it is complete for normal use but not exhaustive.

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 per the rubric the baseline is 4. There is nothing for the description to clarify, and it correctly omits any parameter discussion rather than inventing one.

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 ('Return the current page's title') and immediately disambiguates it from page content and URLs by clarifying it is 'the text shown in the browser tab'. This lets an agent distinguish it from siblings like get_text and get_current_url without inspecting any 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?

It gives a concrete use case ('confirm which page is open') and explicitly names the alternative for the adjacent task: 'to wait until the title changes, use wait_for_page with titleContains.' That is a clear when-to-use plus a named sibling with the selecting condition, which is the strongest form of 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?

No annotations, so description carries full burden. It discloses that it 'Waits for the page to load', returns the new URL and title, warns about stale element refs requiring recapture, and notes that refresh can reset unsaved form input. These are important behavioral details that go beyond what the schema provides.

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

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

Three sentences, each front-loaded with essential information: first sentence lists actions with analogies, second gives alternate tool, third warns about side effects. No wasted words.

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

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

Given no output schema and no annotations, the description is nearly complete: it covers actions, return values (new URL and title), side effects (stale refs, form reset), and alternative tool. It could mention that it only works within the current tab's history or any limitations on forward navigation, but it's largely sufficient.

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

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

Schema coverage is 100% and the enum values are fully described in the schema. The description lists the same three actions, adding no new syntax or format details, so baseline would be 3. However, it provides contextual analogies ('like the Back button') that may slightly aid understanding, warranting a 4 given the schema already does the heavy lifting.

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 specific actions (back, forward, refresh) with analogies to browser buttons, making the purpose immediately clear. It doesn't differentiate itself from all siblings like get_current_url in the description, but the action enumeration and reference to navigate provide 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?

Explicitly states when to use this tool (back/forward/refresh navigation) and provides an alternative ('To open a specific URL, use navigate instead'). This covers the main routing decision, though it doesn't mention other siblings like get_current_url or press_key alternatives.

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

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

With no annotations, the description carries the behavioral burden and does useful work: it discloses per-action readiness semantics (waits for visible on hover, visible-and-enabled on clicks) and the side effect that right_click opens a context menu. It does not cover failure behavior (what happens on timeout), whether the page can navigate as a result of a click, or what is returned, which are the remaining gaps for a state-mutating interaction tool.

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

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

Three sentences, front-loaded with the action list, followed by readiness semantics and then the sibling routing rule. No filler, and the most decision-relevant information (what actions exist and which tool to use instead) comes first.

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 interaction tool with no annotations and no output schema, the description covers actions, targeting, and readiness adequately. It omits the post-action contract (return value, whether navigation may occur) and timeout behavior, which an agent would benefit from knowing before triggering a mutation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema by tying readiness/waiting behavior to the action value (hover vs clicks) and restating the selector-or-ref targeting choice. It stops short of adding timeout or locator-strategy nuance, so it is an incremental rather than a transformative gain.

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 resource (mouse actions on an element) and enumerates the exact operations: double_click, right_click, hover, and click-as-real-mouse-move. It explicitly separates itself from the sibling 'click' tool with 'For an ordinary click, prefer click,' so an agent can disambiguate 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?

It gives an explicit routing rule to the alternative tool ('For an ordinary click, prefer click') and describes the conditions that select each action (right_click opens a context menu, hover reveals menus/tooltips, click helps elements that react to real pointer movement). This is as close to when/when-not guidance as a multi-action tool can get.

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

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

No annotations, so the description carries the burden, and it does disclose blocking wait semantics bounded by pageLoadTimeoutMs set in start_browser, plus return contents (final URL after redirects and page title). It stops short of stating timeout/error behavior or whether the wait is skippable, so it is strong but not exhaustive.

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

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

Two sentences, front-loaded with the core action and wait behavior, followed by a compact routing clause. 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?

With no output schema, the description still tells the agent what comes back (final URL after redirects, page title) and how long it blocks, which is everything needed 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 100% and the single parameter is fully documented with type, format, and an example. The description adds the routing context (current tab) but no new syntax or constraints for `url`, so baseline 3 is appropriate.

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

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

Specific verb (Open) plus resource (a URL) and scope (in the current tab), followed by what it returns. It also names the sibling tools it is not (history, wait_for_page), so an agent can distinguish it without opening other schemas.

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 routes the agent: use history to go back/forward/refresh, and use wait_for_page when a later redirect or client-side route change still has to happen. This is exactly the when-vs-alternative guidance requested.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the key is delivered to the focused element rather than a addressed target, enumerates the recognized named keys, and reveals the important fallback that any other value is typed as literal text. It does not state what happens when nothing is focused or how failures surface, which is the remaining 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?

Three sentences, all earning their place, with the core behavior front-loaded and the sibling routing placed last where it aids selection. No filler or restatement of the title.

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?

No output schema exists and none is implied for a keystroke action, so return-value explanation is unnecessary. The accepted key vocabulary and literal-text fallback are covered; only edge behavior (no focused element, unsupported keys, focus loss) is left unstated.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: it enumerates the accepted named-key set and, crucially, defines the behavior of values outside that set (typed as literal text). That is semantics the schema's single 'key' string field does not convey.

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 (press) and resource (one key) plus the crucial scope restriction: it acts on whatever currently has focus, not a selector-addressed target. This cleanly distinguishes it from the sibling 'type', which focuses a field first.

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 usage scenarios (Enter to submit, Tab to move focus, Escape to close a dialog, arrows in a list) and explicitly names the alternative tool plus the condition selecting it: 'To type into a specific field, use type, which focuses the field first.' No inference 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?

With no annotations, the description carries the full burden and does well: it discloses the retry loop, that each attempt waits for the element to be visible and enabled, the inter-attempt pause, and the return behavior on success vs. total failure. It omits any note on side effects of the click itself or whether the retry re-resolves the selector, but the core dynamics are covered.

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

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

Front-loaded with purpose and failure modes, then mechanism, then return values. Dense and mostly waste-free; the middle clause enumerating failure modes is slightly verbose but earns its place by clarifying when to choose this 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?

No output schema exists, yet the description covers the return contract ("the attempt that succeeded, or every attempt's error"), which is what an agent needs. Combined with fully-covered parameters and explicit usage routing, it is essentially complete for a retry-click 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 coverage is 100%, so all four parameters are already documented, including delayMs and attempts. The description only loosely echoes these ("failed attempts pause delayMs"), adding little beyond what the schema states, so the baseline 3 is appropriate.

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

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

Opens with a specific verb+resource ("Click with retries") and immediately scopes it to "clicks that fail intermittently," naming the concrete failure modes (loading overlay, animation, stale re-render). This distinguishes it cleanly from the sibling `click` 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?

Explicitly routes the agent: "Try click first; use this when click failed because of timing." This states both the preferred alternative and the exact condition that selects this tool, leaving nothing to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return value (scroll position with atTop/atBottom flags), the container-vs-element distinction, and the lazy-loading repetition pattern. It is thin on failure/timeout behavior beyond what the timeoutMs schema already states, keeping it just under 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?

A single dense paragraph with the core verb front-loaded and no filler sentences; each clause adds information. It is on the long side and could be broken into a mode list, but 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?

For a 6-parameter tool with no output schema and no annotations, the description fills the critical gaps by stating the return shape and the lazy-load workflow. It is complete enough to invoke correctly, with only minor omissions around error handling.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the dual role of selector/ref and the deltaY example. The description largely restates this, adding only the 'middle of the screen' target nuance and the container semantics already present in the schema. Baseline 3 is correct.

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?

Opens with a specific verb+resource ('Scroll the page') and enumerates the distinct scroll modes: pixel delta, top/bottom jump, element-into-view, and inside a scrollable container. It further distinguishes itself from sibling tools by noting that click and type already scroll their targets into view.

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 when-to-use ('reveal content or trigger lazy loading') and when-not-to-use ('click and type already scroll their target into view'). It also prescribes a concrete alternative workflow for infinite scroll, naming the sibling tool wait_for_element and the repeat-until-atBottom condition.

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

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

With no annotations, the description carries the full burden and does well: it discloses the wait-for-visible behavior, that it clicks like a user so change events fire, that multi-select adds to the existing selection, that mismatches error out with the available option list, and that it returns the resulting selection. It does not discuss timeout expiry behavior or read-only vs mutating implications in any depth, which is the only remaining 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?

Front-loaded with the core purpose, then behavior (wait, click semantics, multi-select, errors), then the exclusion. Four clauses, each carrying distinct information with no repetition or filler.

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

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

No output schema and no annotations, so the description must cover behavior and returns — it states the return value (resulting selection) and the error format. Combined with a fully documented 6-parameter schema, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so every parameter (ref, text, value, index, selector, timeoutMs) is already fully documented including the exactly-one-of constraint and zero-based indexing. The description echoes the three selection modes ('visible text, value, or zero-based index') but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (select) and resource (option in a native <select> dropdown) with a precise scope, and explicitly carves itself apart from the sibling 'click' path for custom dropdowns. An agent can distinguish it from click/interact 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?

Gives an explicit exclusion and the alternative: 'Only for real <select> elements; for custom dropdowns built from other elements, click the trigger and then the option.' It also states the pre-condition (waits for the dropdown to be visible) and the failure/retry path (error lists available options).

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

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

With no annotations, the description carries the full burden and does so well: it discloses irreversibility ('This cannot be undone'), the failure mode (key/domain mismatch), and the preferred follow-up path. It stops short of describing any file-location or permission prerequisites, so it is strong but not exhaustive.

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

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

Three short sentences, each earning its place: action, reason/irreversibility, alternative, and error condition. The destructive nature is front-loaded in the first word.

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

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

For a two-parameter destructive tool with no annotations and no output schema, the description covers the essentials an agent needs: irreversibility, the failure precondition, and the replacement workflow. It omits only secondary details such as where the hints file lives or what auth is required.

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

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

Schema description coverage is 100%, so both 'key' and 'domain' are already documented in the schema. The description only implies the domain-key pairing through the failure condition and adds no format or default details beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb ('Permanently remove') and resource ('a saved selector hint from the hints file'), and its scope is immediately distinguishable from the sibling selector_hint_save/get/list operations without opening any 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?

Gives an explicit trigger scenario ('when the site changed and the selector no longer works') and routes the agent to the correct alternative ('save a corrected hint with selector_hint_save'). It also documents the when-not condition ('Fails if no hint with that key exists for the domain').

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

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

No annotations are provided, so the description carries the burden. It discloses the missing-key failure mode and that the returned value is directly consumable by click/type/get_text, but says nothing about persistence scope, session coupling, or whether the hint can be stale.

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

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

Two tight sentences: the lookup semantics and downstream use come first, then the failure/alternative guidance. No filler or repetition of structured data.

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 output schema, the description compensates by stating what is returned (a selector ready for other tools) and what happens on miss. An agent has everything needed 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 description coverage is 100%, covering both 'key' and 'domain'. The description only restates that the lookup is per-site/domain; it adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb+resource (look up a saved selector by key for a site) and states the output's purpose: it is ready to pass as the selector of click, type, get_text. This distinguishes it from selector_hint_list and the hint-mutation siblings without opening any 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?

It gives the failure condition ('fails if no hint with that key exists for the domain') and an explicit alternative ('use selector_hint_list to see what is saved'), which is exactly the when-to-use/alternate-route guidance an agent needs.

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

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

With no annotations, the description carries the full burden, and it does disclose a meaningful operative fact: 'Does not need a browser to be running.' This is valuable given nearly every sibling tool requires an active browser session. It doesn't mention pagination or result-size behavior, but for a trivial read that gap is minor.

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 core action and what is returned; the operational caveat is correctly placed last. No filler.

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

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

There is no output schema, but the description compensates by naming the returned fields (key, domain, selector). Combined with the browser-not-required note, an agent has what it needs to call and interpret this tool; only exhaustiveness/pagination details 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 coverage is 100% and the parameter's own description already defines the domain filter and the omit-to-list-all behavior. 'For every site, or only for one domain' restates the schema rather than adding new meaning, so baseline 3 applies.

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

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

The description gives a precise verb+resource ('List saved selector hints') and enumerates the returned fields (key, domain, selector), plus the scope options (every site or one domain). This clearly separates it from the sibling selector_hint_get (single key), selector_hint_save, and selector_hint_delete.

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

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

It states a concrete trigger: 'Check this at the start of a run on a familiar site to reuse known selectors.' That is clear when-to-use guidance, but it never names the alternative (selector_hint_get for a known key) or any 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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses persistence location (.selenium-mcp/selector-hints.json or SELENIUM_MCP_SELECTOR_HINTS_PATH), durability across restarts, and the return value. These are non-obvious side effects 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 what the tool does, then storage location, then the usage trigger, then return value. Slightly dense but every sentence adds information; 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?

Covers purpose, persistence, keying, and return value for a 3-param nested-object tool with rich schema. No output schema exists, so explaining the return briefly is appropriate. Missing only explicit sibling/alternative routing, which is minor.

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

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

Schema coverage is 100%, so the schema fully documents key, domain, and selector (including enum strategies and the default-to-current-hostname behavior). The description adds no parameter-level detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb (save/remember) and resource (selector hint keyed by site), and distinguishes itself from the sibling read tool selector_hint_get by clarifying the write direction. The keying and domain scoping is explicit.

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

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

Gives a concrete when-to-use trigger ('Save a hint after a selector has worked, e.g. after a successful click'). Does not explicitly name selector_hint_get as the read counterpart or state when not to save, but the usage context is clear.

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

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

With no annotations, the description carries the burden and discloses the critical side effect: the new session becomes active and 'all other tools act on the active session'. It also states the return shape. It omits failure behavior, resource cost, and whether this spawns a new process vs. tab.

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 core action and its key trait, then usage scenarios, then the sibling routing, then the option/return note. Four tight sentences 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?

For a session-creating tool with no output schema, the description covers purpose, active-session semantics, sibling routing, and return shape ('the new session and overall status'), while the schema fully documents parameters. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters (browser enum, headless, sessionId, windowSize, browserArgs, timeouts). The description only adds 'takes the same options as start_browser', which is useful context but not parameter detail. Baseline 3 applies.

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

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

States a specific verb and resource (open a browser session) plus the distinguishing traits: 'additional, independent' with its own window, cookies, and login state, and that it becomes the active one. This clearly separates it from start_browser (first session) and session_select (switching).

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 usage scenarios (test several users like buyer/seller, compare two states) and names the switching alternative (session_select). It does not explicitly contrast against start_browser as the 'when not to use', leaving that inference to the word 'additional'.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the destructive side effects (cookies, login state, and open pages are lost; the browser process quits) and the active-session reassignment behavior, including the last-session edge case. It omits return value/error semantics, but the core behavioral profile is covered.

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

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

Three tight sentences, zero filler, front-loaded with the destructive effect and closing with alternative routing. 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?

For a single-parameter mutation tool with no annotations and no output schema, the description covers purpose, destruction, and side effects adequately. Minor gaps remain around failure modes and whether an id validation error occurs, so it is strong but not exhaustive.

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

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

Schema coverage is 100% and the single parameter is fully documented in the schema (id returned by session_create or session_list). The description restates 'by id' but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (close/destroy) and resource (one browser session) plus the concrete consequence 'quit its browser.' It is immediately distinguishable from stop_browser, which acts on the active session rather than a specified id.

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 routes the agent to an alternative: 'To close just the active session, stop_browser does the same.' That is a clear when-to-use-this-vs-that statement, though it gives no guidance on error conditions (unknown id, already-closed session) or whether the target must first be selected.

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

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

No annotations are provided, so the description carries the full burden. It compensates by disclosing the exact shape of the result (the fields and the active marker), effectively standing in for the missing output schema, and 'List' signals a non-mutating read. It stops short of stating whether the list can be empty or whether sessions from other clients 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?

Two sentences, no filler. The what (list with field breakdown) is front-loaded and the routing guidance follows immediately, so an agent gets value from the first clause onward.

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, read-only listing tool with no output schema and no annotations, the description covers the return shape and the intended follow-up actions. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly adds no parameter guidance because none is possible.

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 ('List every open browser session') and enumerates exactly what each entry contains (id, browser, headless, window size, start time, active flag). This cleanly separates it from the session_create/session_select/session_destroy siblings, which mutate rather than enumerate.

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 downstream alternatives and the condition that selects them: use this to find ids for session_select or session_destroy, or to check what is still running. The agent does not have to infer when this tool is the right entry point.

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

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

With no annotations, the description carries the burden and does disclose key behavior: other sessions remain open untouched, and the selection governs every following tool call (ambient state). It omits what happens on an invalid or destroyed session id, which is a notable gap for a state-changing tool.

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

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

Three short sentences, front-loaded with the action and then the side-effect and the id source; nothing redundant.

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

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

For a one-parameter selector with no output schema, the description covers purpose, cross-call effect, and id sourcing adequately; only error behavior on an invalid id is left unstated.

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

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

Schema description coverage is 100% and the single sessionId parameter is already documented as coming from session_create or session_list, so the description adds only a pointer to session_list rather than new semantics. Baseline 3 applies.

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

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

States a specific verb and resource ('Make an existing browser session the active one') plus the effect on subsequent calls, which cleanly separates it from session_list, session_create, and session_destroy.

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 clear operating context (multi-session switching) and points to session_list for obtaining ids, but never states when this should be preferred over session_create/start_browser or what to do when no session is currently open.

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

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

No annotations, so the description carries the full disclosure burden. It discloses two valuable non-obvious behaviors: the session is a singleton that all other tools act on, and the driver is auto-downloaded by Selenium Manager. It stops short of failure modes (e.g. browser not installed beyond the schema note) or auth/permission requirements.

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?

Five tight sentences, front-loaded with the core action and the ordering instruction before the constraints and alternatives. Every sentence carries a distinct, useful fact.

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

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

For a 6-parameter, all-optional tool with no output schema, the description covers the key invocation contract (call first, singleton, driver auto-fetch) and notes the return value ('Returns the session status.'). Slightly light on what the returned status contains, but adequate.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema with defaults, ranges, and examples. The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 is appropriate.

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

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

States a specific verb (Start) and resource (a browser session) with the concrete browser options, and explicitly distinguishes itself from stop_browser and session_create in the same breath. An agent can identify this tool 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?

Explicit sequencing guidance ('Call this first'), the singleton constraint, and named alternatives with the conditions that select them ('call stop_browser before starting another, or use session_create to run several browsers at once'). Nothing is left to inference.

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

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

With no annotations provided, the description fully carries the behavioral burden: it warns that cookies, login state, and open pages are lost, explains multi-session behavior (only active closes, another becomes active), and states that calling it when nothing is running is safe.

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 core action and destructive consequence, then efficiently layers in multi-session behavior, the alternative tool, and safe no-op guidance. Every sentence earns its place with no wasted wording.

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

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

For a zero-parameter, no-output-schema tool with no annotations, the description is complete: it covers the operation, side effects, multi-session routing, safety, and recommended usage timing. Nothing needed for correct invocation is missing.

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

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

There are zero parameters and the schema is empty, so parameter semantics are not applicable. The baseline for a zero-parameter tool is 4, and the description appropriately adds no unnecessary parameter detail.

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

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

States a specific verb and resource: close the active browser session and quit its browser. It also distinguishes the tool from its closest sibling by explicitly naming session_destroy for closing a specific 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?

Gives explicit when-to-use guidance ('Call it when you are done'), a safe no-op condition ('Safe to call when nothing is running'), and the alternative for a different need ('use session_destroy to close a specific one').

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

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

With no annotations, the description carries the full burden and does well: it discloses the return format (base64 and/or disk), that folders are created as needed, and that an existing file is overwritten – a clear destructive-on-disk side effect. It omits any note on permissions or capture timing, but the important behavioral traits are covered.

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

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

Three sentences, all front-loaded: purpose first, then behavior/side effects, then the routing guidance. Every sentence earns its place and nothing is redundant.

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?

Complete for a screenshot tool with no output schema: the description explains both the returned payload (base64) and the disk-write behavior, and gives clear routing relative to the many sibling read/inspect tools. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, and both parameters are fully documented in the schema, including the savePath example paths and the includeBase64 default. The description reinforces the base64/savePath duality but adds no syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('Capture a PNG screenshot of the visible viewport'), including the scope ('visible viewport') that distinguishes it from a full-page capture. It also names the sibling capture_page and the text-based alternatives, so an agent can route between them without opening a 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?

Explicit when-to-use ('when visual layout or appearance matters, or to show the user a step') and explicit when-not with named alternatives ('To check text or state, prefer capture_page, get_text, or the assert tools'). The exclusion criterion ('exact and much smaller than an image') gives a concrete decision rule.

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

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

With no annotations, the description carries the full burden and does well: it discloses the visibility wait, that the field is cleared first (clearFirst: false appends), that text is sent as keystrokes so the page's input events fire, and that submit: true presses Enter. It does not cover failure behavior (e.g., what happens if the element is not found within timeoutMs) or the return payload, which keeps it 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?

Three dense sentences, front-loaded with the core action and behavior, then the submit/clearing modifiers, then the sibling routing. No filler and nothing buried.

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

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

For a 6-parameter mutation-style tool with no annotations and no output schema, the description covers action, waiting, clearing, keystroke semantics, submit behavior, and alternative tools. It leaves failure/retry behavior and the response undefined, which is a modest gap rather than a blocker.

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

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

Schema description coverage is 100%, so the schema already documents ref, text, submit, selector, timeoutMs and clearFirst in detail; baseline is 3. The description restates clearFirst/submit semantics rather than adding new syntax or format information, so it adds little beyond the structured fields.

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

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

States a specific verb and resource ('Type text into an input, textarea, or other editable element') and explicitly disambiguates from siblings by naming select_option for dropdowns and press_key for single keys. An agent can distinguish this from click/press_key/select_option without opening any 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?

Gives explicit routing: use this for editable text fields, use select_option for dropdowns, use press_key for single keys like Tab/Escape. It also states the two targeting modes (selector or a ref from capture_page), so when-to-use and how-to-target are both covered.

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

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

No annotations are provided, so the description must carry the full burden. It does well: explains waiting for input existence, that hidden inputs are common, that the file must exist on the server's machine, and the post-upload click expectation. Doesn't cover whether the attach triggers events or what happens on failure, but covers the behavioral essentials 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?

Four sentences, all earning their place, front-loaded with the action and the picker-avoidance point. No filler or repetition of the name.

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

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

For a 3-param nested-schema tool with no output schema and no annotations, the description covers the core workflow and edge cases (hidden input, server-side file, follow-up click). Missing a note on return value/errors and any permission or security context, but broadly complete for the browser-automation domain.

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

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

Schema description coverage is 100% with rich parameter docs (selector object, filePath examples, timeoutMs default/range). The description adds the server-side file location fact ('on the machine running this server'), reinforcing filePath semantics, but otherwise the schema fully documents parameters. Baseline 3 is appropriate.

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

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

States a specific verb+resource: attach a local file to a file input. Distinguishes from sibling 'type' or 'click' by clarifying it bypasses the OS file picker and targets the hidden input directly, which is the key differentiator for upload tools.

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

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

Gives context on when to use (attach without picker) and what to do afterward ('click the page's upload or submit button if it has one'), plus the constraint 'the file must exist on the machine running this server'. No explicit when-not guidance or named alternatives, but strong for the category.

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

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

No annotations are provided, so the description carries the burden. It discloses the default existence-vs-visibility semantics, the returned state fields (displayed, enabled), and the timing behavior implied by 'wait'. It does not state what happens on timeout (error vs return) or block/polling behavior, which is a meaningful gap for a waiting primitive with no annotation coverage.

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

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

Four front-loaded sentences, each earning its place: what it does and returns, when to use it, when not to, and where to go instead. No filler or redundancy.

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

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

Complete for a 3-param waiting tool with full schema coverage and no output schema: purpose, semantics, and routing to siblings are all covered. The remaining gap is timeout/error behavior, which matters for a blocking primitive but is partially inferable from the timeoutMs parameter and default.

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

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

Schema description coverage is 100%, so both selector and visible are already fully documented in the schema with examples and defaults. The description reinforces the visible toggle but adds no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 (wait for element) with explicit scope: existence by default, visibility with visible:true, and return payload (tag and state). Clearly distinguishes itself from siblings like click/type/get_text which self-wait, and routes URL/title waits to wait_for_page.

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

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

Explicit when-to-use with concrete scenarios (spinners finishing, lazy lists, dialogs, SPA transitions), an explicit when-not-to-use note ('click, type, and get_text already wait for their own target'), and a named alternative for URL/title changes (wait_for_page). Nothing left to inference.

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

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

No annotations, so the description carries full burden and does well: it discloses return behavior (final URL and title), timeout error content (the URL/title actually observed), and combined-condition semantics. Left implicit are the default/max timeout bounds (in schema) and blocking nature, so not quite 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?

Three tight sentences: purpose/conditions first, usage context second, return/timeout and the sibling pointer last. No filler, front-loaded with the core capability.

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?

No output schema, yet the description explains what is returned and what a timeout error reveals. Combined with 100% schema coverage and no annotations needed for a read-only wait, an agent has everything required to invoke it correctly.

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

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

Schema coverage is 100% and each parameter documents its own semantics including examples and defaults, so the schema does the heavy lifting. The description adds the AND-combination rule across conditions, which is genuine value, but per-parameter meaning is otherwise redundant.

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 (wait) and resource (current page URL/title), enumerates the exact conditions (urlContains, urlMatches, titleContains) and their AND semantics. Clearly distinguished from sibling wait_for_element, which it explicitly names.

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 says when to use it: after a navigating/redirecting action (login submit, link click, SPA route change) and before checking the new page. Also routes the agent to wait_for_element for element waits, so both when-to-use and alternative are covered.

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

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

With no annotations, the description carries the full behavioral burden and does well: it states side effects (new_tab/new_window open a blank one and switch to it; close closes the current one and then switches to another handle), the return values ('window handles, or the resulting window and viewport sizes'), and the Chrome/Edge-only caveat for exact phone sizes. It does not state permissions or rate limits, but nothing suggests those apply.

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 top-level scope and then a tight action-by-action breakdown. Every clause earns its place; 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?

For an 8-action tool with no output schema, the description covers the main behavior, side effects, and return shape. It is slightly short of complete because it does not explain what happens if switch is called with a stale handle or whether resize affects only the current window.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by giving concrete action-to-parameter mappings (width/height for resize, handle for switch) and device-emulation guidance (exact phone sizes use device emulation on Chrome/Edge) that the schema does not contain.

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

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

The description opens with a specific verb+resource ('Manage browser tabs and windows, and resize the viewport') and then enumerates every action with a precise definition, so an agent can distinguish this from siblings like frame or alert that also affect 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?

Each action enum value is explained with a when-to-use condition (e.g. 'switch = go to a handle from list', 'switch_latest = go to the newest tab/window (e.g. after a link opened a new tab)'), which is strong. It does not name alternatives, but this tool has no direct sibling for tab/window management, so the gap is minor.

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