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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered externally. The description adds value beyond that by clarifying the first-matching-element behavior and by describing what happens when no element is found within the timeout via @handle_sb_errors. It also restates the read-only nature in a way consistent with the annotations, though this is somewhat redundant.

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 'Args' and 'Tool selection' sections and front-loads the main purpose. The read-only sentence is helpful but largely duplicates the annotations, and the prose could be slightly tightened without losing value. Overall it is appropriately sized 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?

For a 3-parameter read-only tool with an output schema and safety annotations, the description covers all necessary operational context: parameter semantics, first-match behavior, what happens on timeout, and which sibling tools to use instead. No critical gap remains 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 parameter meaning. It does so thoroughly: selector includes supported selector syntax, attribute explains the omitted-behavior returning a dictionary, and timeout gives its meaning and default. The examples and default values add meaning the schema 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?

The description opens with a precise action: 'Get a specific HTML attribute (or all attributes) from the first-matching element.' This clearly identifies the resource, the verb, and the first-match scoping, and the attribute examples make the domain concrete. It also distinguishes this tool from sibling tools by emphasizing attribute retrieval rather than text, content, or presence checks.

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 this tool versus find_elements, get_content, and check_if_condition. It gives concrete conditions such as 'Need one or more HTML attribute values' and 'Need to discover multiple matching elements or inspect their text,' so an agent is not left to infer the right choice.

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 valuable behavioral context beyond that: it specifies timeout wait behavior, URL normalization details, and the error-handling fallback via @handle_sb_errors when no element matches. This goes beyond what annotations provide, earning a 4.

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: initial summary, Args, Tool selection, and error note. While a bit long, each sentence earns its place—the tool selection list is genuinely useful, and the argument descriptions are concise. It is front-loaded with the core purpose, and the length is justified by the need to explain three output formats and sibling routing.

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 3 optional parameters, the description covers everything an agent needs: the exact purpose, all parameter semantics, defaults, output format behaviors, timeout, error handling, and clear guidance on when to use it versus siblings. Even if an output schema exists, the description explains the return types conceptually (visible text, html, urls) and the URL normalization behavior, ensuring complete understanding.

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 for parameter explanation. It describes 'selector' with type and default, 'output_format' with each enum value and its meaning, and 'timeout' with default and purpose. This fully compensates for the lack of schema descriptions and adds meaning far 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 'Read visible text, HTML, or discovered URLs from the selected element.' It specifies the verb (read), the resource (selected element), and the output types. It also explicitly contrasts with get_page_info, distinguishing page content versus metadata, which makes sibling differentiation clear.

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

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

The 'Tool selection' section provides explicit when-to-use guidance with a list mapping needs to specific tools (get_page_info, get_content, find_elements, etc.). It also states when to use this tool over metadata tools, leaving no ambiguity about when to select it.

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

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

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?

With no annotations, the description carries the full burden of behavioral disclosure. It warns about authentication credentials and private data, notes that save may overwrite files, explains that filename can access the MCP server's filesystem, and honestly caveats that loaded cookies may not restore a login. This is unusually transparent.

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

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

Well-structured with headings for Args, Returns, Security, and Notes, with the core purpose front-loaded. The length is justified because each section adds essential behavior not otherwise conveyed, given the minimal schema.

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

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

Complete for a 2-parameter tool with no annotations and no output schema. It covers per-action return values, filesystem risks, overwrite behavior, and the practical limitations of loading cookies. An agent has everything needed to invoke 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?

Despite 0% schema description coverage, the description fully compensates by explaining every action value and its effect, and by specifying that filename is only used by save/load and ignored for get_all/clear. The parameter meaning is unambiguous.

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 concrete resource and action set: 'Manage cookies for the current browser session' and enumerates four specific operations (inspect, clear, save, restore). The cookie focus clearly distinguishes it from sibling tools like manage_history and manage_storage.

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

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

Provides explicit use cases: inspecting session state, preserving login sessions, restoring saved sessions, and resetting website state. It does not explicitly contrast with alternatives or state when not to use the tool, so it falls just short of a 5.

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

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

With no annotations 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?

No annotations are provided, so the description carries the behavioral burden. It discloses the four actions and the requirement for set_rect, but it does not describe side effects, coordinate units, default action behavior, or return semantics beyond what the schema already shows.

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 an Args/Notes split, bullet-style action definitions, and no filler. The most important usage guidance is front-loaded, and each line earns its place.

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

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

Given no annotations and a 0% schema description coverage, the description covers the action matrix, parameter meanings, and the key constraint of set_rect. Minor gaps remain, such as coordinate interpretation and default action, but an output schema exists so return-value details are not necessary.

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

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

