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

No annotations are present, so the description carries full burden. It discloses read-only behavior, blocking semantics for element/text assertions, immediate checks for title/URL, timeout handling, and that failures are returned as errors via handle_sb_errors. This is thorough behavioral context beyond the schema.

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

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

The description is well-structured with clear sections, front-loading the purpose and distinguishing features. Every section (Args, Returns, Tool selection) is purposeful and efficient, with 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 the tool's complexity (multiple assertion types, blocking vs immediate checks, error handling), the description covers all necessary aspects: parameter details, return behavior, and selection guidance. The output schema exists, but the description does not need to explain return values, and it doesn't.

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

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

Schema description coverage is 0%, so the description must document all parameters, and it does. Each parameter is explained with allowed values, requirements, and specific behavior (e.g., 'exact' only for text_visible, 'timeout' ignored for title/URL). It adds meaning beyond the bare schema.

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

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

The description clearly states the tool verifies a browser condition and reports failure as an error, with a specific verb and resource. It enumerates the exact conditions and distinguishes from check_condition and wait_for.

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 explains when to use it versus alternatives, with a dedicated 'Tool selection' section. It says to use check_condition for inspection without failing, wait_for for synchronization, and assert_condition for verifying expectations, leaving no ambiguity.

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?

Describes return behavior (boolean, False for missing elements, string on error) and explicitly states it does not wait. Also notes the precedence of text over check, providing full transparency about behavior without reliance on annotations.

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

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

The description is well-structured with sections for Args, Returns, Tool selection, and Notes. It is thorough but not wordy, with all content directly relevant to using the tool.

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

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

Given the tool's moderate complexity, it covers purpose, usage, behavior, parameters, and return values. It also includes notes about waiting behavior, making it complete for an agent to use 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?

Explains all three parameters: check (with enum values), selector (CSS selector), and text (optional, with precedence over check). This adds meaning beyond the raw schema, which has no parameter descriptions.

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

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

The description clearly states the tool checks the current state of an element or text without waiting, and distinguishes it from wait_for and assert_condition. It also provides a tool selection section that clarifies its specific role.

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 ('immediate boolean observation') and contrasts with wait_for and assert_condition, providing clear guidance on alternatives. Also notes it does not wait, so users know not to use it for async conditions.

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

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

No annotations are provided, so the description carries the full burden, and it delivers: it discloses selection precedence, visibility waiting behavior, navigation-cancellation side effects, timeout applicability, and scroll default. This goes well beyond a generic click description.

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?

Despite being long, the description is front-loaded with a one-line purpose, followed by a compact precedence list, detailed Args, and examples. No filler; the length is justified by the number of modes and caveats.

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 seven-parameter tool with no annotations, the description covers all invocation modes, edge cases, and defaults. The presence of an output schema means return-value details are not required; nothing needed to call this 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 description coverage is 0%, but the Args section explains every parameter's meaning, default, constraints, and interactions, such as nth being 1-based, parent_selector enabling iframe scoping, and all_matches being ignored when nth is set. Examples map parameters to concrete calls.

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 and resource: 'Click element(s) matching a CSS, XPath, or supported text selector.' The enumerated click modes and examples make clear this is the click action, distinct from siblings like hover_action, type_text, or focus.

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 conditions for each click mode, including precedence order and a warning to use all_matches only when multiple clicks are intentionally desired. It does not explicitly contrast with sibling tools like hover_action, but the mode guidance is strong enough to select the correct invocation.

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 available, the description carries full behavioral disclosure. It states that the session's persistent state is ended, enumerating open tabs, cookies, navigation history, and page state, and confirms that calling it with no active session 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?

The description is compact and front-loaded with the core action. Each sentence provides distinct, useful context: what it does, when to use it, the alternative, and no-session safety.

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-parameter lifecycle tool, the description fully covers purpose, timing, state effects, fallback, and edge-case safety. Since an output schema exists, not detailing the return format is acceptable.

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

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

The tool has zero parameters and 100% schema description coverage, so parameter explanation is unnecessary. A baseline of 4 is appropriate because the description does not need to add parameter semantics.

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

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

The description opens with a specific verb and resource: 'Close the active browser session and release browser resources.' It also differentiates from sibling start_browser by describing the closure as ending the session and pointing to starting a new session if needed.

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

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

