SeleniumBase MCP

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. It clearly states that failed expectations raise an assertion-related SeleniumBase exception, that the MCP error wrapper converts it to a descriptive result, and that URL/title checks ignore the timeout. This gives the agent an accurate model of the tool's control flow and failure modes.

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

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

The description is well-organized with clear sections for purpose, arguments, return, exceptions, and tool selection. It is slightly redundant in places, such as repeating the verify-vs-wait distinction, but the structure makes the important information easy to find and the length is justified by the tool's complexity.

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

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

The description covers purpose, parameters, return value, exception behavior, timing caveats, and sibling-tool routing. Given the absence of annotations and complete lack of schema-level descriptions, this description alone is sufficient for an agent to select and invoke the tool correctly across all check types.

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 all five parameters. It does so comprehensively: each check enum value is described, expected is mapped to the relevant check types, selector is scoped to element/text checks, exact is explained for text_visible, and timeout's conditional applicability is called out.

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: verify an expected browser condition and fail when it is not met. It explicitly differentiates assert_condition from check_condition by noting that a failed expectation is treated as an error, not a boolean result.

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 tool-selection guidance: use check_condition for inspecting current state, wait_for for waiting on a condition, and assert_condition for verifying an expected condition. It also notes the important exception that URL/title checks do not wait for the timeout, giving agents a clear operational boundary.

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 fully carries behavioral disclosure. It states that the tool does not wait, returns True or False, treats missing elements as False rather than raising, and ignores check when text is provided. These details go far beyond a generic 'check condition' summary.

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 (Args, Returns, Tool selection, Notes) and the core purpose is front-loaded. However, it repeats 'check is ignored when text is provided' three times and restates the wait_for advice in multiple places, so it is slightly less concise than it could be.

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 or annotations, the description covers the return value, error behavior for missing elements, defaults for all parameters, parameter interactions, and sibling routing. An agent has everything needed to choose and invoke the tool correctly.

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

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

The schema has 0% description coverage, so the description must fully explain the parameters. It does: check defines both enum values and the default, selector defines the default and connection to text, and text explains precedence over check and the intended question it answers ('Is this text currently visible?').

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: 'Check the current state of an element or text without waiting' and frames itself as an 'immediate boolean observation.' It also explicitly differentiates from sibling tools by naming wait_for, assert_condition, find_elements, and get_content, 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?

The description gives direct when-to-use guidance ('Use this tool when you need an immediate boolean observation') and explicit alternatives: wait_for for conditions that may become true later, assert_condition for expected requirements, find_elements for counts/details, get_content for reading content. It also specifies when text should be used instead of element checks.

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 transparency burden. It discloses key behaviors: nth takes priority over all_matches, all_matches is ignored when nth is set, only_if_visible does not wait for visibility, and timeout defaults to 7 seconds. This is substantive, though it does not describe failure behavior or what happens when no element matches.

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 Tool selection sections. The Tool selection list somewhat recaps the Args details, but it serves as a useful decision aid. Overall, the description is appropriately sized for the complexity of the tool and information is 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?

Given an output schema exists, return-value details are not required. The description covers selector syntax, parameter precedence, timeout behavior, visibility handling, and parent scoping. It is nearly complete, but it omits behavior for zero matching elements and any potential side effects of clicking.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining every parameter in the Args section. The inclusion of a concrete selector example ('a:contains("Sign in")') adds valuable syntax guidance beyond the schema's bare property 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 a specific action ('Click one or more elements matching a selector') and identifies itself as the primary element-clicking tool. This clearly distinguishes it from sibling tools like hover_with_action and gives immediate clarity about its resource and scope.

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' section that maps use cases to parameter choices (basic click, nth, all_matches, only_if_visible, parent_selector). It does not explicitly contrast with sibling tools, but the guidance is concrete and actionable for choosing the right invocation mode.

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

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

