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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it declares read-only verification, lists what it does not do (click, type, navigate, scroll, modify), explains blocking behavior for element/text checks vs immediate title/url checks, and states that failures become descriptive tool errors via handle_sb_errors.

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 front-loaded and structured into purpose, behavior, args, returns, and tool selection. It is slightly redundant because the sibling comparisons appear both in prose ('Unlike check_if_condition...') and again in the tool-selection bullets, but the length is largely justified by the tool's complexity and zero schema coverage.

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, zero schema description coverage, and an output schema, the description provides everything an agent needs: purpose, usage alternatives, parameter semantics, blocking behavior, and failure handling. Return value details are present as helpful context even though the output schema already defines them.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It enumerates every check value, explains selector requirements for element vs text checks, expected requirements per check type, exact matching only for text_visible, and timeout behavior including the >=0 constraint and that it is ignored for title/url assertions.

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: verify a browser condition and report failure as an error. It clearly distinguishes the tool from check_if_condition and wait_for_condition, so an agent can identify its role 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?

It explicitly says when to use this tool ('when an expected page state must be explicitly verified') and provides a dedicated tool-selection section contrasting it with check_if_condition and wait_for_condition. The conditions for choosing each alternative are fully specified.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the tool does not wait for elements, that missing elements return False rather than raising, and that errors return a string. It omits any note on permissions or rate/timing guarantees beyond the non-waiting statement, so it is strong but not exhaustive.

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

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

Well front-loaded with the purpose first and structured sections afterward, but the precedence rule ('check' is ignored when 'text' is provided) is stated twice, once in Args and again in Notes, which is redundant for the value delivered.

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

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

An output schema exists, so the 'Returns' text is a bonus rather than a necessity, and the description still covers the non-waiting semantics, error behavior, and precedence rules an agent needs. Nothing required 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, and it largely does: it defines the 'present'/'visible' enum meanings precisely and explains that 'text' takes precedence and causes 'check' to be ignored. It leaves the two schema defaults (check='visible', selector='body') unstated, which is the only gap.

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

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

States a specific verb and resource ('Check the current state of an element or text') with the distinguishing constraint 'without waiting for the condition to become true' front-loaded. An agent can separate it from wait_for_condition and assert_condition without opening any schema.

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

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

Provides an explicit tool-selection block naming each alternative (wait_for_condition, assert_condition, find_elements, get_content) alongside the condition that selects it. When-to-use and when-not-to-use are both spelled out, including the timing caveat.

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 it does well: it discloses that all_matches clicks are cancelled without exceptions if navigation occurs, that only_if_visible does not wait, that timeout is ignored by conditional/bulk modes, and that errors are routed through @handle_sb_errors. It doesn't explicitly state that clicks are destructive/irreversible, but for a click tool the mutation is self-evident and the navigation-cancellation caveat is valuable. A 4 is warranted; a 5 would require even more operational detail like exact exception types or side effects on page state.

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 every section earns its place: selection behavior, per-parameter semantics, examples, error behavior, and when-not-to-use. It is well-structured with headers and bullet-like formatting, and the most important scoping rule (nth precedence) is front-loaded. It loses one point only because the length is substantial and some parameter explanations could be tightened without losing clarity.

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

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

For a 7-parameter tool with no annotations and 0% schema coverage, the description is remarkably complete. It covers all parameters, precedence, error behavior, and exclusions, and provides five examples covering each mode. The output schema exists, so return-value documentation is not required. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must fully compensate, and it does. Every parameter (selector, nth, all_matches, only_if_visible, parent_selector, timeout, scroll) is explained with semantics, precedence, defaults, and constraints. It even warns that text-matching selectors are unsupported with all_matches=True. This is far beyond what the bare schema provides.

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: 'Click element(s) matching a CSS, XPath, or supported text selector.' It then enumerates the distinct click modes (normal, nth, all_matches, only_if_visible, parent-scoped), which clearly differentiates it from sibling tools like hover_action, focus_element, and select_option. The examples further cement what the 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 includes an explicit 'When not to use' section that names hover_action as the alternative for hover-then-click flows. It also gives clear selection-behavior precedence rules (nth > all_matches > only_if_visible > parent_selector > normal), so an agent knows exactly when to set which parameter. This is exemplary usage guidance.

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

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