It explicitly says to call this when the browser automation workflow is finished and names start_browser as the alternative for subsequent automation. It also clarifies behavior with no active session, removing ambiguity.

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 behavioral burden and does so richly: it states results are converted to ordinary serializable dicts (not live element objects), that handles cannot persist across MCP calls, that timeout may be shortened for non-convertible XPath, and that errors surface as an 'error' key. These are exactly the traits an agent needs to avoid misuse.

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 gated by clear section headers (Args, Returns, Tool selection, Notes), so it is navigable. It is somewhat long and the Returns block partially restates the output schema, but nearly every line adds routing or behavioral value.

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

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

Complete for a discovery tool: it explains purpose, parameter behavior, return shape (even beyond the existing output schema), error behavior, and the critical cross-call handle limitation. No gap remains that would cause an incorrect invocation.

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

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

Schema description coverage is 0%, yet the Args section documents all three parameters with meaning beyond the schema: selector as CSS or SeleniumBase-convertible XPath with the contains(...) limitation called out, timeout as a wait-for-first-match bound with a fallback caveat, and include_html controlling outer HTML in output.

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

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

Starts with a specific verb+resource ('Find matching elements and return structured element information') and then explicitly distinguishes itself from siblings get_content, click, and check_condition in the Tool selection section. An agent can identify the tool's role 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?

Provides an explicit 'Use this tool when...' trigger list (count, text/tag inspection, HTML of multiple matches) and a Tool selection block naming the alternative for each adjacent need. When/when-not and alternatives are all 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 well: it discloses that 'highlight' changes the border color, may affect timing, and may 'reduce stealth', and that a timeout raises an exception surfaced by @handle_sb_errors. It does not state side effects on page state (e.g., whether focusing can trigger blur/focus handlers or scroll the page layout), leaving a small gap for a tool with UI side effects.

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

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

Front-loaded purpose sentence, then the exclusion clause, then a clean Args breakdown ordered by importance. Every sentence adds information; there is no filler or restatement 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?

The tool is non-mutating but has UI side effects and an output schema, so return values need no explanation. Given no annotations, the description supplies the safety profile (does not activate), the enum semantics, the timeout default, and the error path — enough for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, but the description compensates fully: it defines `selector` as a CSS or SeleniumBase selector, explains each of the three `action` enum values with their actual effect, and restates the `timeout` semantics and default. Nothing in the schema is left semantically unexplained.

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

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

The opening line names a specific verb set (scroll to, focus, highlight) and the resource (an element), and it immediately distinguishes the tool from its siblings by naming the operations it does NOT perform. An agent can separate this from `click`, `scroll`, or `hover_action` 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 when-not guidance is given: 'This tool does not click, type, select, hover, or otherwise activate the element. Use `click`, `type_text`, or `hover_action` for those operations.' This routes the agent to the correct alternatives with the selecting condition stated.

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

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

With no annotations, the description carries the full burden and does well: it declares the operation read-only, documents the timeout default of 5 seconds, and states that a missing element surfaces via @handle_sb_errors rather than silently succeeding. It does not cover whether the element is waited for, retried, or searched in iframes/shadow DOM, 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?

Front-loaded with the one-line purpose, then structured Args/Returns/Tool selection sections that are easy to scan. Slightly heavier than needed — the 'Returns' line adds little given an output schema exists, and the classification of attributes is somewhat verbose — but no sentence is truly 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?

Given an output schema exists, the brief Returns note is acceptable, and the description covers input semantics, timeout behavior, failure mode, and sibling routing. Enough for an agent to call this correctly; only edge cases like frames or waiting semantics are unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it documents all three parameters: selector accepts CSS or SeleniumBase-supported XPath, attribute is optional and yields a dictionary of all attributes when omitted, and timeout defaults to 5 seconds. This adds real meaning beyond the bare schema, though it doesn't clarify selector-matching semantics (first match vs. uniqueness) in 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 (Read), resource (HTML attributes), and scope (first matching element), with examples of the attribute kinds returned (href, src, class, aria-label). The 'Tool selection' section explicitly separates it from find_elements, get_content, and check_condition, so an agent can route correctly without opening 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?