With no annotations, the description carries the full burden, and it delivers. It discloses that closing ends persistent browser state, enumerates the destroyed state (tabs, cookies, navigation history, page state), and explicitly states it is safe to call when no session is active. This is strong behavioral disclosure for a teardown operation.

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 well-structured: an immediate behavioral statement, a clear usage condition, the side-effect disclosure, and the fallback action. Each sentence earns its place and the most important 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 is simple (zero parameters) and has an output schema, so the description need not explain return values. It fully covers what the tool does, when to use it, what state it destroys, and how it behaves in an edge 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 and the schema documents them trivially with 100% coverage. Since there are no parameters to describe, the baseline of 4 applies; the description appropriately spends no space on 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 states a clear verb-resource pair: 'Close the active browser session and release browser resources.' It is specific about the scope (the active session) and naturally distinguishes itself from the sibling start_browser without ambiguity.

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

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

It explicitly says when to call this tool: 'when the browser automation workflow is finished.' It also names the alternative for follow-up work: 'start a new session with start_browser.' It additionally clarifies the safe no-op case, leaving no doubt about when invocation is appropriate.

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 behavioral burden. It clearly discloses that element handles resolve immediately into JSON-like dictionaries rather than live SeleniumBase objects, that handles cannot persist across MCP calls, and that no matches yield an empty dictionary. These are non-obvious traits an agent must 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 description is front-loaded with a concrete purpose, then organizes content into Args, Returns, Tool selection, and Note. Each section adds distinct value—parameter details, return shape, alternatives, and a critical persistence caveat—without filler or redundancy.

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

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

The description is fully self-contained despite missing annotations and schema descriptions. It covers purpose, when to use, full parameter semantics, return structure including the empty-dictionary edge case, behavioral caveats, and sibling routing. Nothing an agent needs to correctly select and invoke the tool is absent.

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

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

Schema description coverage is 0%, but the description fully compensates. It explains selector syntax with concrete examples, gives the timeout default and behavior, and describes exactly how include_html alters the output. Every parameter is meaningfully defined beyond its name and 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?

The first sentence states a specific verb (find) and resource (matching elements) with a clear outcome (structured element information). The Tool selection section explicitly distinguishes it from get_content, click, and check_condition, so an agent can immediately tell which tool to use.

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 lists when to use find_elements (counting matches, inspecting text/tag names, or HTML of multiple matches) and routes to alternatives for other needs. This leaves no ambiguity about when to prefer another 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?

With no annotations, the description carries the full burden. It discloses the side effects of highlighting ('can affect timing and may reduce stealth'), the default scroll behavior, and explicitly states that it does not activate the element. This is comprehensive behavioral 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 well-structured with clear sections (overview, purpose, args, tool selection). Every sentence carries value and there is no filler. The organization makes it easy for an agent to parse quickly.

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, when, how, and the behavioral consequences. The output schema is present, so return values do not need description. The tool selection guidance provides full contextual completeness for correct invocation.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining the 'selector' parameter and providing a detailed explanation of each enum value for 'action', including the default. This 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 uses specific verbs ('Scroll to, focus, or highlight') tied to a clear resource ('an element') and explicitly lists what the tool does NOT do (click, type, select, hover). This sharply distinguishes it from sibling tools like click, type_text, and hover_with_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?

The dedicated 'Tool selection' section explicitly states when to use focus_on for each action and points to alternative tools for clicking, typing, and hovering. No inference is required.

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

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