With no annotations available, the description carries full behavioral disclosure. It states that the session's persistent state is ended, enumerating open tabs, cookies, navigation history, and page state, and confirms that calling it with no active session is safe.

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

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

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

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

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

For a no-parameter lifecycle tool, the description fully covers purpose, timing, state effects, fallback, and edge-case safety. Since an output schema exists, not detailing the return format is acceptable.

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

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

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

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

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

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

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

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

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

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

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

With no annotations, the description carries full burden and delivers: it warns that results are serializable dictionaries rather than live element objects, that handles cannot persist across MCP calls, that XPath 'contains(...)' selectors are unsupported and that timeout may be shortened for unconvertible XPath, and that errors are surfaced in the returned dict. These are non-obvious operational constraints an agent would otherwise learn only by failing.

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 structure is well front-loaded—purpose, then usage, then Args/Returns/Tool selection/Notes—so an agent can skim. It runs slightly long, with some overlap between the opening paragraph and the Args section, and the closing '@handle_sb_errors returns strings' note is internal-sounding boilerplate, but almost every 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?

For a 3-parameter tool with 0% schema coverage and no annotations, the description covers input semantics, return shape, error behavior, and the cross-call persistence limitation, so it is complete even though an output schema exists. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate and it does: selector (CSS or convertible XPath, with the conversion limitation called out), timeout (max wait for first match, plus the shortening caveat), and include_html (outer HTML vs. tag/text only) are each explained beyond their names and defaults. No parameter is left to guesswork.

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

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

The description opens with a specific verb+resource ('Find matching elements and return structured element information') and the Tool selection block explicitly differentiates it from get_content, click_element, and check_if_condition. An agent can identify the tool's niche without opening a schema.

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

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

It states concrete triggers ('discover how many elements match a selector, inspect their text/tag names, or inspect the HTML of multiple matches') and routes to named alternatives with their own conditions. When-to-use vs. when-to-use-something-else is fully covered.

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

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

No annotations are provided, so the description carries the full load and does well: it discloses that 'highlight' mutates the border color, that this may affect timing, and may reduce stealth — a meaningful side-effect warning. It also describes error behavior via @handle_sb_errors on timeout. It stops short of describing permission prerequisites or reversibility, but for a DOM attention operation this is strong disclosure.

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

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

Front-loaded purpose statement, followed by a tight exclusion sentence and a structured Args block. Slightly verbose with the dedicated non-activation paragraph, but every sentence conveys routing or parameter meaning.

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

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

Despite an output schema existing, the description still covers all three parameters, the side effect of highlight, and the timeout failure mode. For a 3-param tool with zero schema coverage, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate and it does: it explains each action enum value individually, defines selector as CSS/SeleniumBase, and specifies timeout units and default. This is materially richer than the bare schema titles.

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

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

States specific verbs (scroll to, focus, highlight) on a specific resource (an element), and explicitly distinguishes from siblings by naming click_element, type_text, and hover_action as the tools for activation. An agent can route correctly without opening any schema.

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

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

Explicitly states when NOT to use it (does not click, type, select, hover, or activate) and names the alternatives for those operations. The action enum values are also mapped to intent, giving the agent a clear decision path.

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

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

With no annotations, the description carries the burden and does most of it: it declares the operation read-only, documents the default 5s timeout wait, and explains the no-match path (exception surfaced via @handle_sb_errors). It does not say whether the element is scrolled into view or how attribute-name casing/normalization is handled, so it is strong but not exhaustive.

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

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

Front-loads the core behavior in the first sentence, then organizes parameters and tool-selection routing into clearly labeled blocks. Slight redundancy between the opening line and the Args section, but every block carries usable information rather than padding.

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

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

An output schema exists, so return values need not be enumerated, and the description still notes the dictionary shape when attribute is omitted. Combined with the timeout semantics and the documented error path, an agent has everything needed to call this correctly for a simple 3-parameter read tool.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: selector is defined as a CSS selector or SeleniumBase-supported XPath, attribute is explained with its omitted-behavior (return all attributes as a dictionary), and timeout is given a meaning plus its default. It stops short of edge cases like invalid selectors or case sensitivity.

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

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

States a precise verb and resource ('Read HTML attributes from the first matching element'), including the scoping detail that only the first match is used. That scoping is exactly what separates it from find_elements, so an agent can distinguish it 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?