Provides explicit when-to-use guidance plus a routing table naming three sibling alternatives and the condition that selects each. The single-attribute vs. all-attributes distinction is also spelled out, 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, so the description carries the full behavioral burden. It usefully discloses the timeout default of 5 seconds and that returned URLs are normalized with protocol prefixes, but it says nothing about failure behavior (e.g., element not found / timeout expiry) or that this is a non-mutating read.

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 core sentence followed by Args and tool-selection blocks; each line is informative. The tool-selection list slightly restates the output_format descriptions, costing a little 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 an output schema present, return-value detail is not required, and the description still clarifies format semantics. It covers params and alternatives well; the only shortfall is unstated error/timeout behavior for a browser-automation read tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it defines selector as CSS or SeleniumBase XPath, enumerates all three output_format values with meaning, and states the timeout default. Only minor gaps remain (e.g., selector default 'body').

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: 'Read visible text, HTML, or discovered URLs from the selected element.' An agent can distinguish it from siblings like get_page_info and find_elements directly from this sentence.

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 'Tool selection' block explicitly names the conditions that route to get_page_info, find_elements, check_condition, wait_for, and the three internal output_format modes. This is exactly the when-to-use/when-to-not 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?

Despite having no annotations, the description explicitly labels the operation as READ-ONLY, states it does not navigate/reload/click/type, explains the running:false no-session behavior, and clarifies it will not attempt page-level operations when no session exists. This thoroughly covers behavioral expectations.

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?

Well-organized and front-loaded, with distinct sections for purpose, return value, and tool selection. It is longer than minimal, but the extra length is mostly functional; one sentence ('Unlike a dedicated browser-status tool...') is somewhat redundant with the rest of the description.

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

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

For a zero-parameter, read-only metadata tool, the description covers the exact return fields, the false-running edge case, what it does not do, and routes to all relevant siblings. No important context is missing.

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

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

The tool has zero parameters)Skip baseline of 4 appliesheart. The description compensates by documenting the return fields (url, title, origin, user_agent, running) and the no-session case, which is meaningful context even though there is nothing to explain about parameters.

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

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

The description opens with a specific verb and resource: 'Get current browser session and page metadata.' It immediately distinguishes itself from siblings by identifying when to use it and what it does not do (find elements, check visibility, get content), making disambiguation easy.

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 guidance on when to use it ('primary tool for determining where the browser currently is after navigation, clicks...') and includes a tool-selection list mapping sibling tools to their specific use cases. No ambiguity about 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?

The description discloses the main behaviors: hovering, clicking, dragging, dropping, and returning a confirmation message. It doesn't mention potential side effects like navigation or waiting, but with no annotations provided this is a reasonable level of 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?

The description is well organized with clear sections, but the Notes section repeats selector-role information already stated earlier. It is still concise enough to be easily parsed.

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

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

The description covers the action enum, selector requirements, tool-selection guidance, and return value. Given that no annotations or output schema were provided, this is a complete description for an agent to invoke the tool correctly.

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

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

Every parameter is thoroughly explained: selector1, selector2, and the action enum. The description states when selector2 is required and clarifies the role each selector plays for each action value.

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

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

The description clearly states the tool's purpose: hover over an element, optionally click another, or drag-and-drop. This distinguishes it from sibling tools like click and find_elements.

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 Tool selection section explicitly maps use cases to action values: simple hover to none, hover-then-click to click, and drag-and-drop to drag_and_drop. This leaves no ambiguity about when to use each mode.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It warns about filesystem access, potential file overwriting, privacy of cookie data, and the unreliability of restoring logins. It also clearly notes that cookies may be expired or domain-restricted, giving a transparent view of limitations.

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 well-organized into sections (Description, Args, Returns, Security, Notes) and every sentence contributes essential information. It is detailed but not redundant, balancing thoroughness with clarity.

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

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

Despite lacking an output schema, the description textually describes the return expectations for each action (e.g., confirmation containing filename). It also covers security considerations, file overwriting behavior, and functional limitations, making it complete for an agent to decide when and how to use the tool.

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

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

The schema provides no descriptions, but the tool description explains both parameters thoroughly: action with its four enum values and their effects, and filename with its purpose for save/load and that it is ignored for get_all/clear. Defaults are also mentioned implicitly. This adds significant meaning beyond the raw schema.

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

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

The description clearly states 'Manage cookies for the current browser session' and then enumerates four specific actions (get_all, clear, save, load). This is distinct from sibling tools like manage_storage or manage_window, making its purpose unambiguous.

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

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