With no annotations provided, the description carries the full burden. It clearly states the operation is read-only and does not modify the element, and it explains the two possible return shapes. It does not cover behavior for missing selectors or multiple matches, but the core behavioral profile is 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-structured with Args, Returns, and Tool selection sections, and the first sentence states the purpose immediately. It is longer than strictly necessary, but each section contributes practical information with only minor 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 simple read tool with no annotations or output schema, the description adequately covers parameters, return values, and tool selection. It falls short of a 5 by omitting error behavior for unmatched or missing elements and not clarifying multiple-match selector semantics.

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 document the parameters, and it does: selector is defined as a CSS selector or SeleniumBase text-matching selector, and attribute is described as optional with a default of returning all attributes as a dictionary. The phrase 'one or more HTML attributes' is slightly inconsistent with the singular attribute 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 clear verb and resource: 'Read HTML attributes from a matching element.' It names concrete attribute examples and distinguishes the tool from siblings like find_elements, get_content, and check_condition in the Tool selection section, so an agent can choose correctly.

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 ('Use this tool when you need the value of one or more HTML attributes') and provides a bulleted Tool selection section with alternatives and the conditions that route to them. This leaves little to inference.

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

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

With no annotations, the description fully carries the behavioral disclosure burden. It explains returned types per output_format, the effect of include_shadow_dom (and when it has no effect), and that URLs are returned as full URL strings. This is strong transparency, though it could also explicitly state that the operation is read-only and non-mutating.

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 efficiently organized with clear 'Args:', 'Returns:', and 'Tool selection:' sections. The opening sentence states the core purpose immediately, and every subsequent line adds necessary detail without redundancy.

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

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

Given the tool's moderate complexity, zero annotations, and complete parameter documentation in the description, it is fully self-contained. It covers what the tool returns, how parameters affect behavior, and how to choose between this and sibling tools. No critical information is missing for correct invocation.

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

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

Schema coverage is 0%, so the description must fully explain each parameter. It does so in detail: selector scoping behavior per format, the meaning of each output_format enum, and the exact conditions under which include_shadow_dom applies. No parameter is left ambiguous.

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: 'Read visible text, HTML, or discovered URLs from the current page.' It clearly distinguishes from siblings by naming alternative tools for different needs, such as get_page_info for metadata and find_elements for structured element 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?

A dedicated 'Tool selection' section explicitly lists when to use this tool versus alternatives like get_page_info, find_elements, check_condition, and wait_for. It also maps each output_format value to the appropriate use case, leaving no ambiguity.

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

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

With no annotations provided, the description carries the full burden, and it does so thoroughly. It labels the operation READ-ONLY, states what it does not do, explains the behavior when no browser session is active, and explicitly says it does not navigate, reload, click, type, or modify the page.

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

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

Although the description is long, it is organized into clear sections with front-loaded purpose, a structured return specification, and an explicit tool-selection guide. Each sentence adds necessary guidance, especially given the large sibling set and absence of 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?

The description fully covers what the tool returns, what it does not do, when to use it, and how it behaves without an active browser session. Given the simple parameterless signature and rich output schema, nothing essential is missing for an agent to select and 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 tool has zero parameters and an empty input schema, so there is no parameter ambiguity. The description adds value by clearly documenting the returned dictionary keys and their meanings, which is the relevant semantic content for a parameterless metadata tool.

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

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

The description opens with a specific verb and resource: 'Get current browser session and page metadata.' It explicitly positions itself as the primary tool for determining the current browser location after navigation, clicks, or tab switches, and distinguishes itself from content, element, and condition-checking 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 'Tool selection' section gives direct, condition-based routing: 'Need URL, title, origin, or User-Agent -> use get_page_info' and maps each alternative need to a specific sibling tool. This leaves no ambiguity about when to use this tool versus find_elements, get_content, check_condition, wait_for, or assert_condition.

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

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

No annotations are provided, so the description carries the burden. It clearly states what each action does and what the return is. It doesn't address side-effect caveats such as page navigation or visibility requirements, but the core behavior is 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?

The description is front-loaded with the summary and well organized into Args, Returns, Tool selection, and Notes. It is slightly repetitive because Notes restates selector roles already covered in Args, but the structure is scannable and easy to follow.

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 all parameters, all three action branches, selection guidance, and return behavior, so an agent can call it correctly in most cases. Minor gaps are the lack of stated preconditions such as an active browser session and no explicit exclusion for simple clicks, but these are not blocking.

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

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