Contains an explicit 'Tool selection' block that names the alternative tools (find_elements, get_content, check_if_condition) and the condition that routes to each. It also states the positive trigger ('need the value of a specific HTML attribute'). Both when-to-use and when-not are covered.

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

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

With no annotations, the description carries the full burden and adds meaningful behavior: it defines output_format semantics, notes URL normalization to full protocol-prefixed URLs, states the timeout default and its failure behavior, and mentions @handle_sb_errors exception handling. It does not cover authentication or rate limits, but for a read-oriented content tool this is strong disclosure.

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

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

The description is front-loaded with purpose, then structured into Args and Tool selection sections. Each sentence adds routing or parameter semantics, and the length is justified by the need to compensate for absent schema descriptions and annotations.

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

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

Given an output schema exists, the description need not explain return values, and it appropriately focuses on selection, parameters, and failure behavior. It fully covers what an agent needs to invoke the tool correctly despite no annotations and 0% schema description coverage.

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 fully. It documents all three parameters: selector syntax and default, timeout meaning and default, and each output_format enum value with its exact return behavior. It adds substantial meaning beyond the bare schema.

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

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

The description opens with a specific verb+resource: 'Read visible text, HTML, or discovered URLs from the selected element.' It explicitly distinguishes itself from metadata retrieval by naming get_page_info and other alternatives, so an agent can select it without opening the schema.

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

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

It provides an explicit 'Tool selection' routing list that maps five distinct needs to five sibling tools, including get_page_info, find_elements, check_if_condition, and wait_for_condition. This is unambiguous when-to-use guidance with named 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 does so thoroughly: it declares the operation READ-ONLY, enumerates what it does not do (inspect, find, check visibility, wait, assert, navigate, modify), and specifies fallback behavior (returns {'running': False} when no session is available). This goes well beyond the structured fields.

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 and organized with clear sections (purpose, usage, read-only disclaimer, returns, tool selection), but it is longer than necessary for a zero-parameter read. The 'Returns' list duplicates the output schema, and the final sentence repeats the read-only guarantee already stated earlier.

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 read operation, zero parameters, absence of annotations, and the presence of an output schema, the description is complete: it covers purpose, when to use, alternatives, safety profile, return value semantics, and fallback behavior. Nothing an agent needs to call it correctly is missing.

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

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

The tool takes zero parameters and schema description coverage is 100%, so there are no parameter semantics to clarify. The baseline for zero parameters is 4, which is appropriate here.

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') and explicitly differentiates itself from siblings like get_content, find_elements, check_if_condition, wait_for_condition, and assert_condition in the Tool selection section. An agent can immediately tell what this tool is for and why it exists.

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

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

It explicitly says when to use this tool ('after navigation, clicks, form submissions, redirects, reloads, or tab switches') and provides a clear routing table mapping other needs to their correct sibling tools. No ambiguity remains about alternatives.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It precisely explains the timing semantics for hover_and_click (including the separate short wait for secondary_selector), how timeout applies differently across actions, the two-step nature of drag_and_drop, and error behavior (exceptions propagated via @handle_sb_errors). This is thorough and preempts common 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 structured with clear sections (Args, Returns, Error behavior, When not to use) and front-loads the core purpose. Each sentence adds value—no filler or repetition. Despite its length, every part is essential to correct usage, making it appropriately concise for 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?

Given the tool's complexity (three actions with distinct selector roles), the description covers everything an agent needs: parameter meanings, action-specific behaviors, timeout semantics, error handling, and return format. It also explicitly calls out when not to use the tool. There is no missing information that would cause mis-invocation.

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

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

Schema coverage is 0%, so the description must fully compensate. It does so by explaining each parameter's role per action: selector's three context-dependent meanings, secondary_selector's conditions and exclusions, the action enum with descriptions, and timeout's per-action nuances. This exceeds what the schema provides and leaves no ambiguity.

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 statement of the tool's function: 'Hover over an element, optionally click another, or drag-and-drop.' It explicitly lists the three action variants and distinguishes itself from siblings like click_element and focus_element by focusing on hover interactions. The purpose is unambiguous and differentiates from alternatives.

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

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

The description provides explicit usage guidance for each action, including when to use hover_and_click and drag_and_drop. It also contains a 'When not to use' section that directs agents to use 'click' when no hover is needed, naming the alternative tool directly. This leaves no ambiguity about when to select 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, the description carries full responsibility for behavioral disclosure. It warns about filesystem access, potential file overwriting, privacy of cookie data, and the unreliability of restoring logins. It also clearly notes that cookies may be expired or domain-restricted, giving a transparent view of limitations.

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

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

