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

The description goes well beyond the annotations (readOnlyHint, idempotentHint) by explicitly stating it is read-only and does not modify the page. It also discloses blocking behavior for element/text assertions, immediate checks for title/URL, and how failures are handled via handle_sb_errors. This adds substantial context not present in the 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 structured logically with clear sections (purpose, behavioral notes, args, returns, tool selection). While it is long, every paragraph serves a distinct purpose and the core purpose is front-loaded. There is no filler or redundancy.

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

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

Given the tool has 5 parameters and 6 check types, the description covers every parameter's semantics, the exact return behavior (confirmation or error), and the timeout handling differences. It also addresses how it relates to siblings. An agent has all necessary information 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's 'Args' section thoroughly explains each parameter: what each check enum means, when selector/expected are required, the exact parameter's effect, and timeout constraints. This fully compensates for the lack of schema descriptions and provides far more meaning than 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 opens with a specific verb and resource ('Verify a browser condition') and then distinguishes itself from check_if_condition and wait_for_condition, making its purpose unambiguous. The tool selection section further reinforces what this tool does versus alternatives.

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

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

It explicitly states when to use it ('when an expected page state must be explicitly verified') and provides a dedicated 'Tool selection' list naming two sibling tools and the conditions under which they should be chosen instead. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral detail beyond these annotations: it explicitly states the tool does not wait, missing elements return False instead of raising an exception, and errors return a string with details. This gives the agent a realistic model of the tool's runtime behavior.

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

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

The description is well-structured with clear sections: purpose, usage guidance, arguments, returns, and tool selection. The key non-waiting behavior is front-loaded, and the tool selection section is compact and actionable. Each section earns its place without unnecessary 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 description is complete for an agent to select and invoke the tool correctly. It covers purpose, parameter semantics, return behavior, error handling, non-waiting behavior, and explicit routing to sibling tools. Given the annotations and output schema, nothing essential 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 carry the burden of explaining parameters, and it does. It defines the 'check' enum values ('present' and 'visible'), clarifies that 'check' is ignored when 'text' is provided, explains 'selector' as a CSS/SeleniumBase selector, and describes 'text' as an optional visibility check that takes precedence. This fully compensates for the schema's lack of 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 uses a specific verb and resource: 'Check the current state of an element or text without waiting for the condition to become true.' It clearly distinguishes itself from siblings by naming wait_for_condition and assert_condition and describing the difference in behavior. The purpose is unmistakable even before reading the schema.

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

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

The description provides explicit guidance on when to use this tool versus alternatives: 'Immediate boolean observation -> use check_if_condition', 'Wait for a state/content transition -> use wait_for_condition', 'Verify an expected condition -> use assert_condition'. It also lists other sibling tools such as find_elements and get_content for different needs, giving an agent clear routing rules.

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

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

Beyond the annotations, it discloses subtle runtime behavior: the priority order of selection modes, that all_matches cancels subsequent clicks if page navigation occurs, that only_if_visible does not wait for visibility, and the timeout/error handling behavior. This is exactly the kind of context an agent needs beyond readOnly/openWorld flags.

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 substantial, every section contributes: purpose, selection priority, per-argument detail, examples, error behavior, and anti-guidance. It is organized with clear headers and front-loaded with the core action.

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

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

Given the rich parameter set and no parameter documentation in the schema, the description covers selection modes, defaults, exclusions, error behavior, and example calls. The presence of an output schema means return-value documentation is already handled, so nothing essential 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?

With 0% schema coverage, the description carries the full parameter burden and does so thoroughly. It defines selector types, explains nth precedence and 1-based indexing, clarifies all_matches cancellation, notes timeout default and non-use in conditional/bulk modes, and documents parent_selector iframe support.

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

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