The schema has zero parameter descriptions, but the description compensates fully by explaining selector1's role per action, selector2's requirement and nullability per action, and the exact meaning of every action enum value. This is thorough and directly actionable.

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 the exact operations: hover, optional click, and drag-and-drop, and explicitly names hover-triggered menus as a key use case. This clearly differentiates it from siblings like click, focus_on, and scroll.

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 a dedicated 'Tool selection' section that maps each action value to a scenario, and says to use the tool for hover interactions, hover-triggered menus, and drag-and-drop. It does not explicitly mention when to use sibling tools instead, but the intended usage is clear enough.

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 itself discloses key behaviors: clearing deletes 'all cookies', saving may overwrite existing files, loading does not guarantee login restoration, and cookie data may contain sensitive credentials. This is strong behavioral transparency.

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

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

The description is detailed but well structured into Args, Returns, Security, and Notes sections. Every section provides useful information, though the Returns section partially repeats action semantics already covered in Args.

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 two parameters and no output schema, the description covers all necessary operational details: action outcomes, return descriptions, filename behavior, security considerations, and limitations of loading cookies. Nothing critical is missing.

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

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

The schema has 0% description coverage, and the description fully compensates by explaining each action value and the filename parameter, including its default value and when it is ignored. This gives the agent complete parameter meaning.

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 that the tool is for managing browser cookies and enumerates specific actions: inspect, clear, save, restore. This distinguishes it from sibling tools like manage_storage by focusing specifically on cookies.

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 practical use cases such as preserving login sessions, restoring sessions, and resetting website state during testing. It does not explicitly mention alternatives or when not to use this tool, but the context is clear enough for correct selection.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that 'back' and 'forward' have no useful effect at history boundaries, that 'reload' ignores the browser cache, and that operations can trigger page loads, redirects, and navigation events. It also explains the return behavior for each action and recommends verification via 'get_page_info'.

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: action semantics, return values, side-effect warnings, and tool selection guidance. It is well-organized with clear headings and front-loaded purpose, avoiding redundant filler.

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

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

The description is fully complete for a tool with one parameter and an output schema. It covers all actions, return semantics, side effects, boundary behavior, and when to use alternative tools, leaving no significant gap for an agent deciding whether and how to invoke it.

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 the single parameter. It does, with a detailed breakdown of each enum value: 'back', 'forward', 'reload', and 'list'. The description adds meaning beyond the bare enum, including effect, boundary behavior, cache handling, and return format.

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, specific statement: 'Navigate through the current browser history, reload the current page, or list the current browser history.' It also distinguishes itself from the 'navigate' tool by explicitly stating that 'navigate' is for arbitrary URLs, making the tool's scope unambiguous.

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

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

The description provides an explicit 'Tool selection' section with clear routing rules: arbitrary URL -> navigate, previous/next history entry -> this tool, refresh -> reload, list -> list. It also advises using 'get_page_info' afterward to verify the resulting URL or title, giving concrete post-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?

With no annotations provided, the description carres the full burden and does so thoroughly: it explains get vs set behavior, the return values, storage origin scoping, and security implications around auth tokens and session identifiers. It also notes that storage is per-origin, which is crucial 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?

Information is well-organized under clear headings and the core purpose is front-loaded. There is some repetition about storage being origin-scoped and about not using run_javascript for arbitrary JavaScript, but it remains concise enough for an agent to parse.

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 purpose, selection, parameters, returns, and security, which is strong for a tool with no annotations and no output schema. A minor gap is that setting a null value is not explained, and the persistence distinction between local and session storage is only implied by their names.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining every argument: key, value, storage, and action. It even clarifies the conditional requirement that value is required when action='set', which the schema alone does not express.

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 'Get or set a key in localStorage or sessionStorage' names a specific verb, a concrete resource, and the storage type. It also distinguishes the tool from siblings by explicitly scoping it to Web Storage, not cookies, content, or JavaScript execution.

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

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