The description is well-organized into sections (Description, Args, Returns, Security, Notes) and every sentence contributes essential information. It is detailed but not redundant, balancing thoroughness with clarity.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no annotations, the description carries the full burden and largely meets it: it warns that navigation actions can trigger page loads or redirects, that 'reload' bypasses the cache, that 'back'/'forward' only apply 'if available', and what 'list' returns. It does not mention whether history is per-tab vs session scoped or any failure mode when no history entry exists, so it falls short of a 5.

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

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

Front-loaded with the core purpose and a use-for routing sentence before the Args block, which is the right ordering. There is mild redundancy – 'reload' semantics are stated twice (summary line and Args entry) – but the extra lines are informative rather than 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-enum-parameter tool with an output schema already covering return values, the description covers everything an agent needs: action semantics, side effects, and the sibling to use for arbitrary URLs. Nothing material is left for the agent to infer.

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 supply parameter meaning, and it does: each enum value is documented with its effect ('reload' ignoring the cache, 'list' returning position and entries, back/forward conditional on availability). Only the default ('list') is not restated, which is minor given it is captured in the schema's default field.

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

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

States a specific verb (manage/inspect) and resource (current browser tab's navigation history), then enumerates the four actions it performs. It also names the sibling it is not (open_url) so the agent can disambiguate navigation-vs-history behavior without inspecting either schema.

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

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

Explicitly routes each action: 'back'/'forward' for history navigation, 'reload' for cache-bypassing refresh, 'list' to inspect history, and directs the agent to open_url for arbitrary URL navigation. It also tells the agent to call get_page_info afterward to verify the result, which is a concrete follow-up guideline.

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

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

With no annotations provided, the description carries the full burden and includes return behavior, security warnings about sensitive tokens, and origin scoping. It could more explicitly mention that setting a value overwrites an existing key, but the overall behavior is well disclosed.

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

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

The description is well-organized into purpose, selection guidance, parameter explanations, returns, security, and notes. Every section adds useful information, and the structure makes it easy to scan.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the destructive close_active_tab action and the requirement to follow it with a switch action, notes that tab indexes are session-relative and unstable, and documents the error-handling behavior through @handle_sb_errors. This goes well beyond the bare action list.

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 clearly organized with Args, Notes, and Error behavior sections. Every block adds practical information: action semantics, parameter constraints, session-relative index warnings, and exception propagation. The length is justified by the multi-action surface.

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 multi-action browser-tab tool with no annotations and an output schema present, the description alone covers all the essential semantics: what to use it for, what each action does, how parameters interact with actions, session-relative index caveats, and error behavior. An agent has enough to call it correctly.

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

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

The input schema has no per-parameter descriptions, but the tool description explains every parameter, including defaults, action-specific applicability, and the meaning of switch_to. For example, it says tab_index is only used by switch_to_tab and that url defaults to about:blank on open_new_tab. This fully compensates for the schema's 0% coverage.

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

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

The first sentence identifies a specific capability (managing browser tabs: list, open, switch, close) and explicitly contrasts with open_url and manage_history for navigation within the active tab. This lets an agent distinguish manage_tabs from 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?

It explicitly says when to use this tool ('listing, opening, switching, or closing tabs') and when to use alternatives ('open_url' and 'manage_history' for navigation within the active tab). It also gives procedural guidance, such as using list_tabs to obtain a current tab_index before switch_to_tab because indexes change.

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

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

With no annotations, the description carries the behavioral burden and mostly succeeds: it explains the read behavior of get_rect, the mutating behavior of set_rect with the all-four-required constraint, and the state changes for maximize/minimize. It stops short of a 5 because it does not address side effects such as persistence or reversibility of window state changes.

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 cleanly organized into an opening sentence, a compact Args list, and a short Notes block. Each line contributes necessary information, and the action list is scannable without unnecessary prose.

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

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

With an output schema present and all parameter semantics explained in the description, nothing critical is missing for invocation. The description also resolves the main contextual ambiguity by directing tab operations to manage_tabs.

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

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

Schema description coverage is 0%, but the description fully compensates by defining every parameter: the four action enum values with their effects, and x, y, width, and height scoped to set_rect with the required-parameter warning. This adds all the meaning the 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 opens with 'Get or change browser window geometry or state' – a specific verb and resource – then enumerates each action. It also distinguishes itself from manage_tabs by noting that manage_tabs handles tab switching, so an agent can select this tool confidently.

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 names the sibling alternative ('Use manage_tabs for switching between browser tabs'). This is direct routing guidance rather than implied usage.

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

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

No annotations are provided, so the description carries the full burden and does so well: it discloses automatic 'https://' prefixing for bare hostnames, that navigation blocks until the navigation operation completes, that dynamic content may still be loading (routing to wait_for_condition), and that errors propagate through @handle_sb_errors. These are exactly the behaviors an agent needs to sequence calls correctly.

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

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

Front-loaded with purpose, then behavior, then routing, which is a sensible order and every paragraph carries information. The 'Returns:' block is mildly redundant given an output schema exists, and the Args/Returns scaffolding adds a little length, but there is no padding prose.

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

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

For a one-parameter navigation tool, the description covers purpose, alternative routing, input normalization, timing/synchronization semantics, and error behavior. With an output schema present, the brief return note is sufficient; nothing needed to call this correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate and does: it explains that 'url' accepts either a complete URL such as 'https://example.com' or a bare hostname such as 'example.com', and what transformation occurs in the latter case. This is meaningfully more than the schema's bare string type.

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

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

Opens with a specific verb and resource: 'Navigate the current browser tab to the URL provided.' It explicitly distinguishes itself from history navigation, naming manage_history(action="back"/"forward"/"reload") as the alternative, so an agent can separate it from siblings without opening a schema.

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

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

The 'Tool selection' block gives explicit when-to-use and when-not-to-use routing: new URL -> open_url, back/forward/reload -> manage_history. The opening sentence also states the condition ('needs to visit a new URL rather than move through its existing back/forward history'). Nothing is left to inference.

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

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

No annotations are provided, so the description carries the full burden, and it does: it discloses the execution channel (CDP Runtime.evaluate in the active page), what the code can reach (DOM APIs, storage, same-origin resources), the escaping behavior for Promises, the return-serialization limits (DOM objects/functions/symbols may not cross the MCP boundary), and a security warning about unrestricted execution. That is a rich behavioral profile well beyond a restated name.

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

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

Front-loaded with the verb and the core selection rule, then cleanly sectioned into Tool selection, Args, Returns, and Security. It is longer than strictly necessary — the Security paragraph partially restates the bypass point already made in the opening and tool-selection sections — but every remaining sentence is actionable.

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

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

For a single-parameter arbitrary-execution tool with no output schema and no annotations, the definition covers purpose, routing, parameter shape, return serialization, and safety implications. There is nothing an agent needs in order to invoke it correctly that 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 compensate fully and does: it defines 'expression' as an evaluable expression or executable code referencing document/window, and supplies five concrete examples spanning reads, optional chaining, storage access, and a mutation, plus the Promise-return rule. This is more semantic detail than a schema would typically carry.

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 sentence states a specific verb and resource ('Evaluate a JavaScript expression in the current page context') and the body clarifies the execution mechanism (CDP Runtime.evaluate) and scope (active page). An agent can distinguish this from every sibling because the description names the exact capability the higher-level tools lack.

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

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

Explicit when-to-use ('only when the required browser operation cannot be accomplished through the higher-level SeleniumBase tools') plus a categorized list of alternatives (click_element/type_text for interaction, get_content/find_elements for reading, manage_storage, manage_cookies). The condition that selects this tool over each alternative is spelled out, not inferred.

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

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

No annotations exist, so the description carries the full burden and does so: it discloses filesystem writes, overwrite risk, trusted-path requirement, permission needs, no upload/publish behavior, prerequisite of a running session, and error behavior. This is unusually complete for a mutation tool with zero annotation coverage.

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

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

Well structured with front-loaded purpose and clearly labeled sections (Args, Side effects, Error behavior, When not to use, Returns). Slightly longer than strictly necessary, with some restatement in the error section, but every paragraph earns its place for a tool with no annotations.

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

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

Given zero annotation coverage, 0% schema description coverage, and mutation semantics, the description is complete: prerequisites, side effects, error handling, parameter behavior, and sibling routing are all covered. Output is a confirmation message, so the brief Returns note suffices even with an output schema present.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it defines the three format values, explains filename defaults per format, and clarifies that folder is passed to SeleniumBase with a stated default fallback.

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

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

Starts with a specific verb+resource ('Save the current browser page to a local filesystem file') and enumerates the three output formats. Clearly distinguished from read-only siblings like get_content and get_page_info.

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

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

Provides an explicit 'when to use' trigger (persistent file artifact needed) and a 'when not to use' section that names get_content, get_page_info, click_element, type_text, and select_option with the conditions that select each. Fully routable.

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?

Since annotations are absent, the description carries the full burden of behavioral disclosure. It explains how the scroll works (percentage of viewport height, directions, top/bottom ignoring amount, allowed values >100). It does not describe edge cases like page load state or iframes, but for a scrolling tool this is adequate. It adds value beyond the raw schema by explaining semantics.

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

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

The description is well-organized into sections (Args, Notes, Tool selection). Although it is moderately long, every section earns its place: args explain parameters, notes clarify behavior, and tool selection provides routing guidance. It is front-loaded with the core purpose and avoids 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 that an output schema exists, the description need not explain return values (and indeed does not). It covers the parameters thoroughly, provides usage guidelines, and discloses behavioral nuances. All information an agent needs to invoke the tool correctly and decide when to use it is present.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. It does so excellently: the 'direction' enum is explained with each value and its effect, and 'amount' is defined as a percentage of viewport height with a concrete example (25 = quarter). It also notes that amount is ignored for 'top' and 'bottom', and that values >100 are allowed. This completeness compensates fully for the absent 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 purpose: 'Scroll the current page vertically.' It specifies the verb (scroll), the resource (current page), and the direction of action (vertically). It also distinguishes itself from the sibling 'focus_element' by explicitly naming that alternative 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 provides explicit when-to-use and when-not-to-use guidance: 'Need to reveal a specific element -> use focus_element with action="scroll_to_element". Need to scroll the page by a relative amount -> use scroll_page.' This names the alternative and defines the selection criteria, leaving no ambiguity for the 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?

No annotations exist, so the description carries the full burden. It discloses the error behavior ('Raises: An error when the dropdown or requested option cannot be found'), which is valuable failure-mode information. However, it doesn't cover whether the selection triggers change events, whether it waits for options to load, or what the success response looks like (though an output schema exists, reducing that need).

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 Args and Raises sections, front-loaded purpose statement. The documentation is thorough but slightly verbose with the args restating what a schema normally covers; still, every sentence adds value given 0% schema coverage.

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

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

For a 3-param interaction tool with no annotations and 0% schema coverage, the description covers purpose, all parameter semantics, error behavior, and sibling routing. An output schema exists so return values needn't be explained. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 0%, so the description must fully compensate. It thoroughly documents the semantics of 'by' (text/value/index) and explains what 'value' means for each mode, including that both integer and numeric-string index values are accepted. This goes 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?

States a specific verb (select) and resource (option from an HTML <select> dropdown), and explicitly distinguishes this native-select tool from custom JS dropdowns. An agent can immediately tell it apart from click_element or hover_action.

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

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

Explicitly names the when-not condition ('This tool is for native <select> elements') and routes custom JS dropdowns to click_element or other element-interaction tools. This is the strongest possible sibling differentiation.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden and does so thoroughly. It honestly states that success is not guaranteed, that the return message is identical for success and failure, that the action may change page state or cookies, and that shadow DOM may prevent detection. It also explains the CDP mechanism and why it is stealthier.

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 every section earns its place: purpose, mechanism, behavior, workflow, and return-value caveat. It is front-loaded with the core purpose, uses clear section breaks, and contains no filler or repetition.

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

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

For a no-parameter tool with an output schema and no annotations, the description is fully self-sufficient. It explains when to invoke it, what will happen, what will not happen, and how to verify the outcome using sibling tools. Nothing essential for correct invocation is missing.

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

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

The input schema has zero parameters, so there is nothing for the description to explain beyond the schema. The description correctly focuses on behavior rather than arguments. This matches the baseline for parameter-free tools.

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: 'Attempt a SeleniumBase CDP-based CAPTCHA interaction,' and enumerates concrete interactions (checkbox click, slider drag/drop). It also names target providers (Cloudflare Turnstile, reCAPTCHA, hCaptcha, etc.), making the purpose unambiguous and clearly distinct from sibling browser automation 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 tool provides a numbered workflow that tells the agent when to inspect with get_content, when to call solve_captcha, and which sibling tools to use afterward to verify results. It also states that no click is attempted if no CAPTCHA is detected. However, it does not explicitly discuss when not to use this tool or why it should be preferred over click_element or run_javascript in CAPTCHA scenarios.

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

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

With no annotations, the description carries the full burden and does so richly: automatic single retry on launch failure, session persistence across calls (cookies, tabs, history, localStorage/sessionStorage), idempotent behavior when a session exists, OS-dependent headless default, and mutual-exclusivity constraints (guest vs incognito, browser_executable_path vs use_chromium). Environment requirements and fallback paths are also disclosed.

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

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

Well front-loaded — purpose and the call-ordering rule come first, then Args, Returns, Lifecycle, Environment. However, the Args block is verbose for a no-required-parameter tool, and the 'Returns' paragraph partially restates what the output schema already provides, adding length without new information.

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

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

For an 8-parameter, zero-required, no-annotation session-launch tool, nothing an agent needs is missing: sequencing, idempotency, retry behavior, mutual exclusions, environment prerequisites, and cleanup via close_browser are all covered, and return values are backed by an output schema.

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

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

Schema description coverage is 0%, so the description must compensate for all 8 parameters, and it does: it explains the null-vs-bool semantics of headless and its Linux/Windows/macOS default, gives proxy format examples ('SERVER:PORT', 'USER:PASS@SERVER:PORT'), states url triggers a wait for navigation, and documents two mutual-exclusivity constraints that the schema cannot express. This is meaning well beyond the bare 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?

Opens with a specific verb+resource: 'Launch a persistent SeleniumBase Pure CDP Mode browser session,' and immediately distinguishes itself from siblings by naming the interaction tools it must precede (open_url, get_content, click_element, type_text, find_elements) and the sibling that ends it (close_browser). An agent can route correctly without opening any schema.

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

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

Explicitly states when to call ('before using browser interaction tools'), the lifecycle boundary ('once at the beginning of a workflow'), the termination counterpart (close_browser), and the when-not case ('If a browser session is already running, this tool does not launch another browser'). Alternatives and exclusions are spelled out rather than implied.

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

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

With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It explains each mode's behavior—clearing, appending via keystrokes, typing without pauses, direct value setting without key events—and discloses timeout waiting and error handling via handle_sb_errors. This is rich behavioral context beyond what the schema could convey.

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

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

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

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

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

The tool is a moderately complex mutation operation with four parameters, no annotations, and zero schema-level descriptions. The description covers all parameters, all mode semantics, timeout behavior, error handling, and return values. Given the complexity, nothing an agent needs to invoke it correctly is missing.

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

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

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

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

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

The description opens with a specific verb phrase—'Enter, append, directly set, or clear a value on a page element'—and clearly scopes the tool to modifying text/value fields. It distinguishes itself from siblings by explicitly noting it does not submit forms or click other elements. An agent can tell this apart from click, run_javascript, and select_option without opening schemas.

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

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

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

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

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

With no annotations, the description carries the full burden and does so: it declares the call blocks, that it does not scroll/click/modify the page, and that a timeout surfaces as an error-handler failure rather than a success confirmation. It also flags the interaction rules between text, selector, and seconds_passed, which materially changes 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?

Front-loaded with the core behavior and organized under Args/Returns/Tool selection headings. It is longer than strictly necessary because the final 'Tool selection' block restates routing advice already given in the opening paragraphs, creating mild 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 blocking-wait tool with four parameters, an enum, and an output schema, the description covers side effects, failure semantics, parameter interdependencies, and sibling routing. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate and it does: it enumerates every state enum value with its meaning, states selector's requirement condition, explains that text makes present/visible and absent/not_visible equivalent, and gives timeout's dual meaning (max wait vs. exact duration).

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

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

States a specific action (block until a page condition or duration elapses) with clear scope, and explicitly distinguishes itself from the two nearest siblings, check_if_condition and assert_condition, by naming what each does instead. An agent can route correctly without opening any schema.

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

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

Gives explicit when-to-use ('synchronization when a dynamic page may need time to reach a condition') plus a three-way selection guide: inspect now -> check_if_condition, wait for change -> wait_for_condition, verify expectation -> assert_condition. Exclusions are stated, not inferred.

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