seleniumbase-mcp
OfficialServer Quality Checklist
Latest release: v1.2.5
- Disambiguation5/5
Every tool has a distinct purpose, and similar tools (check_state, wait_for, assert_condition) are explicitly differentiated by their intended use. The lifecycle, navigation, inspection, and interaction categories are clearly separated with no ambiguous overlaps.
Naming Consistency4/5Most tools use a consistent verb_noun snake_case pattern (get_content, manage_tabs, save_output). Minor deviations like bare verbs (navigate, click, scroll) and the unusual hover_with_action and focus_on slightly break the pattern, but the overall style remains readable and predictable.
Tool Count3/5With 25 tools, the set sits at the heavy end of typical scope. While each tool serves a clear purpose, the count is inflated by fine-grained separation (e.g., check_state vs wait_for vs assert_condition, and four separate manage_* tools) rather than being a lean, tightly-curated set.
Completeness5/5The tool surface thoroughly covers the browser automation lifecycle: launching, navigation, history, element inspection, interaction, waiting, assertion, cookie/storage management, tabs, windows, scrolling, captchas, and output saving. Only niche features like alert handling or file upload are absent, but core workflows have no dead ends.
Average 4.7/5 across 25 of 25 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 126 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior4/5
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 important behaviors: only_if_visible does not wait for visibility, nth takes priority over all_matches, all_matches clicks visible matches in order, parent_selector support is conditional, and timeout defaults to 7 seconds. It does not describe failure behavior when no element matches, but the coverage is otherwise strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with an Args section and a Tool selection summary. Some information is repeated between these sections, but the repetition serves as a quick-reference and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, zero annotations, and no explanatory output schema, the description covers purpose, selector syntax, all parameters, defaults, precedence, visibility semantics, and scoping caveats. It is missing explicit edge-case behavior such as what happens when no element matches, but the overall guidance is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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. Every parameter is explained with meaningful semantics: nth's 1-based indexing and precedence, all_matches' visibility and ordering, only_if_visible's no-wait behavior, parent_selector's iframe/nested-container usefulness, timeout's default, and scroll's intent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: "Click one or more elements matching a selector," and declares itself "the primary element-clicking tool." It clearly identifies the tool's role among browser-interaction siblings and distinguishes supported selector syntax (CSS and SeleniumBase text-matching).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when an element click is needed, and it is labeled the primary click tool. The "Tool selection" section provides actionable recipes for different click scenarios, though it does not explicitly contrast the tool with alternatives like hover_with_action or find_elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly explains the three behavioral modes (hover-only, hover-then-click, drag-and-drop), the roles of both selectors for each mode, and the return value ('Description of the performed operation'). It does not explicitly caution that clicking or dragging may trigger page changes, but the described actions inherently imply those effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with a clear summary followed by args, tool selection, and notes. It is somewhat repetitive: the Notes section largely restates selector roles already covered in the Args and Tool selection sections. This adds minor bloat but does not obscure the information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three distinct modes and two interdependent selectors, the description is complete. It covers every action value, explains which selectors are needed for each mode, and states the return value. An agent has enough information to select the right action and populate the arguments correctly without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 fully compensate. It does: selector1 and selector2 are each explained per action mode, including which parameters are required, which are unused, and what roles they play. The action parameter's enum values are also fully defined. This is excellent parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, concrete statement of what the tool does: 'Hover over an element, optionally click another element, or drag-&-drop.' It clearly differentiates this from the sibling click tool by emphasizing hover interactions, hover-triggered menus, and drag-and-drop operations. The three explicit action modes leave no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool: 'Use this tool for hover interactions, hover-triggered menus, and drag-and-drop operations.' It also gives a 'Tool selection' section mapping each scenario to the correct action value. However, it does not explicitly address when not to use it or name alternatives like the sibling 'click' tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose read/write behavior, return shape, origin scoping, and sensitive-data security considerations. It does not explicitly mention side effects such as overwriting an existing key or how a null value is interpreted, which keeps this slightly below 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses clearly labeled sections, which helps an agent scan it quickly. There is minor redundancy between 'Tool selection' and 'When not to use' regarding cookies and arbitrary JavaScript, so it is well organized but not maximally tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple 4-parameter storage tool despite having no annotations and no output schema: it covers purpose, selection, arguments, return values, security, and origin scoping. The only missing details are edge behaviors such as null handling and overwrite semantics, which are peripheral but could matter in some workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the 'Args' section compensates by explain key, value, storage, and action, including the enum meanings and conditional value requirement for set. The semantics of a null value and the effect of setting an already-existing key are left to inference, so it is strong but not perfect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the exact operation ('Get or set') and the resource ('a key in localStorage or sessionStorage'), giving a specific verb+resource statement. The tool-selection list immediately distinguishes this tool from siblings like manage_cookies and run_javascript, so there is no ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'Tool selection' section and a 'When not to use' section, naming alternatives such as manage_cookies, run_javascript, get_content, and get_attributes with clear exclusion conditions. An agent can determine exactly when to invoke this tool versus sibling tools without needing to inspect their schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 clearly states that the tool does not intentionally wait, is for current-state checks only, and that text takes precedence over check. It could more explicitly state that a non-match returns False, but the 'boolean observation' phrasing and 'Return True when...' conditions make this largely clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then organizes usage guidance, arguments, and notes logically. It is slightly redundant because the note 'When text is provided, check is ignored' repeats the same statement from the parameter documentation, but every other sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean-observation tool with no output schema, the description covers parameters, return semantics, no-wait behavior, and sibling alternatives. It could be more complete by explicitly stating what happens when the selector matches no elements or by defining the returned value for the false case, but the coverage is strong overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains the check enum values ('present', 'visible') with return conditions, describes selector as a CSS or SeleniumBase selector defaulting to 'body', and clarifies that text is optional, takes precedence over check, and scopes the visibility check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: checking the current state of an element or text and returning an immediate boolean observation. It names specific verbs and resources ('check', 'element', 'text') and distinguishes itself from wait_for and assert_condition, so an agent can differentiate it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit routing guidance: use wait_for when a condition may become true later, use assert_condition when failure should raise an assertion error, use find_elements for counts/details, and use get_content for reading actual content. This is comprehensive and 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.
- Behavior4/5
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 well: it discloses that scroll only ensures in-viewport presence, that focus moves keyboard focus, and that highlight 'can affect timing and may reduce stealth' — the last one is a non-obvious behavioral trait an agent must know. It omits edge-case behavior (e.g., what happens when a selector matches nothing), but the core 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the behavior, followed by the negative-scope sentence, then an Args block, then a 'Tool selection' table. Every sentence carries information. It is slightly longer than strictly necessary — the Tool selection section paraphrases the opening paragraphs — but the redundancy improves navigation, so I do not penalize further.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool sits among 24 siblings that include click, type_text, hover_with_action, select_option and scroll, the description exhaustively routes the agent: it covers the primary use, the three actions' semantics, and the exclusions with alternative tool names. It also accounts for the stealth/timing implication of highlight. Nothing an agent needs in addition to the schema and sibling list is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the schema provides only names, a default, and an enum. The description compensates: selector is defined as 'CSS selector or SeleniumBase selector,' and the three action enum values are each explained in a sentence of behavior. It doesn't specify selector validity rules, but for the coverage gap this is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and two resources: 'Scroll to, focus, or highlight an element.' It immediately differentiates itself from siblings (click, type_text, hover_with_action) by explicitly stating it 'does NOT click, type into, select from, hover over, or otherwise activate the element.' This gives an agent a clear discriminator without opening any other schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated 'Tool selection' section lists each use apart ('Bring into view' -> default, 'Focus' -> action="focus") and names the exact sibling alternatives for excluded actions ('Click -> use click', 'Type text -> use type_text', 'Hover -> use hover_with_action'). It states when to use it AND when not to, referencing the right sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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: clear deletes all cookies, save may overwrite files, filename can access the server filesystem, cookies may contain credentials, and loading does not guarantee restored logins. These are exactly the side effects and limitations an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into Args, Returns, Security, and Notes, with the main purpose and use cases front-loaded. Every section earns its place; the length is justified by the tool's breadth and the absence of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-mode tool with no output schema, the description covers input semantics, per-action return values, filesystem and security caveats, and behavioral limitations. An agent can infer exactly what to expect from each action and what precautions to take.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description fully documents each action value, the meaning of filename, the default, and that filename is ignored for get_all and clear. It more than compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear resource (browser cookies) and spells out four concrete operations: inspect, clear, save, and restore. It does not explicitly contrast with the sibling manage_storage tool, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete use cases: inspecting session state, preserving logins, restoring sessions, and resetting website state during testing. It does not say when to avoid this tool or name alternatives such as manage_storage for web storage, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 this tool intentionally waits and is for synchronization rather than validation, and it explains the timeout parameter and text/state interactions. It does not explicitly describe what happens on timeout, but the intentional-wait behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear sections and front-loads the core purpose. However, the text/selector relationship is repeated in the opening paragraph and again in the Args section, and the formatting is somewhat verbose. Still, the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage context, parameter semantics, returns, and alternatives, which is strong for a tool with no annotations. Minor gaps remain: it does not state failure behavior on timeout, and there is some ambiguity about how text works when selector is omitted despite selector being described as 'required unless text is supplied.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does: each state value is defined, selector and text are described with their relationship, and timeout has a default. 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and target: 'Wait until an element or text reaches a requested state.' It explicitly contrasts itself with check_condition and assert_condition, so an agent can distinguish it from siblings without inspecting their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives direct usage context: use when the page is dynamic and an automation step must wait. The 'Tool selection' list explicitly states when to use check_condition, wait_for, or assert_condition, making decision-making straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 the blocking behavior, the fact that no browser action occurs, and the fixed-duration nature. It does not mention potential side effects like all MCP requests being blocked or whether the wait is absolute, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a one-sentence core definition, a brief explanatory paragraph on usage, and an Args section. Every sentence contributes value, with the most important statement front-loaded and no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema present, the description covers the essential purpose, usage constraints, and parameter semantics. It could add a caution about the impact of long blocking times, but the 'Block the MCP server' phrasing already implies this, and the output schema handles return-value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the one parameter. It does so by defining 'seconds' as 'Number of seconds to block' and clarifying 'May be an integer or float,' which adds unit, type flexibility, and meaning beyond the bare schema type. It stops short of specifying bounds or validation rules, but for a single-parameter tool this is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Block the MCP server for a fixed number of seconds.' It immediately differentiates itself from sibling wait_for by labeling itself a 'low-level timing tool' that performs no browser action, making its scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-not-to-use guidance is provided: 'should not be used when waiting for a page condition' and 'Prefer wait_for when waiting for an element or text to appear/disappear, because wait_for can return as soon as the requested condition is met.' This clearly routes an agent between the two wait tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 and explicitly states 'This is a read-only operation and does not modify the element.' It also describes the return behavior for both cases: the requested attribute value or a dictionary of all attributes. It does not specify behavior for multiple matching elements or missing selectors, but the key side-effect and return expectations are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Tool selection sections, and the main purpose is front-loaded in the first sentence. Every section earns its place; the bulleted alternatives are clear and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a simple read-only getter: it explains parameter semantics, return values, and when to use alternatives, which matters because there is no output schema. It could additionally clarify whether the first matching element is used when a selector matches multiple elements, but this is a minor gap for the stated use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 selector as 'CSS selector or SeleniumBase text-matching selector' and attribute as an optional parameter whose omission returns all HTML attributes. This adds substantial meaning beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 HTML attributes from a matching element.' It clearly identifies the domain (HTML attributes) and the target (a matching element), and the Tool selection section explicitly distinguishes it from sibling tools like find_elements, get_content, and check_condition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit 'Use this tool when you need the value of one or more HTML attributes' statement and then provides a bulleted Tool selection list naming exact alternatives for other needs. An agent can determine when to invoke this tool versus find_elements, get_content, or check_condition without guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 what each output_format returns, how selector scopes the result, and the include_shadow_dom default behavior. It does not describe failure modes or edge cases like empty results, but for a read-only content tool this is a minor omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized into Args, Returns, and Tool selection sections. Each section adds value, and the core purpose is front-loaded. Minor redundancy between the intro use-case sentence and the Tool selection list, but it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool of this complexity: it documents every parameter, defines all output formats, explains return types, and provides routing guidance to five sibling tools. The presence of an output schema additionally covers structured return details, so nothing an agent needs to invoke correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 all three parameters with concrete semantics: selector scoping per output_format, the exact meaning of each enum value, and include_shadow_dom's effect and default. This goes far beyond the schema's bare property names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific action and resource: 'Read visible text, HTML, or discovered URLs from the current page.' It clearly distinguishes from siblings by listing specific alternatives in Tool selection, such as get_page_info for metadata, find_elements for structured element info, and check_condition for presence/visibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The Tool selection section explicitly maps user needs to the correct tool (e.g., 'Need URL, title, origin, or User-Agent -> use get_page_info') and to the correct output_format. The introductory sentence also sets the general condition: use when you need actual page content or URL information rather than page metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 explains what each action does, including that get_rect returns coordinates/size and that set_rect requires all four parameters. It does not mention returned values for non-get actions or coordinate units, but no annotation contradiction exists and the behavioral surface is 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently organized: a one-line summary, a structured Args section, and a final routing sentence. Every part adds information, and the key purpose statement is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description supplies the essential actions, parameter meanings, and usage boundary. It does not specify coordinate units or return values for set_rect/maximize/minimize, which keeps it from being fully complete, but the core calling contract is clearly explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 does, by documenting every parameter: action's four enum values, x/y as screen positions, and width/height for set_rect, plus the requirement that all four be provided together. This goes beyond the schema's bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-and-resource statement: 'Get or change browser window geometry and state.' It then enumerates the exact actions, making its scope unmistakable and distinguishing it from sibling tools, particularly manage_tabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool for browser-window geometry/state and to use manage_tabs for switching tabs instead. This provides clear selection guidance relative to the most likely sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses automatic protocol prefixing ('https://'), waits for the initial HTML document, and notes that navigation adds to browser history. Minor omissions like error handling or timeout behavior slightly reduce completeness, but core behavioral expectations 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections for Args, Returns, and Tool selection. It front-loads the primary purpose and usage. The only blemish is a likely typo in the tool selection section where 'forward' is mapped to 'reload' instead of 'forward', which slightly detracts from an otherwise crisp structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers all essential aspects: what URL formats are accepted, protocol handling, loading behavior, return confirmation, and clear alternative routing. It is fully sufficient for an agent to select and invoke navigate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain the url parameter. It does, stating it may be a complete URL or hostname, explaining the automatic 'https://' prefix with a concrete example. This adds substantial meaning beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Navigate the current browser tab to a URL,' a specific verb+resource statement. It further distinguishes the tool from history-based navigation by stating it is for visiting a new URL 'rather than move through its existing back/forward history,' clearly differentiating it from sibling manage_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit selection guidance: use navigate for a new URL, manage_history for back/forward/reload. It names the exact alternatives and their actions ('manage_history(action="back")'), leaving no ambiguity about when this tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It clearly warns that the tool does not guarantee a solved CAPTCHA, that some controls are in shadow DOM and expose no success signal, and that attempts may change page state or cookies. This is unusually transparent about uncertainty and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by limitations, a numbered workflow, and return behavior. Every sentence contributes meaningful guidance; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a zero-parameter tool with an output schema. It covers what the tool attempts, why the result may be uncertain, what side effects may occur, how to verify outcomes with sibling tools, and what the return message conveys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so there are no parameter semantics to document. The baseline of 4 applies since no parameters exist and no parameter information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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.' It goes on to name concrete CAPTCHA types (Cloudflare Turnstile, reCAPTCHA, FriendlyCaptcha), making the tool's scope unambiguous and distinct from browser automation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The workflow is explicit: inspect with get_content first to detect CAPTCHA controls, then call solve_captcha, then verify state with get_page_info, get_content, check_condition, or manage_cookies. This gives clear usage context, though it does not state any explicit 'when not to use' condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 thoroughly explains the persistent session, state preservation, CDP communication, OS-specific headless defaults, and environment prerequisites. It also describes return values and error behavior, leaving no ambiguity about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (Args, Returns, Lifecycle, Environment) and every section earns its place. However, the headless default explanation is repeated nearly verbatim in Args and Environment sections, adding minor redundancy. Overall, it remains focused and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 8 parameters, no annotations, and no schema description coverage, so the description must cover a lot. It addresses all parameters, lifecycle, environment, return values, and failure behavior. For a tool that establishes a persistent browser session, the description is exceptionally complete and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 each parameter's purpose, default behavior, and constraints. It even warns against combining mutually exclusive parameters (use_chromium with browser_executable_path, incognito with guest) and gives proxy format examples, adding significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: launching a persistent SeleniumBase Pure CDP Mode browser session. It distinguishes this tool by defining the session lifecycle and its role as a prerequisite for other browser interaction tools, so an agent can easily tell it apart from siblings like navigate or close_browser.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('must be called before browser interaction tools') and when to close it ('call close_browser when finished'), plus environment requirements. However, it does not mention what happens if the tool is called again while a session already exists, which is a minor gap in usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Because no annotations are present, the description carries the full disclosure burden and succeeds. It states that failed expectations raise an error, that URL/title checks ignore the timeout, that text_visible can fall back to searching the whole document, and that failures surface as a descriptive MCP error wrapper.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is moderately long but tightly organized into Intro, Args, Returns, Raises, and Tool selection sections. It front-loads the core behavior and sibling differentiation before details, and every section contributes actionable information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For its complexity, the description covers invocation semantics, per-check behavior, error/return behavior, and alternative-tool routing—enough for an agent to select and call it correctly. Residual gaps are the under-defined exact and timeout parameters, and the timeout note is never expanded into a full argument description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description enriches parameter meaning well: the check enum is fully explained, selector is scoped to three check types, and expected is mapped to four checks. However, 'exact' is described only by which checks it applies to, not what it does, and 'timeout' is never listed in Args—it appears only in a parenthetical caveat—so two of five parameters remain under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action and resource: 'Verify an expected browser condition and fail when it is not met.' It immediately contrasts with check_condition, which 'simply reports True or False on the current state,' so an agent can distinguish it from the most similar sibling 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated 'Tool selection' section provides explicit routing: use check_condition for inspecting current state, wait_for for waiting, and assert_condition for verifying an expected condition. This names alternatives and their exact trigger conditions, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It explains the behavior of each action value and warns that tab indexes can go stale because links or browser actions may open new tabs. It does not discuss reversibility or side effects of close_active, but the meaning of 'close' is reasonably explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized into an opening statement, scoping sentence, Args breakdown, and Notes. Each action is explained in its own line with enough detail to be useful, and the stale-index caveat is placed where it will be noticed. There is no significant wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description still covers action semantics, parameter meanings, return contents for list, and the important stale-index edge case. An agent has everything needed to call this tool correctly and recover from tab changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 each parameter's role: action enum values, url for action='open', tab_index from action='list' for action='switch', and switch_to for action='open'. This adds substantial meaning beyond the bare input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a clear verb set and resource: 'List, open, switch between, or close browser tabs.' It also immediately differentiates from sibling tools by saying in-tab navigation belongs to navigate and manage_history, so an agent can distinguish manage_tabs from those related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly scopes usage to 'tab management' and excludes browser navigation within the current tab as belonging to navigate and manage_history. It also gives a concrete procedure: call action='list' before switch to obtain a valid tab_index, and re-check tabs after link clicks because new tabs may appear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It clearly warns that files may be overwritten and that filename/folder can affect server-accessible filesystem paths. It also states the write side effects and the confirmation return value. This is strong transparency for a file-writing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Security), front-loads the core purpose, and every sentence adds information. It is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-optional-parameter tool with no required inputs, the description covers purpose, usage, all parameters, return behavior, and security caveats. Nothing needed 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter: format's three enum options, the format-dependent default filename, and the optional folder. This adds real meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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.' This clearly distinguishes the tool from all browser-navigation and element-interaction siblings, none of which produce persistent artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: 'Use this tool when an automation workflow needs a persistent artifact from the current page.' While it does not name alternatives or state when not to use it, no sibling tool competes for this responsibility, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 amount is a percentage of viewport height and that amount is ignored for top/bottom. It doesn't cover edge cases like no-overscroll or return behavior, but the output schema exists and the core behavior is well specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then uses a compact Args block to document parameters, and finishes with a clear alternative tool. No sentence is wasted and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter scroll tool with an output schema and no annotations, the description covers all necessary semantics: direction values, amount meaning, ignored-argument behavior, and when to use a sibling tool. There are no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only parameter documentation. It fully describes every enum value for direction, defines amount as a percentage of viewport height, and provides a concrete example. It also notes when amount is ignored.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Scroll the current page vertically.' It enumerates all four direction behaviors and explicitly contrasts with focus_on(action='scroll_to_element'), distinguishing it from a key sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: '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 clearly identifies when to choose an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses the matching modes, the error condition when the dropdown or option cannot be found, and the native-select limitation. It does not fully specify side effects such as whether change events are fired or how disabled dropdowns are handled, but it is substantially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line purpose, a compact Args list, a Raises note, and a clear alternative-tools sentence. Every section adds necessary information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and sibling tools provide surrounding context, the description is complete: it defines the operation, parameter semantics, error behavior, and the boundary against custom dropdowns. An agent has enough 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.
Parameters5/5Does 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 parameters. It does: dropdown_selector is defined as a CSS selector, value is explained with three matching modes, and by is clearly documented with text, value, and index semantics, including acceptance of integer or numeric-string index values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Select an option from an HTML <select> dropdown.' It clearly distinguishes itself from siblings by explicitly stating it targets native <select> elements and directing custom dropdowns to click or other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: for native <select> elements. It also states when NOT to use it and provides alternatives: 'For custom JavaScript dropdowns made from div/button/list elements, use click or other element-interaction tools instead.' This leaves no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 provides per-mode semantics, including side effects: fill_input clears first, append keeps the existing value, fast_type avoids pauses, set_value does not simulate normal key events and supports range inputs, clear_only empties the field. This is thorough behavioral detail well beyond a generic 'enters text' line.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise summary, then follows with a clear Args list and a Tool-selection section. It is longer than minimal, but every sentence serves a purpose—no filler or repetition. The structured bullet lists and headings make it easy to scan. A slight deduction because the content could be tightened without losing substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully specifies parameter semantics, element restrictions, selection criteria, and mode-specific behaviors, and an output schema exists to cover return values. It does not mention error behavior (e.g., what happens if the selector matches nothing or timeout expires), but that is a minor gap given the richness of the rest and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so admirably: the Args section explains selector meaning, text usage, timeout semantics, and each mode with concrete effects and an example for set_value with range inputs. The mode parameter is fully elaborated with five clearly described choices, giving the agent everything needed to choose correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action phrase 'Fill, append, fast-type, directly set, or clear a form control', naming the resource type and the distinct operations. It further delimits its scope to 'input elements, textareas, and contenteditable elements', which distinguishes it from sibling tools like 'click' or 'select_option'. The 'Tool selection' section explicitly routes away from text-entry toward 'get_content'/'find_elements' for listing inputs, so an agent can reliably tell this tool apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Tool selection' section states exactly when to use this tool: 'use it when you know the selector and want to change or clear its value', and when not to: for a complete listing of inputs use 'get_content' or 'find_elements'. It also explicitly restricts usage to form-control element types. This gives the agent explicit decision criteria rather than leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so thoroughly. It declares the operation READ-ONLY, lists what it does not do (inspect content, find elements, wait, assert), and explains the no-session fallback: returns {"running": False} instead of attempting page access. It also states that 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a return-value breakdown, tool-selection bullets, and a final side-effect warning. Although slightly long, every section earns its place and the most important usage guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is complete: it specifies returned fields, session-inactive behavior, read-only guarantees, and sibling tool alternatives. The output schema exists, but the description's return section still adds useful context beyond a bare schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is unnecessary. The baseline of 4 applies because there is no parameter meaning to add; the description instead focuses usefully on return value semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Get current browser session and page metadata.' It also positions the tool as the primary way to determine where the browser currently is after navigation, clicks, redirects, reloads, or tab switches, which clearly separates it from content- and element-focused siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Tool selection' section explicitly maps needs to tools: URL/title/origin/user-agent -> get_page_info; visible text/HTML -> get_content; matching elements -> find_elements; state checks -> check_condition; waits -> wait_for; assertions -> assert_condition. This gives an agent explicit 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It discloses that back/forward have no effect without history entries, that reload bypasses the browser cache, and that operations can trigger page loads requiring a wait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Notes sections. The only minor issue is slight redundancy between the opening sentence and the 'Use this tool...' paragraph, but it remains appropriately sized for a multi-action tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, one parameter, no annotations, and an output schema, the description covers invocation, parameter behavior, return values, side effects, and alternatives. Nothing essential is missing for an agent to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only an enum with no descriptions, but the description fully documents each action value: back, forward, reload, and list. It explains the effect of each action and the return behavior, completely compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: navigate the current browser history, reload the current page, or list history. It also explicitly distinguishes itself from the 'navigate' tool by saying that tool is for arbitrary URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool: for relative history navigation or displaying current history. It also gives an alternative: use the 'navigate' tool for arbitrary URLs, which is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it delivers. It discloses that element handles resolve immediately into JSON-like dictionaries, that live SeleniumBase objects are not returned, and that element handles cannot be persisted across MCP calls. It also specifies the exact return shape and empty-result behavior, which is valuable beyond the bare schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with clear sections: summary, args, returns, tool selection, and a note on handle persistence. Every sentence adds useful information, and the most important distinction from sibling tools is front-loaded. The length is justified by the absence of annotations and schema-level parameter descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition covers the tool's purpose, when to use it versus alternatives, all parameter semantics, the return structure, and the key limitation that element handles cannot persist across MCP calls. This is everything an agent needs to correctly select and invoke the tool, even without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only names, types, and defaults, with 0% schema description coverage, so the description must compensate. It does so thoroughly by explaining selector syntax with concrete examples, defining timeout as maximum wait seconds with its default, and describing exactly what include_html controls. This adds real meaning beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Find matching elements and return structured element information.' It also explicitly distinguishes itself from siblings in the Tool selection section, naming get_content, click, and check_condition as alternatives, so an agent can easily tell what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The Tool selection section gives concrete when-to-use guidance: use find_elements for structured information about matching elements, get_content for page/single-element text/HTML, click with nth for clicking one match, and check_condition for presence/visibility. This is explicit and actionable, leaving no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 excels. It discloses execution via Chrome DevTools Protocol Runtime.evaluate in the active page, access to page JS context, Promise support, serialization limits for return values, and a security warning about unrestricted read/write access to page data. Nothing about the tool's behavior is hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place due to the tool's complexity and safety implications. It is well-structured with clear headings (Tool selection, Args, Returns, Security), bulleted lists, and front-loaded purpose. No filler or repetition; the detail is necessary for correct and safe invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one opaque parameter, the description covers everything an agent needs: what it does, when to use it, what the parameter accepts, what values can be returned, serialization caveats, and security context. Even the return behavior is explained despite no output schema, making the tool fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, so the description fully compensates. The Args section defines 'expression' comprehensively: what it is, how it is evaluated, browser globals available, five concrete examples, and guidance on producing values and Promise handling. This goes far beyond the schema's bare parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource: 'Evaluate a JavaScript expression in the current page context.' It clearly distinguishes itself from sibling tools by stating it is for operations that cannot be accomplished through higher-level SeleniumBase tools, so an agent immediately knows what this tool uniquely does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit and actionable. It says 'Use this only when the required browser operation cannot be accomplished through the higher-level SeleniumBase tools' and then lists specific alternative tools to prefer for interactions, reading content, storage, and cookies. It closes with a positive condition: use when arbitrary JavaScript is needed that higher-level tools do not expose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/seleniumbase/seleniumbase-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server