The description provides an explicit tool-selection section listing when to use this tool versus manage_cookies, run_javascript, get_content, and get_attributes. It also gives clear 'When not to use' exclusions, making the selection decision unambiguous.

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 explains what 'list' returns, what each action does, and warns that tab indexes are session-scoped and may change after tabs are opened or closed. It also notes that other browser actions may open new tabs, which helps the agent plan its calls.

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 clear opening summary, a usage boundary, an action breakdown, and a notes section. Every sentence adds necessary information, and the structure makes it easy for an agent to scan the action options and associated parameters.

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 multi-action nature and conditional parameters, the description is complete: it covers all four parameters, all five actions, return contents for list, the relationship between list and switch, and important caveats about tab index stability. The sibling-tool boundary is also explicitly drawn, so an agent can confidently select this 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 fully explain parameters. It does: action is detailed with each enum value's behavior, url is tied to 'open', tab_index is tied to list results for 'switch', and switch_to is explicitly described. 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: 'List, open, switch between, or close browser tabs.' It clearly defines the tool's scope and distinguishes it from navigate/manage_history, which manage navigation within the current tab rather than tab-level operations.

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 that tab management belongs here and that browser navigation within the current tab belongs to navigate and manage_history. It also advises calling action='list' before 'switch' to determine tab_index, giving concrete 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?

With no annotations provided, the description must disclose behavior itself, and it mostly does. It explains that get_rect returns coordinates and size, set_rect sets all four geometry values, and maximize/minimize change state. The main gaps are lack of detail on side effects, return format, and error behavior, which keeps it from 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?

The description is front-loaded with its purpose, followed by a compact bulleted list of actions and parameters. Every sentence contributes useful information, and the routing note is placed at the end without disrupting the core usage details.

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

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

The description covers all five parameters, every action, the set_rect requirement, and sibling routing, which is enough for correct selection and basic invocation. It does not mention prerequisites like a running browser, return shapes, or how maximize/minimize interact with get_rect, so it is not fully complete.

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

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

The schema has 0% parameter description coverage, so the description carries the full load. It defines each parameter ('Horizontal screen position for set_rect'), explains every action enum value, and adds the crucial constraint that all four geometry parameters are required for set_rect. It stops short of specifying units or coordinate-system details, so not a 5.

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

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

The description opens with a clear verb+resource: 'Get or change browser window geometry and state.' It enumerates four concrete actions (get_rect, set_rect, maximize, minimize), making it obvious what the tool does. The closing sentence also explicitly differentiates it from the sibling tool manage_tabs.

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

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

The description explicitly says when to use it: 'Use this tool for browser-window geometry/state.' It also states when not to and names the alternative: 'For switching between browser tabs, use manage_tabs instead.' This is a clear when/when-not pattern with a specific 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?

With no annotations available, the description carries the full burden of behavioral disclosure. It reveals important behavior: automatic protocol prefixing, waiting for the initial HTML document, and that the page becomes part of browser history. It doesn't mention failure/timeout behavior, but the key execution traits are well covered.

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

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

The description is well-structured with clear sections (summary, behavior, Args, Returns, Tool selection). Every sentence adds value, and the most important usage distinction is front-loaded. It is detailed without being redundant.

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

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

For a single-parameter tool with no annotations and an output schema, this description is complete: it covers purpose, when to use it, parameter semantics, key behavioral quirks, return value, and alternatives. Nothing crucial is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, but the description fully compensates with an explicit Args section explaining that url may be a complete URL or a bare hostname, with examples. It also explains the URL normalization behavior, so the agent understands how the parameter is interpreted.

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-resource pair: 'Navigate the current browser tab to a URL.' It clearly distinguishes itself from history-related operations like back/forward/reload by naming the alternative tool (manage_history) and the exact condition for choosing navigate ('Go to a new URL').

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 navigate (new URL) versus manage_history actions for back, forward, and reload. The opening also contrasts navigate with 'its existing back/forward history,' providing a clear decision boundary 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?