The description provides concrete usage scenarios (preserving login sessions, restoring saved sessions, resetting website state during testing) and notes about navigating to a site before loading cookies. However, it does not explicitly state when to prefer this over a sibling tool like manage_storage, so it falls short of fully explicit when/when-not guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It warns that navigation actions can trigger page loads or redirects and recommends verification afterward. It does not fully describe failure modes or state effects of reload, but the key behavioral risk is surfaced.

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?

Compact and front-loaded: the purpose, action options, and the important caveat about page loads are all stated efficiently. Every sentence contributes value without 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 a single enum parameter, an output schema, and no annotations, the description covers the essential operational details: action semantics, the risk of navigation effects, and a follow-up verification step. Nothing critical is missing for correct invocation.

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

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

Schema description coverage is 0%, but the description fully compensates by defining the semantics of every enum value: back, forward, reload (including cache bypass), and list (returning history position and entries). This gives the agent everything needed to choose the right action.

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 purpose: managing or inspecting the current browser tab's navigation history, and enumerates four distinct actions. It also explicitly distinguishes itself from the sibling 'navigate' tool by directing arbitrary URL navigation to that 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?

Provides clear guidance on when to use each action and explicitly names the alternative tool ('navigate') for arbitrary URLs. It also instructs the agent to call get_page_info afterward to verify the resulting URL or title, which is actionable and useful.

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 includes return behavior, security warnings about sensitive tokens, and origin scoping. It could more explicitly mention that setting a value overwrites an existing key, but the overall behavior is well disclosed.

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 well-organized into purpose, selection guidance, parameter explanations, returns, security, and notes. Every section adds useful information, and the structure makes it easy to scan.

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

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

Despite having no output schema, the description covers what the tool returns, security considerations, and the important scope-of-origin constraint. This gives an agent enough context to use the tool correctly and safely.

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

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

The description explains all four parameters in plain language, including that value is required when action is 'set' and that storage selects local or session storage. This adds meaningful guidance beyond the bare schema titles and enum lists.

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

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

The description clearly states the tool's function: 'Get or set a key in localStorage or sessionStorage.' It specifies the resource (web storage), the actions (get/set), and distinguishes this tool from siblings like manage_cookies and run_javascript.

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

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

It explicitly says when to use this tool for localStorage/sessionStorage and when not to, naming alternatives such as manage_cookies, run_javascript, get_content, and get_attributes. This gives clear guidance for an agent to select the correct tool.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses what `list` returns, that `switch` depends on `tab_index` from `list`, that indexes are session-relative and may change, and that re-listing is needed before switching. It does not explicitly describe side effects of closing a tab, but 'close' is self-explanatory.

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

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

Well organized with a front-loaded purpose and clear action-by-action bullets. The opening sentence is slightly redundant with the following 'Use this for...' sentence, but the overall structure is efficient and scannable.

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

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

This is a complete, self-contained definition for a multi-action tab tool: all actions and parameters are covered, the unstable tab-index behavior is called out, the `list` output is described, and sibling tools are named for alternative usage. The existing output schema covers return shape details.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining each parameter in action context: `url` is for `open`, `tab_index` is for `switch`, and `switch_to` controls whether to switch after opening. It also explains every action enum value.

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

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

States it manages browser tabs and explicitly scopes operations to listing, opening, switching, and closing. It also distinguishes itself from `navigate` and `manage_history`, which are for in-page navigation, so an agent can tell it apart from siblings.

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

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

Gives direct guidance: use this tool for tab-level operations and use `navigate`/`manage_history` for navigation within the active tab. The per-action bullets further clarify which action is appropriate for each use case.

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 is the only behavioral source. It states the meaning of each action and the set_rect requirement that all four geometric values be present, which gives a clear expectation. It does not disclose preconditions like whether a browser window must already be active or how maximize/minimize interact with existing geometry, leaving a small gap.

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

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

The description is well-organized with a one-line summary, a compact action list, parameter explanations, and a usage boundary note. Every section contributes information an agent needs, with 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?

The output schema exists, so return-value documentation is not needed. The description covers the action semantics, parameter constraints, and the key sibling alternative. It only omits minor preconditions such as requiring an already-open browser window, which is a small gap given the tool context.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning by itself. It defines what each parameter means, ties x/y/width/height specifically to set_rect, and corrects the schema's all-optional impression by noting that all four are required for set_rect.

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 opening line clearly states the tool works on browser window geometry and state, and the enumerated actions (get_rect, set_rect, maximize, minimize) leave no ambiguity about what it does. It also distinguishes itself from the sibling manage_tabs in the final sentence.

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

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