Schema description coverage is 0%, and the description compensates by explaining each parameter and enumerating the action enum. It adds the important rule that set_rect needs x, y, width, and height, though it slightly repeats information already inferable from the parameter names.

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, 'Get or change browser window geometry or state,' uses a specific verb and resource and clearly scopes the tool. The action list further enumerates the exact operations, making it easy to distinguish 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 Notes section explicitly directs the agent to use this tool for window geometry and state, and points to manage_tabs for switching tabs, which provides a clear alternative. It also states that set_rect requires all four coordinates, giving an explicit usage constraint.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds valuable context: it mentions that an error is raised when the dropdown or option cannot be found, and it explains the flexibility of the 'value' parameter. While it doesn't detail side effects like triggering change events, it provides enough behavioral transparency beyond the annotations. No contradiction 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 and concise. It starts with a clear purpose, then lists parameters in a readable format, followed by error behavior and a usage note. Every sentence serves a purpose, no fluff, and the information 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?

The tool has an output schema (though not shown, context signals indicate it exists), and the description covers all essential aspects: what the tool does, how to use each parameter, error behavior, and when to use alternatives. 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?

The input schema has 0% description coverage, so the description carries the full burden of parameter explanation. It thoroughly defines 'dropdown_selector', 'value' (including accepted types), and 'by' (with all three modes: text, value, index). This substantially adds meaning beyond the bare schema, fully compensating for the lack of 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 description clearly states the tool's function: 'Select an option from an HTML <select> dropdown.' It specifies the resource (native <select> elements) and explicitly distinguishes it from custom JavaScript dropdowns, naming the alternative (click_element). This makes the tool's purpose unambiguous and differentiates it from 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 provides explicit usage guidance: 'This tool is for native <select> elements. For custom JavaScript dropdowns made from div/button/list elements, use click_element or other element-interaction tools instead.' This directly tells the agent when to use this tool and when not, referencing a specific alternative, which is exemplary.

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 annotations by disclosing that success is not guaranteed, that the return message is identical for success and failure, that no click is attempted if no CAPTCHA is detected, and that page state or cookies may change. It also explains CDP stealth and shadow-DOM limitations. This is consistent with readOnlyHint=false and destructiveHint=false.

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 numbered workflow, provider list, limitation paragraph, and return note. However, the opening two sentences are somewhat redundant: both say the tool 'attempts' a CAPTCHA interaction. Slight trimming would make it tighter.

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

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

For a zero-parameter tool, the description supplies all essential context: target controls, mechanism, no-op behavior, success ambiguity, side effects, and post-inspection workflow. The return message caveat covers what the output schema would otherwise need to explain. 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?

There are zero parameters, so schema coverage is effectively 100% and the baseline is 4. The description adds that CAPTCHA coordinates are auto-detected and no user input is required. There is no parameter documentation gap to compensate for.

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 action and scope: 'Attempt a SeleniumBase CDP-based CAPTCHA interaction' and names concrete interaction types and providers. It also explains automatic coordinate detection, making the tool's role distinct from generic click_element or run_javascript. The purpose 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 gives a clear workflow: inspect with get_content first, call solve_captcha, then verify with get_page_info, get_content, check_if_condition, or manage_cookies. It does not explicitly state when not to use the tool or name a non-CAPTCHA alternative, so it stops short of full 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?

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?

Annotations already indicate readOnly=false and destructiveHint=false, but the description adds meaningful behavior beyond that: it waits up to timeout seconds, it clears existing values in some modes, it preserves in another, and it routes failures through handle_sb_errors. These details inform the agent about timing, side effects, and error flow, which annotations do not cover.

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

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

The description is longer than average but earned: five mutually exclusive modes require enumeration and disambiguation. It front-loads the core purpose, then logically progresses through behavior, mode selection, and arguments. Each bullet and sentence delivers distinct information with no filler or redundancy.

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

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

For a tool with four parameters, five modes, an output schema, and zero schema-level descriptions, the description covers all essential dimensions: what it does, which element types it supports, what it avoids doing, mode selection, error handling, and parameter semantics. It also states the return contract ('confirmation message... otherwise the error handler returns the resulting failure'), so an agent can interpret the response 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 the full explanatory burden. It explains selector ('CSS or SeleniumBase selector'), text ('Ignored for

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 specific verbs ('Enter, append, directly set, or clear') tied to a clear resource ('value on a page element'), and goes on to enumerate target element types ('inputs, textareas, contenteditable elements'). It explicitly states what the tool does not do ('does not submit a form or click other elements'), which differentiates it from siblings like click_element or select_option without opening their 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 guidance on when to use the tool ('modify text/value fields'), and breaks down mode selection with expected interaction semantics. It also gives an exclusion ('does not submit or click'), strongly implying click_element is for clicking. It stops short of naming alternative sibling tools explicitly, but the context and exclusions are clear enough for an agent to decide.

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.