Even though no annotations are provided, the description discloses execution via Chrome DevTools Protocol Runtime.evaluate, access to the page's JavaScript context, Promises support, serialization limitations for return values, and unrestricted security implications. It clearly states that this tool can read or modify page data and bypass higher-level abstractions, giving the agent a complete behavioral picture.

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: purpose, tool-selection guidance, argument semantics, return behavior, and security warning. It is well-structured with clear headers and front-loaded with the core usage constraint. No filler or redundant marketing language is present.

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 high complexity, minimal schema, no annotations, and no output schema, the description is remarkably complete. It covers execution context, supported input forms, return serialization, Promise resolution, and security risk. An agent has enough information to decide when to invoke it and to craft a correct expression.

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 only provides the parameter name 'expression' with zero description coverage, so the description carries the full burden. It thoroughly explains what the expression may reference, gives multiple concrete examples, notes that Promises are supported, and clarifies that the expression should produce a serializable value when a result is needed. This far exceeds what the schema alone 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 clearly states a specific verb and resource: 'Evaluate a JavaScript expression in the current page context.' It also distinguishes itself from the higher-level sibling tools by framing itself as the low-level arbitrary-JavaScript fallback. This makes its purpose unambiguous and differentiable.

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

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

The description explicitly says to use this only when higher-level SeleniumBase tools cannot accomplish the operation. It then lists preferred tools for specific categories such as click, type_text, get_content, manage_storage, and manage_cookies, and finally states the condition for using this tool. This is exemplary 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses potentially destructive behavior ('Existing files may be overwritten') and filesystem security implications ('filename and folder can affect filesystem paths available to the MCP server'), which is meaningful beyond the schema. It also documents the return value as a confirmation containing format and filename.

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, args, returns, and security. It is front-loaded with the core action, and every section contributes useful 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 tool with three optional parameters and an output schema, the description covers purpose, parameter semantics, return value, and security caveats. Nothing an agent needs to decide whether and how to call this tool 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 thoroughly. It explains each parameter, enumerates valid format values with their output types, and clarifies that the filename default changes based on format (screenshot.png, page_source.html, or page.pdf). This adds meaning entirely 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 and resource: 'Save the current browser page as a screenshot, HTML file, or PDF.' It clearly distinguishes the tool's artifact-saving purpose from sibling tools like get_content or check_state by emphasizing persistence rather than inspection.

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

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

The description explicitly states when to use the tool: 'when an automation workflow needs a persistent artifact from the current page, such as a screenshot for debugging, page source for inspection, or a PDF representation.' It provides clear context, though it does not name alternatives or situations when the 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 behavioral burden. It thoroughly explains direction semantics, the meaning of amount as a percentage of viewport height, and notes that amount is ignored for 'top' and 'bottom'. However, it does not mention edge cases such as bounds, invalid amounts, or behavior when the page cannot scroll further.

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: a one-line purpose, a compact argument list, and a final routing note. Every sentence adds value, and the most important scoping information appears first. There is no redundant or filler content.

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, the description covers the action, all parameter semantics, special cases, and the relevant sibling alternative. An output schema is present, so return-value documentation is not required. An agent has enough context to use this 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?

The input schema has 0% description coverage, so the description must compensate. It fully explains both parameters: each 'direction' value is defined, and 'amount' is described as a percentage of viewport height with a concrete example. This exceeds the schema's bare enum/default information.

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 further differentiates itself from the sibling tool by explaining that focus_on(action="scroll_to_element") is for revealing a specific element, whereas this tool handles page scrolling.

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

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

The description explicitly states when to prefer an alternative: 'Use focus_on(action="scroll_to_element") when the goal is to reveal a specific element rather than scroll the page by a relative amount.' This gives clear, actionable routing guidance with no ambiguity.

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

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