Description opens with a specific verb and resource: 'Click element(s) matching a CSS, XPath, or supported text selector.' It then enumerates the distinct click modes (nth, all matches, conditional, parent-scoped), which clearly separates it from sibling tools like hover_action or focus_element.

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 'When not to use' section explicitly routes hover-before-click scenarios to hover_action, and the description repeatedly states the intended use cases: normal, indexed, bulk, conditional, and parent-scoped clicks. This gives an agent clear decision rules.

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 concrete behavioral effects: the session is closed, persistent browser state ends, and resources are released. It lists specific affected state such as open tabs, cookies, navigation history, and page state. It explicitly confirms idempotent behavior, consistent with the idempotentHint annotation, without contradicting any annotation.

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: it states the core action in the first sentence, then gives usage context and safety confirmation. Every sentence contributes meaningful information without redundancy or filler.

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

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

For a zero-parameter tool with existing output schema, the description is fully sufficient. It covers the operation, the reason to call it, the consequence of closing, the alternative for subsequent sessions, and the no-op safety case. 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?

The tool has zero parameters, so there is no semantic ambiguity to resolve. Per the baseline guidance for no-parameter tools, a score of 4 is appropriate even though the description adds no parameter-specific details.

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 specific verb and resource: 'Close the active browser session and release browser resources.' This immediately differentiates it from sibling tools like start_browser, open_url, and manage_tabs. The scope is unambiguous.

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

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

The description explicitly says when to call it: 'Call this when the browser automation workflow is finished.' It also names the alternative for future work: 'If browser automation is needed afterward, start a new session with start_browser.' It even covers the edge case of calling with no active session.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral context beyond those: it clarifies the tool returns serializable dictionaries rather than live SeleniumBase objects, explains XPath conversion limitations that may reduce timeout effectiveness, and details error handling via @handle_sb_errors returning strings. No contradictions; this is complementary and rich.

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

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

The description is well-structured with clear sections (purpose, args, returns, tool selection, notes). It front-loads the core purpose and usage, then provides details. A few sentences could be tightened (e.g., the XPath explanation is slightly verbose), but overall every part earns its place. The length is justified by the need to cover alternatives 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?

Given the tool's moderate complexity (3 parameters, 1 required, 1 optional boolean, 1 optional numeric) and the presence of an output schema (mentioned via return structure), the description covers all essentials: return format, error cases, usage boundaries, and operational constraints like handle persistence. An agent can call this tool correctly without further research.

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

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