The description explicitly says to use it for browser-window geometry and state, and directly points to manage_tabs for the likely alternative use case. This gives agents a clear when-to-use and when-not-to-use signal.

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

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

With no annotations, the description carries the full behavioral burden. It explains the automatic https:// prefix, that navigation waits for the browser operation to complete, and that dynamic content may still load, recommending wait_for for synchronization. These are non-obvious and valuable behavioral details.

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 well organized with front-loaded purpose, a short args section, and a dedicated tool-selection list. Each sentence adds relevant information without redundancy, making it easy to scan.

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

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

For a single-parameter navigation tool with an output schema, the description covers the core behavior, parameter semantics, waiting behavior, and alternative tool routing. It is complete enough for an agent to invoke it correctly without additional inference.

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

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

The schema provides no description for the url parameter (0% coverage), so the description must compensate. It does so by defining the parameter as a destination URL and giving both complete URL and hostname examples, clarifying accepted formats.

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

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

The description clearly states the tool navigates the current browser tab to a URL, with a specific verb and resource. It also distinguishes navigate from history-based movement (back/forward/reload), making its purpose unambiguous relative to siblings.

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

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

The description explicitly says when to use navigate versus manage_history, including a clear tool-selection section: new URL -> navigate, back/forward/reload -> manage_history. This gives an agent direct decision 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 burden and does well: it warns that this provides unrestricted JavaScript execution, can read or modify page data, bypasses higher-level abstractions, and should only be exposed to trusted clients. It also discloses return serialization limitations.

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 long but well-organized under Args, Returns, and Security sections, and every sentence serves a purpose. The length is justified by the need to convey safety implications, return behavior, and usage boundaries.

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?

Even without an output schema, the description explains what kinds of values can be returned and what cannot be serialized. It also provides enough security context and usage boundaries for an agent to decide when this tool is appropriate.

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

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

Although the schema provides only a type and title for the expression parameter, the description fully compensates by explaining what the expression may reference, providing multiple examples, and noting Promise support. This gives the agent sufficient semantic understanding despite the schema's 0% coverage.

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

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

The description clearly states the tool evaluates a JavaScript expression in the current page context, using a specific verb and resource. It also distinguishes itself from higher-level SeleniumBase tools by explaining it is for operations those tools do not expose.

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

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

It explicitly says to use this tool only when higher-level tools cannot accomplish the operation, and it lists the preferred sibling tool categories for clicking, typing, reading content, managing storage, and cookies. This gives an agent concrete selection 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 fully carries the behavioral transparency burden. It discloses side effects (writes a file, may overwrite), permissions, filesystem safety, that it does not navigate or modify the page, that no upload/publish occurs, and the error behavior for missing session and filesystem failures. This is comprehensive beyond what any structured field would convey.

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?

Although the description is long, it is well-organized into clear sections (side effects and filesystem behavior, error behavior, when not to use, returns) that each carry essential information. The core purpose is front-loaded and every section has a distinct purpose in guiding correct invocation.

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?

Taking into account the tool's complexity, the absence of annotations, and the spare schema, the description is sufficiently complete. It covers prerequisites, parameter semantics, side effects, error behavior, and expected return, leaving no critical gap an agent would need to guess about.

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

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

The schema has no descriptions (0% coverage), but the description covers all three parameters thoroughly. It explains each format enum value, the default filename per format, the optional nature of folder/filename, and what the folder does. This gives the agent full semantic understanding that the schema alone cannot provide.

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

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

The description opens with a specific verb and resource: 'Save the current browser page to a local filesystem file.' It further clarifies it produces a PNG screenshot, HTML source, or PDF from the active tab, and the 'When not to use' section distinguishes it from get_content, get_page_info, and interaction tools. This makes the tool's purpose unmistakable and well differentiated from siblings.

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

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

The description explicitly states when to use the tool: when a persistent file artifact is needed from the current page. It also provides clear negative guidance, listing get_content for reading text/HTML, get_page_info for metadata, and interaction tools for page manipulation. This is exactly the level of directional 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 burden of behavioral disclosure. It explains that scrolling is relative to viewport height, that amount is a percentage, allows values >100, and that top/bottom ignore amount. It does not mention side effects like scroll events or page loading, but for a simple scroll operation this is adequate.

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

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