With no annotations provided, the description takes on the burden of explaining behavior. It does this well by describing how matching works for each 'by' mode, noting that numeric-string indices are accepted, and stating that an error is raised when the dropdown or option cannot be found. It could go further by mentioning side effects or state changes, but the core behavioral contract is clearly 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 an opening sentence, Args section, Raises note, and an explicit usage boundary. Every sentence adds necessary information, and the most important purpose statement 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?

Given the tool's moderate complexity, the description covers the full set of parameters, matching semantics, error behavior, and the critical native-vs-custom dropdown distinction. An output schema is present, so the description does not need to explain return values, and the provided context is sufficient 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?

The schema provides no parameter descriptions, so the description fully compensates. It explains dropdown_selector as identifying the select element, value as visible text/value attribute/0-based index depending on 'by', and each 'by' enum value in detail. This goes well beyond what the raw schema conveys.

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 action with a specific verb and resource: 'Select an option from an HTML <select> dropdown.' It also distinguishes itself from sibling tools by explicitly limiting its applicability to native select elements, avoiding confusion with click or fill_input.

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

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

The description explicitly states when this tool should be used: for native <select> elements. It also provides an alternative for custom JavaScript dropdowns: 'use click or other element-interaction tools instead.' This is clear, actionable guidance for choosing between this tool and its 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?

No annotations are provided, so the description fully carries the burden of behavioral disclosure. It clearly states the tool does not guarantee a solved CAPTCHA, that controls may be shadow-DOM embedded, and that successful attempts may change page state or cookies. It also clarifies what the return message does and does not mean.

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 a simple one-liner, but the extra length is justified by the tool's non-deterministic behavior and the need to set expectations. The main purpose is stated first, followed by a clear workflow and return semantics, with no filler.

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

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

For a zero-parameter tool with an output schema, the description is nearly complete. It explains what the tool attempts, its limitations, side effects, and the recommended surrounding workflow. Minor missing details like timeout or wait behavior are not critical for invoking 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 tool has zero parameters, so the baseline is 4 and there is no parameter ambiguity. The description correctly focuses on behavior and workflow instead, which adds value beyond 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?

The description states a specific verb and resource: it 'attempts to interact with CAPTCHA controls' via SeleniumBase CDP interaction. It names concrete CAPTCHA types, making the tool's scope clear and distinguishing it from page-inspection and navigation 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 an explicit workflow: inspect with get_content first, call solve_captcha, then verify state with get_page_info or check_condition. It does not explicitly state when not to use the tool, but the workflow and limitations imply the intended usage context.

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

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

No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It clearly reveals that the session is persistent across tool calls, maintains browser state (cookies, tabs, history, storage), and runs until close_browser is called or the server exits. It explains the CDP-based communication versus WebDriver, the OS-dependent headless default, and the availability of fallbacks like use_chromium and browser_executable_path when the browser cannot be found.

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 the average MCP description, but the added length is purposeful: each block (Args, Returns, Lifecycle, Environment requirements) adds non-redundant integration-level detail. It could be slightly tightened by folding the OS-specific headless rules into one mention instead of repeating them in the Args and Environment sections; this repetition costs it a perfect score.

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-annotation tool with no schema-level descriptions, the description is highly complete. It specifies every parameter, returns a structured message (confirmation or error), gives lifecycle guidance, and enumerates environment prerequisites. It leaves nothing essential about how or when to call this tool, and the output schema covers the return payload.

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 schema description coverage at 0%, the description fully compensates by explaining not only what each of the 8 parameters does (open a URL, control headless mode, choose Chromium, specify an executable path, incognito, guest, ad-block, and proxy) but also the mutual exclusivity constraints (browser_executable_path not with use_chromium, and guest not with incognito). Real included conventions for proxy format and default headless behavior per OS, making each parameter actionable.

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 immediately states the core function with a specific verb and resource: 'Launch a persistent SeleniumBase Pure CDP Mode browser session.' It goes beyond a generic launch description by naming the browser-control layer (Pure CDP Mode) and explicitly positioning itself as the prerequisite for interaction tools like navigate, click, and type_text, which clearly differentiates it from those 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 strong usage context: it must be called before browser interaction tools, should be called once at the start of a workflow, and close_browser should be called when finished. It also explains the session remains available across calls. However, it does not explicitly outline scenarios where starting a browser is not appropriate or compare itself to a non-browser alternative, leaving room for an explicit when-not-to-use statement.

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 behavioral weight and handles it well. It discloses that set_value bypasses normal key events, that clear_only ignores text, that fill_input clears before typing, and that timeout caps wait time. This gives the agent accurate expectations for each mode.

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 organized with a purpose line, scoped usage, an Args list, and a Tool selection summary. Repetition between mode definitions and tool selection is purposeful, giving the agent both reference detail and decision guidance without fluff.

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 4 parameters, 5 enum modes, and no annotations, the description covers all necessary operational context. An output schema exists, so the lack of return-value detail is acceptable. It is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must explain all parameters, and it does. Selector, text, mode, and timeout are each described with their role, including mode-specific nuances like ignored text in clear_only and slider support for set_value.

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

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