Schema coverage is 0%, so the description carries full responsibility for parameter meaning. It explains selector (CSS or XPath, with conversion caveats), timeout (max wait, behavior when XPath can't be converted), and include_html (what True/False returns). Each parameter gets concrete semantics that the schema itself lacks, fully compensating for the missing 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 opens with a clear verb and resource: 'Find matching elements and return structured element information.' It goes on to list concrete uses (count matches, inspect text/tag names, inspect HTML) and explicitly distinguishes itself from sibling tools by naming alternatives like get_content, click_element, and check_if_condition. This leaves no ambiguity about what the tool does and how it differs.

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 gives explicit when-to-use guidance for this tool versus get_content, click_element, and check_if_condition, with conditions for each. It also adds a critical usage note that element handles cannot be persisted across MCP calls, telling the agent to re-resolve elements. This is exemplary 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?

Beyond the annotations, the description discloses that the tool never activates the element, that highlight may affect timing and reduce stealth, and that timeout failures surface error details via @handle_sb_errors. This adds meaningful behavior context the structured metadata does not.

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

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

The description is front-loaded with the core purpose, followed by exclusions and parameter details. Every sentence earns its place; the length is justified by the need to document three action modes and clarify non-activation.

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 what the tool does, what it doesn't do, when to use alternatives, all parameter semantics, and error behavior. With an output schema present, no return-value explanation is required, making the definition complete for an agent to call the tool correctly.

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

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

Schema description coverage is 0%, so the description carries full responsibility for documenting parameters. It explains selector semantics, enumerates each action value with its effect, and defines timeout with its default, fully compensating for 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 opens with a specific verb-resource statement: 'Scroll to, focus, or highlight an element.' It then explicitly distinguishes itself from click/type/select/hover operations, which clearly separates it from related sibling tools.

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

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

The description explicitly states what the tool does NOT do and names the sibling tools to use for those cases: click_element, type_text, and hover_action. The action enum also gives concrete use cases for each mode, leaving no ambiguity about when to choose this tool.

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

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses important behavior: only the first matching element is used, the attribute parameter is optional and returns all attributes as a dictionary when omitted, and timeout/no-match behavior routes to @handle_sb_errors. This adds real operational context.

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

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

The description is front-loaded with the core purpose, followed by compact parameter explanations and a clear tool-selection list. Every sentence earns its place, and the structure makes it easy for an agent 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 3-parameter read tool with an output schema, the description covers the selector type, first-match behavior, attribute semantics, timeout default, and error handling. Nothing essential to invoking the 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%, so the description fully compensates. It explains selector as CSS or SeleniumBase-supported XPath, attribute as retrievable value or all attributes as a dictionary, and timeout with a default of 5 seconds. Every parameter receives meaningful semantic 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?

The description uses a specific verb and resource: 'get a specific HTML attribute (or all attributes) from the selected element.' It names concrete example attributes and is clearly differentiated from sibling tools like find_elements and get_content in the tool-selection section.

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 ('Need one or more HTML attribute values from a specific element -> use this tool') and when to use alternatives like find_elements, get_content, and check_if_condition. It also clarifies the first-match behavior for multiple elements, leaving little 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior, and the description adds meaningful behavioral details: it returns only visible text, normalizes discovered URLs to full URLs with protocol prefixes, and explains the timeout and error-handling path. There is no contradiction with 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 detailed yet tightly structured: purpose first, then parameters, then routing guidance, then error behavior. Every section earns its place and no sentences are wasted. The tool-selection list is slightly repetitive but adds practical 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?

Given the simple three-parameter surface, the description covers inputs, defaults, output format semantics, sibling-tool routing, and failure behavior. An output schema exists, so the exact return shape does not need to be described. Nothing important is missing 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 fully compensates. It explains each parameter, including what 'selector' accepts (CSS or SeleniumBase-supported XPath), the meaning of every output_format enum value, default behavior, and timeout semantics in seconds.

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 visible text, HTML, or discovered URLs from the selected element.' It clearly enumerates the output formats and differentiates from sibling tools via the tool-selection section, so an agent knows exactly what this tool produces.

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 tells the agent when to use get_content versus get_page_info, find_elements, check_if_condition, and wait_for_condition. It also documents the default 'body' selector and error behavior if no element matches, leaving little 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false. The description adds critical behavioral context: it explicitly states 'This operation does not navigate, reload, click, type, or otherwise modify the current page' and explains the edge case 'If no browser session is active, it returns {"running": False} instead of attempting to access a page.' This goes beyond the annotation flags and clarifies exact behavior when no session exists.

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

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

The description is well-structured: first sentence states purpose, then usage context, then return values, then tool selection, then edge-case behavior. It is front-loaded with the core purpose and each section earns its place. Despite length, it is organized with clear headers (Returns:, Tool selection:) making it easy for an agent 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?

Given zero parameters, the description fully explains the return dictionary fields (running, url, title, origin, user_agent) and the behavior when no session exists. It also covers the read-only nature and contrasts with siblings. With an output schema present (as indicated by 'Has output schema: true'), the description need not repeat all return details, but it still provides a concise summary. Complete for a metadata-fetching 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?

Tool has 0 parameters, so schema coverage is trivially 100%. Per rubric, 0 params baseline is 4. The description does not need to explain parameters since there are none. It does implicitly clarify that no arguments are required, but no additional semantics are needed.

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

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

The description states a specific verb and resource: 'Get current browser session and page metadata.' It explicitly lists the metadata types (URL, title, origin, user_agent) and contrasts with siblings by stating what it does NOT do (inspect content, find elements, check visibility). This distinguishes it clearly from get_content, find_elements, check_if_condition, etc., with no ambiguity.

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

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

Provides explicit 'Tool selection' rules: 'Need URL, title, origin, or User-Agent -> use get_page_info' and contrasts with alternatives like get_content, find_elements, check_if_condition, wait_for_condition, assert_condition. Also states primary use case: 'determining where the browser currently is after navigation, clicks, form submissions, redirects, reloads, or tab switches.' No ambiguity about when to call this tool.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses error behavior (exceptions are returned via @handle_sb_errors), timeout semantics for each action, and the fact that hover_and_click uses a separate internal wait not extended by the timeout parameter. These are exactly the behavioral details 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?

The description is well-structured with clear sections (intro, Args, Returns, Error behavior, When not to use) and every sentence provides necessary information. It is detailed without being redundant—no filler or repeated 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?

Given the tool's complexity (three distinct actions, conditional parameter requirements, timeout nuances), the description covers all operational aspects. It explains return values as a confirmation message, error paths, and explicitly names the sibling alternative. Even with an output schema present, the description is fully self-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 description coverage is 0%, so the description must compensate entirely. It fully explains each parameter: selector's role per action, secondary_selector's requirements for hover_and_click and drag_and_drop, the action enum values, and the timeout's conditional behavior. This adds substantial 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 opens with a specific verb-resource statement: 'Hover over an element, optionally click another, or drag-and-drop.' It clearly distinguishes this tool from the sibling 'click_element' by explicitly stating the hover prerequisite and naming the alternative in the 'When not to use' section.

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 states when to use the tool ('hover interactions, hover-triggered menus, and drag-and-drop operations') and when not to use it ('Do not use this tool to click if you don't need to hover... use click instead'). This gives the agent clear routing criteria relative to siblings.

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

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

Goes well beyond the annotations by disclosing that save can overwrite files, that load does not guarantee login restoration, that cookies may be expired or domain-restricted, and that cookie data may contain credentials. The security warning and per-action return behaviors add substantial context beyond openWorldHint and idempotentHint.

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-structured with clear sections for actions, returns, security, and notes. Each sentence earns its place, and the most important high-level purpose 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?

Complete for a two-parameter tool with no output schema. It covers all actions, parameter behavior, return types, file-overwrite risk, security concerns, and limitations of load. An agent has everything needed 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?

Schema description coverage is 0%, but the description fully compensates by explaining each enum value, defining the filename parameter's role for save/load, and noting it is ignored for get_all and clear. This adds meaning the schema alone does not 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?

States a clear verb and resource: 'Manage cookies for the current browser session' and enumerates the four concrete actions (inspect, clear, save, restore). This clearly differentiates it from sibling tools like manage_storage or manage_history.

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 explains when cookie management is useful: inspecting session state, preserving logins between runs, restoring sessions, and resetting website state. It does not explicitly name sibling alternatives or provide when-not-to-use guidance, but the context is clear enough for an agent.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that list is read-only, that reload ignores the cache, and that navigation actions can trigger page loads or redirects. It also advises verifying the resulting URL or title afterward, which is practical behavioral context.

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

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

The description is compact and front-loaded: a one-sentence purpose followed by labeled action semantics and a brief navigation-caveat. Every sentence earns its place, with no filler or repetition of schema facts that are already structural.

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

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

For a tool with a single optional enum parameter, an output schema, and actions fully documented, the description is complete. It covers what the tool operates on, each possible action, the read-only behavior, and cross-tool follow-up guidance.

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

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

Schema coverage is 0%, so the description must explain the parameters, and it does. Every enum value for 'action' is described with its behavioral effect, from back/forward/reload to the read-only list. This fully compensates for the schema's lack of 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 opens with a specific verb and resource: 'Manage or inspect the current browser tab's navigation history.' It clearly distinguishes the tool's scope from siblings like open_url and get_page_info by naming them explicitly, so an agent can tell exactly what this tool does.

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

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

The description gives explicit usage instructions for each action ('Use back, forward, or reload' vs 'Use list'), identifies the read-only variant, and points to alternatives for other needs ('Use open_url for navigation to an arbitrary URL', 'Use get_page_info afterward'). This is strong when-to-use 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains read vs. write behavior, return values for get and set, origin scoping, and security sensitivity of web storage, which is substantial 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 front-loaded with the core purpose and organized into clear sections: tool selection, exclusions, args, returns, security, and notes. It is relatively long, but every section earns its place by helping an agent select and invoke the tool correctly.

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

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

Given four parameters, no annotations, and no output schema, the description is complete enough for correct invocation. It covers parameter meanings, conditional requirements, return behavior, origin restrictions, and security considerations.

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 documents all four parameters: key, value, storage, and action. It also clarifies the conditional requirement that value is needed for set and explains the local vs. session storage enum values, going well 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 first sentence states a specific verb and resource: get or set a key in localStorage or sessionStorage. The tool-selection section explicitly differentiates it from manage_cookies, run_javascript, get_content, and get_attributes, so an agent can immediately 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?

The description provides explicit when-to-use guidance, a tool-selection list naming exact alternatives, and a when-not-to-use section with clear exclusions. It leaves no ambiguity about when this tool should be chosen over manage_cookies, run_javascript, or get_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 disclosure burden and delivers: tab indexes are session-relative and go stale after open/close, close_active_tab has a mandatory follow-up action, open_new_tab falls back to about:blank, and errors propagate via @handle_sb_errors. These are genuinely non-obvious behavioral traps an agent needs to know.

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 content is grouped into clear sections (Args, Notes, Error behavior) and front-loaded with the purpose statement. Every sentence earns its place given the tool handles five distinct actions with four parameters; the only blemish is a stray closing parenthesis in the tab_index entry.

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 action semantics, parameter applicability, defaults, sequencing constraints, index staleness, and error propagation, so an agent can correctly drive every action. It never states a prerequisite such as the browser session needing to be running (start_browser), and edge cases like switching with zero tabs are only handled by the generic error note.

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 every parameter is semantically documented: action gets per-enum-value behavior, url gets its default behavior, tab_index is scoped to switch_to_tab and sourced from list_tabs, and switch_to is tied to open_new_tab. The Args section fully compensates for the empty schema.

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

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

Opens with a specific verb+resource ('Manage browser tabs') and enumerates the concrete operations: listing, opening, switching, and closing tabs. It further sharpens scope by carving out in-tab navigation as belonging to open_url and manage_history, so an agent can distinguish it from the 22 siblings 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?

Gives an explicit boundary: use this tool for tab lifecycle operations and open_url/manage_history for navigation within the active tab. It also provides intra-tool routing ('Use this to find the tab_index for switch_to_tab') and a hard sequencing rule for close_active_tab that must be followed by a switch action.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds the key constraint that set_rect requires all four coordinates ('All four are required'), which is behavioral guidance beyond the schema. It also specifies the return for get_rect ('Return the current window position and size'). No contradiction with annotations; the description complements them.

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 (Args, Notes) and a bulleted list for actions. Every sentence serves a purpose: the action list, parameter explanations, and the routing note. 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?

The tool has 5 parameters but none are required at the schema level; the description explains that action defaults to get_rect and that the other parameters are for set_rect. The output schema exists, so return values are handled elsewhere. The description covers all input semantics, usage guidance, and sibling differentiation—nothing an agent needs 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 carry full parameter semantics. It explains each action value in detail and clarifies that x, y, width, and height are only relevant to set_rect. The 'All four are required' note prevents misuse. This fully compensates for the lack of schema-side 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 opens with a specific verb and resource: 'Get or change browser window geometry or state.' It immediately distinguishes itself from the sibling tool manage_tabs, and enumerates the four distinct actions (get_rect, set_rect, maximize, minimize) that map directly to the enum. An agent can clearly tell what this tool does and what it doesn't.

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 Notes section explicitly states when to use this tool ('Use this tool for browser-window geometry and state') and when to use the alternative ('Use manage_tabs for switching between browser tabs'). This direct routing to a sibling tool leaves no ambiguity about 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 several important behaviors beyond the annotations: automatic https:// prefixing, waiting for navigation to complete, the possibility that dynamic content may still load, and error propagation through @handle_sb_errors. These details materially help an agent predict what will happen during invocation and what to do about incomplete loading.

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 and front-loaded with the primary behavior, then provides examples, return details, and routing guidance in compact sections. Even the longer protocol-defaulting sentence earns its place because it changes how the parameter should be supplied. There is minimal redundancy given the amount of useful context.

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

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

With a single parameter and an output schema already present, the description covers everything an agent needs: parameter format, protocol normalization, navigation completion semantics, synchronization guidance, error behavior, return value, and explicit routing to sibling tools. No important invocation question is left 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?

The schema provides zero description for the url parameter, so the description carries the full burden. It fully compensates by defining the parameter in the Args section, explaining that it accepts either a complete URL or a bare hostname, and noting the automatic protocol prefixing behavior with a concrete example.

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, actionable statement: 'Navigate the current browser tab to the URL provided.' It clearly distinguishes open_url from manage_history by explicitly matching 'navigate to a new URL' to this tool and all history-based navigation to manage_history. The verb, resource, and behavioral scope are 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 'Tool selection' section explicitly states when to use open_url versus manage_history for back, forward, and reload actions. It also advises using wait_for_condition when synchronization with dynamic content is required, giving clear context about limitations and alternatives.

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

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

With no annotations, the description carries the full burden and meets it: it states evaluation via CDP Runtime.evaluate in the active page, access to DOM/storage, Promise resolution, serializable return values, and unrestricted page modification. The Security section also warns that execution bypasses higher-level abstractions.

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 headers, bullets, and examples, and the purpose is front-loaded. It is slightly long, and the 'Use this only...' sentence is repeated in stronger form in the Tool selection section, but the extra detail is mostly earned.

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 powerful one-parameter tool with no annotations and no output schema, this description covers when to use it, how execution works, parameter semantics, return serializability, and security considerations. Nothing the 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 coverage is 0%, so the description must compensate entirely. It explains what the expression may contain, provides five concrete examples, and clarifies Promise handling and the need to produce a value. This fully documents the only parameter.

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

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

The description opens with a specific verb and resource: 'Evaluate a JavaScript expression in the current page context.' It clearly frames the tool as an escape hatch for browser operations that higher-level tools do not expose, which distinguishes it from siblings like click_element, type_text, and get_content.

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 when-to-use rule ('Use this only when...') and a full Tool selection section recommending click_element, get_content, manage_storage, and manage_cookies first. This leaves no ambiguity about when the agent should pick run_javascript versus a sibling.

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

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

Annotations are sparse (only readOnlyHint=false, openWorldHint=false, idempotentHint=false), so the description carries the full burden. It discloses that the tool writes files, may overwrite, requires filesystem permissions, does not modify the page, does not upload/publish, and details error behavior. It also specifies prerequisites like an active browser session.

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

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

The description is well-organized with clear sections, bullet lists, and front-loaded purpose. Every sentence adds value—prerequisites, side effects, error handling, and alternatives—without redundancy. It is appropriately sized for the complexity of 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?

It covers prerequisites (browser session running), operational scope (does not navigate or modify), side effects (file write/overwrite), error handling, and return value. It also distinguishes from sibling tools. Given the output schema exists, the description needn't detail return structure, but it does anyway.

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 is the only source of parameter meaning. It explains each parameter (format with enum values and defaults, filename with format-dependent defaults, folder with default behavior) clearly and completely.

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 precise verb and resource: 'Save the current browser page to a local filesystem file' and enumerates the exact formats (screenshot, html, pdf). It also explicitly contrasts with siblings like get_content and get_page_info, making selection 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?

It states exactly when to use this tool ('when the browser workflow needs a persistent file artifact') and provides a dedicated 'When not to use' section naming three alternative tools with the conditions that route to them. This is explicit and actionable.

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

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

The description adds meaningful behavioral detail beyond the annotations: amount is a percentage of viewport height, values greater than 100 are allowed, and amount is ignored for 'top' and 'bottom' directions. The annotations are not contradicted, and the added semantics give the agent accurate expectations for how scrolling behaves.

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

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

The description is well-structured with clear sections for arguments, notes, and tool selection. Every sentence adds value, and the most important usage guidance is front-loaded near the bottom but easy to find. 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?

For a two-parameter tool with an output schema present, the description covers the behavioral semantics, special cases, allowed values, and selection guidance. An agent has everything it needs to invoke the tool correctly and know what to expect.

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 fully compensates by documenting each direction value and the exact meaning of amount with examples like amount=25 and amount=200. Even the nuance that top/bottom ignore amount is described, which the schema alone would 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?

The description opens with a specific verb and resource: 'Scroll the current page vertically.' It also names the sibling alternative (focus_element) for the element-revealing case, so an agent can tell which tool fits which task 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 'Tool selection' section explicitly states when to use scroll_page versus focus_element, including the precise action 'scroll_to_element' for focusing a specific element. It also clarifies that scroll_page is for relative page scrolling. This is clear, actionable guidance with an explicit alternative.

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

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

Beyond annotations, the description discloses that changing the selection can trigger additional events and that an error is raised when the dropdown or option is not found. This is consistent with readOnlyHint=false and gives agents useful expectations about side effects and failure modes.

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 purpose, followed by a concise event warning, structured Args definitions, an error note, and a sibling-routing note. Every sentence earns its place with no redundant 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 single-action select tool, the description covers the target element type, all parameters and their semantics, error behavior, side-effect warning, and alternative tools. The presence of an output schema means return values do not need explanation, so nothing essential 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?

With 0% schema description coverage, the description fully compensates: it defines dropdown_selector as a CSS selector, explains that value can be visible text, value attribute, or 0-based index depending on by, and details each by mode including integer/numeric-string acceptance for index.

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: 'Select an option from an HTML <select> dropdown.' It also differentiates from siblings by explicitly routing custom JavaScript dropdowns to click_element, making the tool's scope 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?

It explicitly states when to use the tool (native <select> elements) and when not to (custom div/button/list dropdowns), naming click_element and other element-interaction tools as alternatives. The warning about triggering page events adds practical usage context.

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

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

The description adds meaningful behavior beyond the annotations: it warns that success is not guaranteed, that page state and cookies may change, that the tool no-ops when no CAPTCHA is detected, and that the return value only confirms the attempt was initiated rather than succeeding. This complements the annotations instead of merely repeating them.

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

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

The description is longer than typical definitions, but every section earns its place: the supported widget list, workflow steps, risk disclosure, tool-selection guidance, and return-value clarification are each directly useful to an agent deciding whether and how to invoke the tool. The structure is front-loaded with the core purpose before details.

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 zero parameters and an output schema, this description fully covers what an agent needs to invoke the tool correctly: the preconditions, the exact supported CAPTCHA types, the post-call verification path, the side-effect behavior, and the meaning of the return value. 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?

The tool has zero parameters and the schema already provides 100% coverage, so there are no parameter semantics to explain. With no params, the baseline is 4; the description correctly avoids inventing arguments that do not exist.

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: it attempts a SeleniumBase CDP interaction to solve detectable CAPTCHAs on the current page. It lists supported widget types and explicitly contrasts itself with sibling tools, so an agent can distinguish solve_captcha from click_element and hover_action without ambiguity.

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

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

The workflow is explicit: inspect the page with get_content, call solve_captcha only when a CAPTCHA is present, and verify success through get_page_info, get_content, or manage_cookies. It also states when not to use it, directing the agent to click_element for standard visible elements and hover_action for hover-and-click reveals, making the routing decision explicit.

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

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

Beyond the annotations, the description discloses persistence across calls, CDP mode, automatic one retry on startup failure, reuse of cookies/tabs/history/localStorage/sessionStorage, and the fact that no second browser is launched if a session already exists. It also documents environment requirements. Nothing contradicts the annotations; idempotentHint is consistent with the already-running behavior.

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

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

The description is long but organized into labeled sections (Args, Returns, Startup behavior, Lifecycle, Environment requirements), with purpose and usage front-loaded before parameter details. Given 8 parameters and the need to explain lifecycle and session reuse, the length is warranted and every block adds 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?

The definition covers return values, startup retry behavior, lifecycle/session reuse, environment prerequisites, and all parameters, while the output schema handles the exact confirmation/error shape. For a complex setup tool with 8 optional parameters, this is complete and self-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 description coverage is 0%, so the Args block carries the full burden and succeeds: all 8 parameters are explained semantically, with defaults, examples, and a mutual-exclusion warning. It adds platform-specific headless defaults, use_chromium guidance for when Chrome is not installed, and proxy format examples. This fully compensates for the empty schema 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 first sentence names a specific action (launch) and a specific resource (persistent SeleniumBase Pure CDP Mode browser session), and the lifecycle note distinguishes it from sibling interaction tools by stating it must be called before them. The CDP-versus-WebDriver note removes ambiguity about what kind of browser session is created. This is clearly differentiated from the other browser tools in the sibling list.

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

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

The description explicitly says to call this before browser interaction tools such as open_url, get_content, click_element, type_text, and find_elements, and to call close_browser when finished. It also tells the agent what happens if a session is already running, covering the when-not-to-repeat case. No alternative startup tool exists among the siblings, so no further exclusion is needed.

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 goes well beyond the annotations by disclosing that the tool does not submit forms or click elements, that different modes clear or preserve existing values, that Enter keystrokes can be simulated, and that failures are routed through handle_sb_errors. These behavioral details add significant context beyond readOnlyHint, openWorldHint, and destructiveHint.

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 detailed and well-structured, with clear sections for modes, arguments, returns, notes, and tool selection. It is somewhat longer than strictly necessary because some sections, like Args and Returns, overlap with the schema and output schema, but the length is justified by the tool's complexity.

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

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

For a tool with four parameters, five interaction modes, error-handling behavior, and sibling tools, the description covers everything an agent needs to invoke it correctly: target, text, mode, timeout, side effects, and when to choose an alternative. No important calling information 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 carries the full burden of explaining parameters. It thoroughly explains selector, text (including being ignored for clear_only), all five mode enum values, and timeout semantics, adding critical meaning the bare schema lacks.

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

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

The description names a specific action set (enter, append, set, clear) and a specific resource (page element), and immediately distinguishes itself from siblings by stating it does not submit forms or click other elements. It also explicitly routes select-element updates to select_option, making the tool's scope unmistakable.

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 dedicated 'Tool selection' section explicitly says to use this tool for text-field updates and to use select_option for <select> elements. It also explains when each mode is appropriate, such as preferring 'set_value' for fast programmatic changes when keyboard events are not required.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds meaningful detail: the tool blocks, does not scroll/click/modify, handles timeouts through an error handler, and treats seconds_passed as a pure delay. This goes well beyond the structured annotations.

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

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

The description is long but well-organized into purpose, behavioral notes, parameter semantics, returns, and tool selection. It is front-loaded with the core purpose, and every section contributes needed information for 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?

Given the tool has 4 parameters, 5 enum states, no schema descriptions, and an output schema, the description covers all required cases: state meanings, argument dependencies, timeout behavior, error handling, and return values. Nothing needed for correct use 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 carries full responsibility for parameters. It thoroughly explains each state value, the selector requirement rule, text-search behavior, timeout semantics including the >= 0 constraint, and the equivalence of present/visible and absent/not_visible when text is supplied.

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 precise verb and resource: 'Wait for a page condition or for a specified duration.' It then explicitly differentiates itself from check_if_condition and assert_condition, so an agent can select it correctly without inspecting 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?

There is an explicit 'Tool selection' section mapping immediate inspection to check_if_condition, synchronization to wait_for_condition, and verification to assert_condition. It also clarifies when selector/text are required or ignored, leaving no ambiguity about when to use the tool.

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