The description is concise and well-structured: a one-sentence purpose, followed by a clear list of parameters with explanations, and a final line for alternative usage. Every sentence adds necessary value with no redundancy.

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

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

For a scroll tool, the description covers the main action, all parameter semantics, and when to choose an alternative, which is all an agent needs to call it correctly. An output schema exists, so not describing return values is acceptable.

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

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

Schema coverage is 0% and the description fully compensates: it explains the direction enum with behavior for each value, defines amount as a percentage of viewport height with an example (amount=25 → one quarter), and notes that values >100 are valid. This goes far beyond the bare schema.

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

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

The description clearly states it scrolls the current page vertically, and lists explicit direction options (up, down, top, bottom) with their behavior. It distinguishes itself from the sibling tool focus, which is for scrolling to a specific element, by explicitly naming it as an alternative for that use case.

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 guidance: 'Use focus(action="scroll_to_element") when the goal is to reveal a specific element rather than scroll the page by a relative amount.' Also explains when each direction value applies and notes that amount is ignored for top/bottom, giving clear context for parameter selection.

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

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

The description discloses that an error is raised when the dropdown or requested option cannot be found. It does not mention potential side effects like triggering change events, but this is a minor omission given the straightforward nature of the action.

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

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

The description is concise, well-organized, and every sentence adds useful information. No redundant or vague phrasing.

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

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

The description covers all necessary usage context, parameter semantics, and error behavior. It does not describe a return value, but the tool's output is likely not a primary concern for a selection action.

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

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

Although the schema lacks descriptions, the tool description fully explains every parameter: dropdown_selector, value, and by, including the meaning of each enum value for 'by' and acceptable types for 'value'.

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

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

The description clearly states the tool's purpose: selecting an option from an HTML <select> dropdown. It also distinguishes itself from other element-interaction tools by explicitly limiting its use to native <select> elements.

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

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

The description explicitly states when to use this tool (native <select> elements) and when not to use it, directing users to click or other element-interaction tools for custom JavaScript dropdowns.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job: it explains the stealth mechanism (CDP vs JavaScript, avoiding isTrusted: false), automatic coordinate detection, the lack of guarantee of success, limitations with shadow DOM, and potential side effects (changes to page state or cookies). It also outlines the return message and its non-guarantee. This is comprehensive and honest.

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 well-structured with sections and a numbered workflow, which aids readability. It is somewhat lengthy but every sentence adds value: it covers purpose, stealth, detection, limitations, workflow, and return value. It is front-loaded with a clear purpose statement, and the workflow steps are concise. The length is justified by the need to explain complex behavioral nuances.

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

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

Given the tool's simplicity (0 parameters), the absence of annotations, and the existence of an output schema (which the description aligns with), the description is complete. It explains what the tool does, how it works under the hood, its limitations, and how to integrate it into a broader workflow. An agent has all necessary information to invoke it correctly and understand its outcome.

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

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

The tool has zero parameters by design, so there are no parameter semantics to describe. However, the description compensates by explaining what the tool does automatically (detects coordinates, no need for manual input). Since schema coverage is 100% but empty, the description adds value by clarifying that no arguments are necessary and that behavior is determined by page context. This is above the baseline for zero parameters.

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

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

The description clearly states the tool attempts CAPTCHA interactions via CDP, listing specific CAPTCHA types (Cloudflare Turnstile, reCAPTCHA, hCaptcha, DataDome Slider, FriendlyCaptcha) and actions (click, drag/drop). It distinguishes itself from simpler JavaScript actions by emphasizing stealth, and from other tools like 'click' by focusing on CAPTCHA-specific automation. The purpose is unambiguous and well-scoped.

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

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

The description provides an explicit workflow: first inspect with get_content, then call solve_captcha, then verify with get_page_info or check_condition. It names specific sibling tools for pre- and post-conditions, and states when not to use (if no CAPTCHA is detected, no action is performed). This gives clear guidance on when and how to use the tool, and what to do after.

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 excels: it discloses session persistence via CDP rather than WebDriver, the automatic single retry on launch failure, platform-specific headless defaults, and the fact that an existing session is reused. It also covers return behavior and environment prerequisites, which is exemplary for a tool with zero structured annotations.

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

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