The description opens with a precise verb set and resource: 'Fill, append, fast-type, directly set, or clear a form control,' then scopes it to input, textarea, and contenteditable elements. This clearly differentiates type_text from sibling tools like click, select_option, 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?

The 'Tool selection' section explicitly maps each intended user goal to a specific mode, which is strong usage guidance. It also states the tool is for form controls, though it does not explicitly name sibling alternatives to avoid.

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 disclosure burden. It explains that the tool intentionally waits, is for synchronization rather than validation, and clarifies how 'text' alters the meaning of 'present'/'visible' and 'absent'/'not_visible'. It does not discuss polling behavior or error handling, but the core behavior is clearly 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 organized with clear sections (intro, Args, Returns, Tool selection) and front-loads the core purpose. However, the text/state caveat is nearly identical in the intro and in the 'text' parameter explanation, making it slightly redundant. Still, no irrelevant content is present.

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, the description comprehensively covers purpose, when to use it, all parameters, state semantics, and alternatives. An output schema exists, so return value details are not required, and the description even summarizes the return ('A confirmation'). Nothing critical is missing.

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

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

Schema coverage is 0%, so the description must fully document the parameters. It does: each state value is explained, selector's requirement is stated, text's special handling is detailed, and timeout's default is given. This adds far more meaning than the bare parameter names and enums in the schema.

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

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

The description states a specific verb and resource: it waits for an element or text to reach a requested state. It clearly distinguishes itself from sibling tools check_condition and assert_condition, so an agent can tell exactly which tool fits which purpose.

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?

Includes an explicit 'Use this tool when' statement about dynamic pages and waiting, plus a dedicated 'Tool selection' section that contrasts wait_for with check_condition and assert_condition. This gives the agent concrete selection criteria and exclusions.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly states that the tool blocks the MCP server and performs no browser action while waiting, which accurately conveys the side effect and limitation. It does not discuss edge cases like zero/negative values or cancellation, but the core 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 concise and front-loaded: the core behavior appears in the first sentence, followed by usage context, the alternative, and parameter details. Every sentence contributes meaningful guidance without redundancy.

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

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

For a low-complexity tool with one required parameter, the description covers what the tool does, when to avoid it, what alternative to prefer, and what the parameter means. Since an output schema exists, return-value explanation is not required. No critical information is missing.

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

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

Schema description coverage is 0%, so the description must explain the parameter. It adds meaning by stating that seconds is "Number of seconds to block" and clarifying that it may be an integer or float. It could explicitly state that the value must be non-negative, but the explanation is otherwise sufficient for this simple single-parameter tool.

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: "Block the MCP server for a fixed number of seconds." It clearly differentiates itself from the sibling wait_for by calling itself a low-level timing tool that performs no browser 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?

The description explicitly says when not to use it: "should not be used when waiting for a page condition." It also names the alternative, wait_for, and explains why wait_for is preferable for element/text conditions because it returns as soon as the condition is met.

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