The description is long but the length is largely justified by 8 parameters and important lifecycle/environment context. It is well-sectioned and front-loaded with the core purpose, though there is minor redundancy in the lifecycle section that could be trimmed without loss.

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

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

Given the tool's complexity—8 optional parameters, platform-dependent behavior, and session lifecycle responsibilities—the description provides everything an agent needs: when to invoke, how to resolve missing browser discovery, what happens on retry, and how state persists. The output schema covers return values, so the brief Return section is appropriate.

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

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

Schema description coverage is 0%, so the description must compensate, and it documents all 8 parameters in an Args section with meaningful details. It adds mutual-exclusion guidance (browser_executable_path vs use_chromium), a warning not to combine guest with incognito=True, and practical examples for proxy formats.

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

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

The description opens with a specific verb and resource: 'Launch a persistent SeleniumBase Pure CDP Mode browser session.' It clearly distinguishes itself from sibling interaction tools such as navigate and click by framing it as the prerequisite startup step, making its role unambiguous.

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

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

The description explicitly says to call this before using browser interaction tools such as navigate, get_content, click, type_text, or find_elements, and to call close_browser when finished. It also explains that if a session is already running, the tool does not launch another one, giving an agent clear routing and lifecycle 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 thoroughly. It explains each mode's behavior—clearing, appending via keystrokes, typing without pauses, direct value setting without key events—and discloses timeout waiting and error handling via handle_sb_errors. This is rich behavioral context beyond what the schema could convey.

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?

Although longer than minimal, every section earns its place: purpose, scope, mode decision guide, timeout/error behavior, args, and returns. The structure is logical and front-loaded with the core purpose. There is no filler or repetition of schema defaults.

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

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

The tool is a moderately complex mutation operation with four parameters, no annotations, and zero schema-level descriptions. The description covers all parameters, all mode semantics, timeout behavior, error handling, and return values. Given the complexity, 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?

Schema description coverage is 0%, so the description must fully compensate, and it does. It provides an Args section explaining selector, text (including the 'ignored for clear_only' nuance), mode (with detailed enum semantics), and timeout. This converts an otherwise bare schema into actionable parameter guidance.

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 phrase—'Enter, append, directly set, or clear a value on a page element'—and clearly scopes the tool to modifying text/value fields. It distinguishes itself from siblings by explicitly noting it does not submit forms or click other elements. An agent can tell this apart from click, run_javascript, and select_option without opening 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?

The description clearly states when to use the tool ('modify text/value fields such as inputs, textareas, contenteditable elements, and supported input sliders') and gives a when-not boundary ('does not submit a form or click other elements'). It also provides mode-selection guidance, including a 'prefer this' recommendation for set_value. However, it does not explicitly name alternative sibling tools for cases where this tool should not be used.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool 'blocks until the condition is met or the timeout expires,' declares it 'does not intentionally scroll, click, or otherwise modify the page while waiting,' and explains the error-handling behavior when timeouts occur. It also details state-specific semantics (e.g., text handling with present/visible vs absent/not_visible).

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 thorough and well-structured, front-loading the core purpose and then branching into specifics. It is longer than average, but every sentence adds meaningful information. The use of bullet-like 'Args' and 'Returns' sections aids scanning. It loses one point only because brevity could be improved without losing substance.

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

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

Given the tool's complexity (4 parameters, multiple state modes, and dynamic-page use case), the description covers all necessary aspects: usage context, behavioral guarantees, parameter semantics, return values, and error handling. The inclusion of a 'Tool selection' section further completes the picture. Nothing an agent would need 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 0%, so the description must fully explain parameter meaning. It does: for each parameter, it provides detailed semantic explanation. For example, it clarifies that for `seconds_passed`, selector and text are ignored, that `text` changes the meaning of `present`/`visible`, and that `selector` is required unless text is supplied or state is seconds_passed. This goes far beyond the schema's bare types and defaults.

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

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

The description opens with 'Wait for a page condition or for a specified duration,' which clearly states the verb and resource. It explicitly distinguishes from siblings by naming check_condition and assert_condition and their different purposes, so an agent can tell them apart without inspecting 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?

The description provides explicit when-to-use guidance: 'Use this for synchronization when a dynamic page may need time to reach a condition before the next automation step.' It then names alternatives: 'Use check_condition to inspect the current state without waiting' and 'Use assert_condition to verify an expected condition rather than synchronize with a changing page.' This leaves no ambiguity about tool selection.

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