SeleniumBase MCP
OfficialServer Quality Checklist
Latest release: v1.0.0
- Disambiguation2/5
The tool set has many near-neighbor clusters: click/click_visible_elements/click_nth_element/click_link/click_if_visible, wait_for_element_not_visible/wait_for_element_absent, find_element_info/get_element_html, and assert_text/wait_for_text/is_text_visible. Although descriptions are clear, the sheer number of subtly different variants makes selecting the right tool error-prone.
Naming Consistency4/5Most tools follow a predictable snake_case verb_noun pattern (get_current_url, set_window_rect, save_screenshot) and opposite pairs are recognizable. Minor deviations like bare verbs (sleep, evaluate) and mixed phrases (go_back, save_as_pdf) are easy to learn but break the pattern slightly.
Tool Count1/579 tools is far beyond the 3-15 well-scoped range and falls into the extreme-mismatch category. Many operations could be consolidated (e.g. generic vs nth vs visible clicks, multiple wait/assert state variants), reducing cognitive load without losing capability.
Completeness3/5Core browser lifecycle (start/navigate/interact/wait/assert/storage/capture/close) is well covered, so agents can accomplish most tasks. However, switch_to_tab references a get_tabs tool that is missing, and common actions like hover, drag-and-drop, uploads, and alert handling are absent, leaving notable gaps.
Average 3.7/5 across 79 of 79 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 4 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
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
- Behavior2/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 only states the basic action without explaining how the scrolling is performed (e.g., scrollIntoView alignment behavior), what happens when the element is not found, or whether any side effects occur. This is a minimal statement that lacks behavioral depth.
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 a single sentence with no filler, and the core action is front-loaded. It is appropriately concise for a simple one-parameter tool, though it sacrifices detail for brevity. The structure is clean and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and an output schema, the description is minimal but still misses key operational details such as behavior when the element is absent, scrolling alignment, and relation to the broader scrolling toolkit. The description is adequate only for the simplest interpretation and leaves several practical questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 by explaining the selector parameter. It does not clarify whether the selector is a CSS selector, XPath, or some other format, nor does it provide usage examples. The parameter name 'selector' is self-explanatory, but the description adds no meaningful semantic value beyond the schema field itself.
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 states a specific verb ('Scroll') and a resource ('an element'), which clarifies that this tool scrolls a particular element into view rather than simply scrolling the page. It does not explicitly distinguish itself from sibling tools like scroll_to_top or scroll_to_bottom, but the resource target is clear enough for basic differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as scroll_up, scroll_down, scroll_to_top, or scroll_to_bottom. There is no mention of selector-based element targeting or context like 'use this when you need to bring a specific element into the viewport.' This leaves the agent to infer the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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. It only states the core return behavior and does not clarify what 'visible' means (e.g., present in DOM, within viewport, not hidden via CSS), whether the tool waits or fails if no element matches, or how multiple matches are handled.
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 entire description is a single concise sentence with no redundant words. It is immediately readable and front-loads the action, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description leaves out enough context that an agent could easily confuse it with is_element_present, is_text_visible, or wait_for_element_visible. It also lacks any behavioral nuance such as return-on-missing semantics, which matters for selection among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description adds only the phrase 'matching the selector,' which confirms the selector identifies the element but does not explain expected format, syntax, or examples. For a single-parameter tool this is sparse but not catastrophic, hence a 2.
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 clearly states the tool returns whether an element matching the selector is visible, with a specific verb ('return') and resource ('element matching the selector'). It does not explicitly differentiate from siblings like is_element_present or is_text_visible, but the distinction is largely inferable from the name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as wait_for_element_visible, assert_element_visible, or is_element_present. No context is given about typical scenarios, prerequisites, or why an agent would choose this over related checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Return whether' without explaining whether the call waits, throws on absence, treats hidden text as non-visible, or performs any side effects. This is a significant gap for a predicate 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 a single focused sentence with no filler. The key action and subject are front-loaded, making it easy for an agent to scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description still leaves important invocation details undefined: visibility semantics, waiting behavior, selector interpretation, and how this differs from similar assertion/wait tools. An agent would likely need to inspect other tools or docs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 loosely maps 'text' and 'element' to the two parameters, but it does not clarify matching semantics (exact vs substring), selector syntax, or the default 'body' behavior. The added meaning beyond the schema is minimal.
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 states a clear predicate: whether a specific text is visible within an element. It identifies both the resource (text visibility) and scope (an element), which helps distinguish it from generic visibility checks like is_element_visible, though it does not explicitly name any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to call this tool versus wait_for_text, assert_text, or is_element_visible. There is no mention of conditions, alternatives, or exclusions, leaving the agent to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states the action without mentioning file naming behavior, destination folder semantics, overwrite behavior, permissions, or any side effects beyond saving a screenshot. This is minimal disclosure for a tool that creates a file.
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 a single clear sentence with no wasted words, and the primary action is front-loaded. It is appropriately short for a simple tool, though the brevity leaves important behavioral and parameter information unaddressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has no required parameters, and an output schema exists, so the description is minimally usable for basic invocation. However, with no annotation coverage and no parameter explanations, it is not fully complete for an agent deciding how to customize the screenshot or interpret the side effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the two parameters beyond what their names and defaults already suggest. An agent cannot learn from the description what 'folder' affects or how 'name' should be formatted.
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 states a clear verb and resource: 'Save a screenshot of the current page.' It is unambiguous about what the tool does and is distinct from page-source or PDF saving in intent, though it does not explicitly differentiate itself from sibling tools like save_page_source or save_as_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as save_page_source or save_as_pdf. It implies the use case through the name and phrasing, but excludes no contexts and names no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states only the basic operation and omits important context such as units, whether it scrolls the viewport or an element, boundary behavior at the top of the page, and what the result indicates. There is no annotation contradiction, but the disclosure is minimal.
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 one short, direct sentence with no filler. The relative-quantity qualifier is front-loaded and clear. While the brevity contributes to under-specification, the description itself is appropriately concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a single optional parameter and an output schema, the description is minimally viable: the direction and relative nature are stated, and the schema provides the default. However, missing unit and scoping context means an agent cannot fully predict behavior in edge cases, especially with no annotations to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds that the amount is 'relative.' It does not explain the unit, sign convention, allowed range, or what happens when amount is omitted despite the default of 25. The description adds minimal meaning beyond the schema field title.
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 names the action ('scroll up') and adds the key qualifier 'by a relative amount,' which distinguishes it from absolute scroll tools like scroll_to_top and scroll_to_bottom. However, it does not explicitly state what is being scrolled (page/viewport) and only differentiates from scroll_down via direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose scroll_up over scroll_down, scroll_into_view, scroll_to_top, or scroll_to_bottom. The phrase 'relative amount' implies a use case but does not explicitly state when this tool is appropriate or when an alternative is better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 does not explain how the include_shadow_dom parameter affects what "full HTML source" means, nor whether this returns live serialized DOM or the original page source, making the term "full" potentially misleading.
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 a single, front-loaded sentence with no filler words. Every word contributes to the core meaning, and the structure is appropriately minimal for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema plus one optional parameter, so the description does not need to explain return values. However, it omits the meaning of include_shadow_dom and any contrast with similarly named siblings, leaving the definition minimally adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 for the undocumented include_shadow_dom parameter, but it never mentions it. The parameter name and title are somewhat self-explanatory, but the description adds no meaning beyond the schema.
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 states a clear verb and resource: "Get the full HTML source of the current page." It is easily distinguishable from siblings like get_element_html and save_page_source, but it does not explicitly name or contrast those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of related siblings such as save_page_source, get_element_html, or evaluate. The description is purely declarative and leaves all selection decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 disclosing side effects. It states that cookies are written to a file, but does not mention whether the file is overwritten, where the file is saved, or what format is used. This is a persistence operation with potentially destructive overwrite behavior that is not 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 a single, front-loaded sentence with no filler words. It is appropriately concise for a simple tool, though it sacrifices behavioral detail that would be valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter, no annotations, and only a minimal description. It leaves important details unaddressed: file path, overwrite behavior, and whether the file is stored locally or remotely. Becase there are no annotations and the output schema does not cover side effects, the description is not enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'name' with no description and a default of 'cookies.txt'. The phrase 'to a file' hints that 'name' refers to the file name, but this is not explicitly stated. With 0% schema coverage, the description only minimally compensates for the parameter's ambiguity.
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 uses a specific verb 'Save', identifies the resource 'current cookies', and specifies the target 'to a file'. This clearly distinguishes it from sibling tools like get_all_cookies or load_cookies, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. It does not mention that load_cookies restores saved cookies or that get_all_cookies retrieves cookies without file persistence, leaving the agent to infer the intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of declaring side effects. 'Get' implies a read-only inspection and the tag list clarifies exactly which page URLs are gathered. It does not discuss normalization, deduplication, or the effect of the absolute parameter, but no destructive behavior or contradiction is indicated.
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 one short, front-loaded sentence with no filler and a precise list of relevant tags. It would benefit from a clause about the absolute parameter, but that omission is a completeness issue, not a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The function is simple, has an output schema, and no required parameters, so a terse description is appropriate. Still, the unmentioned absolute parameter and the lack of any routing guidance leave gaps for an agent deciding how to call it or distinguish it from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, absolute, has 0% schema description coverage and is never mentioned in the description, so the agent cannot learn from the description what true/false does to the returned URLs. The parameter name gives a hint, but the description adds no parameter-level meaning.
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 names a specific action and object: 'Get all linked URLs' and narrows scope with the explicit tag list '(a, link, img, script, meta)'. It is distinguishable from single-URL tools like get_current_url, though it does not explicitly contrast with sibling scraping tools, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to choose this over get_html_source, find_all_info, or get_current_url, nor any exclusion such as 'for same-origin URLs only'. Usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states the action, without mentioning what happens when the selector matches multiple elements, finds nothing, or whether the tool waits for the element to exist. 'Get' implies read-only, but no other behavioral traits are revealed.
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 a single direct sentence with no unnecessary words. It front-loads the core action and resource, making 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's low complexity and the existence of an output schema, the description omits essential details such as selector format, matching behavior, and error handling. With no annotations, these gaps could lead an agent to invoke the tool incorrectly or misinterpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'selector' parameter or specify its format (e.g., CSS selector vs XPath). The schema provides only the parameter name and type, which is insufficient to fully understand selector syntax expectations, though the name 'selector' is somewhat self-explanatory.
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 clearly identifies the operation ('Get') and the resource ('outer HTML of a specific element'). It is specific enough to be distinguished from page-level tools like get_html_source and attribute-level tools like get_element_attribute, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the name and description: use this when you need an element's outer HTML. However, there is no explicit guidance about when to prefer this tool over get_html_source or get_element_attribute, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 behavior disclosure. It merely restates the action without specifying what 'amount' means (pixels? lines? percentage), whether negative values are allowed, or what happens at scroll boundaries. The agent is left uninformed about observable side effects and return values.
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 a single focused sentence with no redundancy or filler. Every word contributes to stating the core action, making it maximally concise for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and an output schema exists, the description lacks essential context: units for 'amount', guidance among the many scroll siblings, and behavior at limits. An agent selecting among scroll_down, scroll_up, scroll_to_top, scroll_to_bottom, and scroll_into_view receives no explicit routing help beyond the word 'relative'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 for the undocumented 'amount' parameter. It adds only the vague qualifier 'relative', without defining the unit, valid range, semantics of the default value, or directionality. The agent cannot confidently choose a correct value.
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 states a clear verb ('Scroll down') and resource (the viewport), and the phrase 'relative amount' differentiates it from absolute scroll tools like scroll_to_top and scroll_to_bottom. It is not a tautology and conveys the essential action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'relative' implies this is for incremental scrolling rather than jumping to an absolute position, which lightly distances it from scroll_to_top/scroll_to_bottom. However, it gives no explicit guidance on when to prefer scroll_down over scroll_up, scroll_into_view, or other siblings, so the user must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. 'Clear all cookies' communicates a destructive operation but does not disclose that it may log the user out, that the effect is irreversible, or that it only affects cookies and not local/session storage. The description adds little beyond what the tool name already implies.
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 extremely concise, consisting of a single clear sentence. It is appropriately sized for such a simple tool, though it is nearly a restatement of the tool name and provides no additional structural detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter utility, the description is minimally adequate, but it omits important context for an AI agent, such as the scope of 'all cookies' and the impact on the current browsing session. Given the destructive nature of clearing cookies and the existence of related storage tools, a bit more context would make the tool safer and easier to invoke correctly.
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, so there is no parameter information to clarify. The baseline score of 4 applies because no parameter semantics are needed; the description adequately addresses the action for a parameterless tool.
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 states a specific verb ('Clear') and resource ('all cookies'), clearly distinguishing it from sibling tools like get_all_cookies, save_cookies, and load_cookies. However, it does not clarify whether 'all cookies' means all cookies in the browser context or only cookies for the current domain, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as save_cookies, load_cookies, or get_all_cookies. The description simply states the action without suggesting use cases, prerequisites, or situations where clearing cookies might be undesirable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose a useful behavior: it raises an exception if the element is not found within the default timeout. However, it does not mention side effects like scrolling, focus events, or whether the element must be visible, leaving part of the behavioral profile unstated.
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 two short sentences with no filler. The primary action is front-loaded, and the exception behavior is a useful secondary detail that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter action with no annotations, the description covers the basic action and failure mode but omits selector semantics and any context for selecting this tool over similar element-targeting siblings. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 for the undocumented selector parameter. It merely calls the target 'an element' and does not explain what selector syntax is accepted (e.g., CSS, XPath) or any constraints on selector values.
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 states a specific action ('Move focus') and a clear resource ('an element'), so an agent can grasp the tool's core purpose. It does not explicitly differentiate itself from siblings like click or highlight, which also target elements and affect interaction state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use focus versus click, highlight, or keyboard-adjacent tools, nor any exclusions or alternatives. The only additional sentence describes failure behavior, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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. 'Get a value' clearly signals a read operation with no mutation intent, which is helpful. However, it does not disclose what happens when the key is missing (e.g., null/undefined) or whether any side effects occur, so transparency is partial.
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 a single front-loaded sentence with no filler or redundancy. It states the verb and resource immediately and earns its place with clear, direct language. There is no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is close to adequate, but it leaves gaps: no mention of return behavior when the key is absent and no indication of how this differs from get_session_storage_item. There is no output schema to clarify return values, so the description should have provided a bit more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no extra meaning about the 'key' parameter beyond the schema's type and title. It does not explain that the key must match an existing localStorage entry or what value format is expected. The description should compensate for the sparse schema but does not.
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 uses a specific verb and resource: 'Get a value from the page's localStorage.' It clearly states a read operation on localStorage, and the tool name reinforces the resource. However, it does not explicitly differentiate itself from sibling tools like get_session_storage_item or set_local_storage_item, though the localStorage mention makes the distinction reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention get_session_storage_item for session storage or set_local_storage_item for writes, nor does it describe contexts where this tool is inappropriate. The usage is only implied by the word 'localStorage'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states the action and reveals no details about what the history contains (URLs, timestamps, session vs. persistent), whether a browser session must be active, or how results are structured. The lack of additional behavioral context is a notable gap.
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 one short, front-loaded sentence with no filler. Every word contributes to the core purpose, and for a parameterless tool this is an appropriately sized definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple interface (no params), the description leaves out important context such as the return format, whether the history is limited to the current session, and whether a browser instance must already be running. With no output schema to clarify results, the description is incomplete for an agent to fully understand the tool's behavior.
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, so the input schema is complete by default. With no params to describe, the description does not need to compensate for schema gaps, and the baseline of 4 is appropriate.
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 states a clear verb ('Get') and resource ('the browser's navigation history'), identifying a specific function. It does not explicitly differentiate itself from siblings like get_all_urls or get_current_url, but the resource name is distinctive enough to convey the basic purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_all_urls, go_back, or go_forward. There are no conditions, prerequisites, or exclusions mentioned, leaving the agent without direction for choosing this tool over related navigation queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states the basic count operation and does not mention whether the tool waits for elements, whether hidden elements are included, what happens on zero matches, or whether it is strictly read-only.
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 a single, front-loaded sentence with no filler. Every word contributes to the core meaning of the tool, and it is appropriately sized for a simple count operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema, the description minimally covers what the tool returns conceptually and identifies the key selector input. However, it leaves the timeout parameter's semantics unexplained and does not address edge cases such as no matching elements, which an agent would benefit from knowing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 clarifies that the selector is used to match elements on the page, but it says nothing about the timeout parameter, its units, or its behavior when null. This leaves a required part of the invocation semantics undocumented.
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 a specific action ('Get the count') and a specific resource ('elements on the page match the selector'). This distinguishes it from sibling tools like find_all_info or is_element_present, which return details or presence rather than a count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool instead of alternatives such as find_all_info, is_element_present, or wait_for_element_present. There are no exclusions or conditions, so an agent must infer the appropriate context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It only states the return type and does not disclose behavior for missing elements, multiple matches, or whether this is a side-effect-free read operation.
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 a single, front-loaded sentence with no filler. It conveys the core action and output shape efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so basic context is sufficient. However, the lack of selector semantics and behavioral details leaves gaps that an agent would need to infer from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the selector parameter format, syntax, or matching behavior. It only refers to 'an element' without adding meaning beyond the schema property 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 states a clear verb-resource pair ('Get all attributes') and the return format ('as a dict'). The word 'all' distinguishes it from the sibling get_element_attribute, which is singular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus get_element_attribute or find_element_info. The description implies exhaustive retrieval but never states the selection criteria or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action; it does not mention potential overwrite behavior, where the file is saved when folder is null, whether it waits for rendering, or any other 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 a single clear sentence with no filler. It front-loads the core purpose and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so return value explanation is not needed. However, essential behavioral details—such as default save location, file overwrite rules, and parameter semantics—are missing. It's minimally viable for a straightforward tool but leaves gaps an agent would have to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It says nothing about what 'name' or 'folder' mean, how folder paths should be formatted, or how defaults behave. The parameter names and schema defaults provide the only semantic hints.
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?
Description states a specific action ('Print'), the resource ('the current page'), and the output format ('a PDF file'). This clearly differentiates from sibling tools like save_screenshot and save_page_source, even though it doesn't name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any prerequisites or exclusions. The only implied context is that you use it when you want a PDF of the current page, but nothing is stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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. It only states the action without disclosing side effects like navigation, reload, triggering JavaScript, or what happens if no form is found. Form submission is a mutating behavior that needs more transparency.
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?
A single sentence with no wasted words. It efficiently conveys the core operation and the parameter's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The overall complexity is low and an output schema exists, so return values don't need explaining. However, the description omits critical context such as side effects, when to use it, and behavior on failure, and no annotations fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 add meaning by indicating the selector is inside the form, which implies it is used to locate the containing form. However, it doesn't clarify selector syntax or constraints beyond this.
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 ('Submit') and resource ('a form'), and explains the mechanism ('via a selector inside it'). This clearly distinguishes it from sibling tools like click, type_text, or evaluate, and indicates the tool will find the containing form for a selector and submit it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as clicking the submit button or pressing Enter. The description implies use for form submission but provides no exclusions or routing context.
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 usefully discloses that a missing timeout defaults to 7 seconds and that an exception is raised if the element is not found within the timeout. It could additionally clarify behavior when an element is present but not visible, but the disclosed timeout and failure semantics are valuable.
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 concise and front-loaded, stating the core action first, then the timeout default, then the failure behavior. Every sentence adds relevant information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter assertion tool, the description covers the essential default and exception behavior, and an output schema exists so return values need not be explained. However, it lacks selector guidance and does not address when this assertion is preferred over closely related wait/assert siblings, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 explains the timeout parameter's default behavior, but it provides no meaningful explanation of the selector parameter beyond its literal name, leaving the agent without guidance on selector format or accepted syntax.
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 clearly states the tool asserts that an element is visible on the page, using a specific verb and resource. It does not explicitly differentiate itself from siblings like wait_for_element_visible or assert_element, but the assertion-focused wording makes its purpose reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as wait_for_element_visible or assert_element. It only explains the timeout default and exception behavior, which is useful but does not help an agent choose among closely related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and indexing convention, but omits important behaviors such as what happens if the element is not found, whether it waits for the element to exist, or whether it requires the element to be visible. For a mutation tool, this is a significant gap.
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?
A single, front-loaded sentence with no wasted words. It efficiently communicates the core action and the critical indexing detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema present, the description is mostly adequate but misses edge-case context such as error behavior, waiting, and visibility requirements. Given the existence of related tools like click_visible_elements and wait_for_element_visible, an agent could benefit from additional context about when this action will succeed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 explain the 'number' parameter as the 1-indexed position and 'selector' as the matching query, but it does not clarify the selector syntax (e.g., CSS selector) or whether number refers to the order in the DOM or in the visible set. Partial compensation, but not complete.
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 clearly states the action (click) and the resource (the Nth element matching a selector), and it specifies 1-indexing, which adds precision. However, it does not explicitly differentiate this tool from siblings like click_visible_elements or click, so it misses the highest bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage case: click a specific element by its index among matches of a selector. There is no explicit guidance about when to use this tool instead of click, click_if_visible, or click_visible_elements, nor any mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It conveys that this is a read-only boolean existence check, which implies no mutation. However, it does not disclose whether the check is synchronous, whether it waits, or how it differs from wait_for_element_present and assert_element in terms of failure behavior.
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 one tightly worded sentence with no filler. The return value and condition are front-loaded, making it immediately scannable and appropriate for a simple predicate tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists to explain return values, but the description lacks selector syntax details and does not clarify whether the tool waits or immediately returns. For a simple existence check the core behavior is present, yet with no annotations a bit more context about its relationship to waiting and asserting tools would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only repeats the generic notion of 'selector' without explaining the expected syntax (e.g., CSS, XPath), formatting, or how to target elements. This adds little meaning beyond the schema property name.
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 states a specific operation: returning whether an element matching a selector exists in the DOM. The phrase 'exists in the DOM' semantically distinguishes this from visibility-based siblings like is_element_visible and waiting-based siblings like wait_for_element_present, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The wording implies this is for immediate presence checks rather than visibility, waiting, or assertion, but the description does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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. The word 'attempt' honestly signals possible failure, but the description does not explain side effects, waiting behavior, external dependencies, prerequisites, or what happens if solving fails. For an action tool with no annotation coverage, this is a significant gap.
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 a single concise sentence with no filler or redundancy. It front-loads the action and resource while adding a useful concrete example in parentheses, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Captcha solving is a complex, potentially non-deterministic operation, and with no annotations or parameter schema to carry context, the description should explain expected behavior more thoroughly. It does not mention timeouts, possible failuire modes, whether the agent should wait for the captcha to appear first, or how to verify success. The presence of an output schema reduces the need to describe return values, but operational context 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?
The tool has zero parameters and the schema coverage is 100%, so the description has no parameter information to add. Since there are no inputs, the baseline of 4 applies and the high-level reference to 'on the page' is sufficient context.
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 clearly states the action ('solve') and the resource ('a captcha on the page'), and gives a concrete example ('Cloudflare Turnstile'). It is distinct from sibling tools because none of them address captchas, but 'attempt' leaves some ambiguity about exactly what mechanism or outcome is involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a captcha is encountered on the page, and the example names a common scenario. However, it provides no explicit guidance about when not to use it, what to do after solving, or how to handle failure.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly implies a read operation with no side effects, but it does not disclose behavior when the key is missing, whether the value is returned as a string, or whether the sessionStorage is scoped to the current page/tab. These gaps are notable but the core read-only behavior is evident.
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 a single, focused sentence with no filler. It front-loads the operation and the target storage, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 provides the essential operation but omits important context like return value on missing key, type of the returned value, and any storage isolation caveats. It is minimally viable but leaves an agent uncertain about edge-case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 for the undocumented 'key' parameter. It does not explain what the key represents, accepted formats, or behavior for invalid keys. The description only mentions 'a value from sessionStorage', leaving the parameter semantics entirely to the agent's inference.
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 uses a specific verb ('Get') and identifies a distinct resource ('value from the page's sessionStorage'). This clearly separates it from sibling tools like get_local_storage_item and set_session_storage_item by naming the exact storage mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_local_storage_item or set_session_storage_item. There is no mention of prerequisites, exclusions, or context that would help an agent decide between storage access tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description carries the full burden since no annotations are provided. It states the action but does not disclose whether loading replaces existing cookies, whether it requires a specific file format, or what happens if the file is missing or malformed.
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 a single, focused sentence with no unnecessary words. Every word, including 'previously saved,' adds relevant context about the tool's purpose and relationship to save_cookies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description is minimally adequate. However, it omits important behavioral context such as whether loading merges or replaces existing cookies and what constitutes a valid saved file, which an agent would benefit from knowing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal meaning to the 'name' parameter beyond the schema's default value. It implies the parameter refers to a file, but it does not clarify the filename semantics, path handling, or format expectations.
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 uses a specific verb, 'load,' with a clear resource, 'cookies from a previously saved file.' This distinguishes it from siblings like save_cookies, which writes cookies to a file, and get_all_cookies, which retrieves current cookies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously saved file' implies this tool is meant to be used after saving cookies, likely with save_cookies. However, the description does not explicitly state when to use it over alternatives or mention any preconditions or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core action but does not mention side effects, reversibility, or impact on browser state (e.g., whether tabs remain active). For a simple tool, this minimal disclosure is adequate but not rich; a 3 reflects that it adds basic behavior without deeper context.
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 a single, compact sentence with no wasted words. It front-loads the essential information (the action and target) and omits any filler. This is an exemplary case of conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no annotations, the description is minimally complete, but it lacks any mention of expected return values or behavioral nuances not captured elsewhere. Given the presence of an output schema (not shown), some return information may be inferred, but the description alone does not cover all context an agent might need. A 3 reflects adequate-but-basic completeness.
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, so the schema provides complete coverage by definition. The description does not need to explain parameter meanings, and it does not introduce any confusion. Per the baseline rule for no parameters, a 4 is appropriate, as nothing is missing on this front.
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 clearly states the action: 'Minimize the browser window.' It identifies a specific verb and resource, making the tool's purpose unambiguous. It does not explicitly differentiate from siblings like 'maximize' or 'set_window_rect,' but the purpose is self-evident from the name and phrasing, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without mentioning conditions, exclusions, or related tools. An agent receives no help in deciding between 'minimize,' 'maximize,' or 'set_window_rect' beyond the literal action, so this dimension is under-served.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It discloses the core file-writing side effect but says nothing about overwrite behavior, file destination semantics, whether the operation fails silently, or any permissions/path considerations.
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 a single clear sentence with no filler or repetition. It front-loads the core action and object, making it immediately scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has no required parameters, and an output schema exists, so return values are covered. Still, the description lacks guidance on where files are saved, how name/folder interact, and when to prefer this over get_html_source, leaving the context only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter. The schema only provides default values for name and folder, so the agent receives no explanation of what 'folder' means, how paths are resolved, or whether name should include an extension.
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 action ('save'), the resource ('current page's HTML source'), and the target ('a file'). This distinguishes it from siblings like get_html_source, which retrieves HTML, and save_screenshot/save_as_pdf, which save different formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the current page's HTML needs to be persisted to a file. However, it provides no explicit guidance about when not to use it or which sibling alternative might be better, such as get_html_source for in-memory retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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. 'Get all cookies for the current session' clearly indicates a read operation, but it does not describe the return format, whether cookies from all domains are included, or how the cookies are structured. This is a minimal disclosure with meaningful gaps.
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 a single concise sentence with no filler, repetition, or extraneous information. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is adequate but leaves gaps: it does not specify what 'cookies' includes or what the return value looks like. For a low-complexity tool this is acceptable, but the ambiguity of 'current session' and lack of return format prevent a higher score.
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 the schema is empty, so the baseline is 4. The description correctly implies no arguments are needed and adds no unnecessary parameter details.
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 ('get all'), a specific resource ('cookies'), and the scope ('current session'), clearly distinguishing it from sibling tools like clear_cookies, save_cookies, and load_cookies. An agent can immediately understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as save_cookies, load_cookies, or storage item getters. It implies retrieving data for the current session but does not state scenarios or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It transparently notes that an exception is raised if the element is not found within the default timeout, which is useful. It does not cover visibility, scrolling, or wait behavior, but the core failure behavior is stated.
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 two succinct sentences, front-loaded with the operation and an illustrative example. Every sentence adds value: the first defines the action, and the second communicates an important failure behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a basic two-parameter click operation, and an output schema exists so return-value explanation is not required. Gaps include lack of detail about accepted selector syntax, whether the parent is an iframe locator or a regular element, and behavior when the parent itself is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. 'Nested inside another' and the iframe example help map parent_selector to the containing element and selector to the target element, but exact selector syntax and the precise parent-child relationship are not fully detailed.
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 names a specific verb ('Click') and resource ('an element nested inside another'), with an iframe example that clarifies the intended use. It is reasonably distinct from sibling tools like click_link or click_nth_element, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear condition for use: when the target element is nested inside a parent element or iframe. However, it does not explicitly say when not to use this tool or mention alternative click-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states the action itself, omitting details such as whether the scroll is instantaneous or animated, whether it triggers any events or lazy loading, or whether it operates on the main page only. This is minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. It is front-loaded and immediately conveys the complete action. It could not be briefer while retaining meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 minimally adequate: it names the action and target. However, given the wide range of sibling scrolling tools, some context about when to choose scroll_to_bottom over alternatives would improve completeness. The missing usage guidance detracts from full contextual richness.
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, so there are no parameter semantics to clarify. The description correctly adds no redundant parameter information, and the schema fully covers the empty property set. A baseline score of 4 is appropriate for a no-parameter tool.
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 action: scroll to the bottom of the page. It specifies a concrete resource (the page bottom) and is easily distinguished from sibling tools like scroll_to_top, scroll_up, and scroll_down. The purpose is unambiguous and directly matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus scroll_down, scroll_into_view, or scroll_to_top, nor does it mention any caveats like lazy-loaded content or scrollable containers. The agent receives no explicit decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 states the core effect ('scroll to the top of the page'), which is minimally sufficient, but it does not reveal details such as whether the scroll is instant or animated, whether it operates on the main page only, or what happens on a non-scrollable 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 a single, front-loaded sentence with no filler. Every word earns its place, and the length is appropriate for a zero-parameter, single-action tool.
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?
Given the tool's trivial complexity, zero parameters, and presence of an output schema, the description is nearly complete. The only notable gap is the lack of contextual guidance about how this tool relates to the many sibling scrolling and page-navigation tools, but for a no-argument action, the description covers the essential operation.
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 the schema coverage is 100%, so there is no parameter meaning that the description needs to add. The baseline of 4 applies because the absence of parameters makes semantic explanation unnecessary.
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 states a specific verb ('scroll') and target ('top of the page'), making the tool's basic purpose clear. It does not explicitly differentiate itself from sibling scroll tools such as scroll_to_bottom or scroll_into_view, but the resource is specific enough for basic identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like scroll_to_bottom, scroll_up, scroll_down, or scroll_into_view. There is no mention of exclusions, prerequisites, or typical scenarios, leaving usage entirely 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully explains the exact match requirement, that leading/trailing whitespace is ignored, the 7-second timeout, and that an exception is raised on mismatch. It could go further by noting whether it waits/polls versus performs a single check, but the provided details already add meaningful behavioral clarity.
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 two sentences with no filler. The core action is front-loaded, and the timeout, whitespace handling, and failure behavior are stated compactly.
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 one-parameter assertion tool, the description covers the key behaviors: expected input, comparison semantics, timeout, and failure mode. Because an output schema exists, return-value documentation is not required. It could be slightly more complete with an explicit reference to the current page or an example, but nothing essential is missing for calling it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 only implicitly identifies the single 'title' parameter as the expected title; the parameter name is self-descriptive and the whitespace behavior clarifies how the value is compared, but no explicit parameter semantics are provided beyond what can be inferred.
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 clearly states the action ('Assert') and the resource ('the page title'), with a precise caveat about whitespace. It is distinguishable from siblings like assert_text or get_title by focusing on the page title specifically, but it does not explicitly name or distinguish itself from those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus related assertion or title-related tools such as get_title, assert_text, or assert_url_contains. The intended context is implied by the name and description, but the description does not provide any when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral information by stating that each result includes tag name and text, and the operation appears read-only. However, it does not say what happens when no elements match, whether the tool waits for elements, or how the timeout parameter affects behavior. With no annotations provided, these details are missing.
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 a single, front-loaded sentence with no filler. Every word contributes to the core meaning and it is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple two-parameter query tool with an output schema, the description captures the core operation and return values. Yet it is incomplete on timeout behavior, no-match behavior, and differentiation from sibling tools. It is minimally viable but leaves important operational questions open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description had to compensate for both parameters. The word 'matching' weakly ties to the selector parameter, but it does not clarify selector format or semantics. The timeout parameter is not mentioned at all, even though the default null suggests meaningful behavior.
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 uses a specific verb and resource: 'Find all matching elements' and explicitly states the return payload: 'tag name + text for each.' This makes the tool easy to distinguish from similar siblings like find_element_info (single element) and find_elements_count (count only). The scope ('all') is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The behavior implies use when you need tag and text for every matching element, but there is no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or explain when to prefer find_element_info or get_text over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but does disclose the core write behavior and the storage scope ('page's localStorage'). It does not mention overwriting existing keys or persistence details, but 'set' and 'localStorage' reasonably imply those semantics.
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?
A single, front-loaded sentence with no filler; every word earns its place. The structure is ideal for a two-parameter setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple localStorage setter with an output schema and obvious required parameters, the description covers the essential action. However, with no annotations, usage guidance, or parameter elaboration, it leaves some context (overwrite behavior, when to choose this over session storage) to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain what 'key' or 'value' represent, only that a value is set. The parameter names are somewhat self-explanatory, but the description adds no semantic detail beyond the 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?
Description uses a specific verb ('Set') and resource ('page's localStorage'), clearly distinguishing it from get_local_storage_item and set_session_storage_item. The action and target are unambiguous despite being terse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided; however, the wording implies it is for setting localStorage values as opposed to getting them or using session storage. This is sufficient for a straightforward setter but lacks any exclusionary hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It clearly states the write operation and the target storage, but it does not mention overwrite behavior, session/tab scoping, or storage constraints. The wording is honest but minimal.
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 a single sentence with no filler. It front-loads the action and resource immediately and earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the core operation is captured. However, because there are no annotations and the description is very brief, an agent is left to infer details like overwriting behavior and the difference between sessionStorage and localStorage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate. It only says 'a value' and does not explain the roles of 'key' and 'value' beyond their obvious names. The semantics are self-evident enough to avoid a 1, but the description adds no real parameter insight.
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 uses a specific verb ('Set') and a precise resource ('the page's sessionStorage'). It clearly distinguishes this from sibling tools like get_session_storage_item and set_local_storage_item by naming the exact storage mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when writing a value to sessionStorage. However, it does not explicitly mention alternatives such as set_local_storage_item or state when not to use this tool, leaving some usage decisions 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?
With no annotations, the description carries the behavioral burden and covers key runtime behavior: the default 7-second timeout when timeout is 0/None and the exception on element-not-found. It leaves the event behavior of direct value setting unstated, but 'directly' hints that it bypasses keystroke simulation.
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?
Three short sentences, front-loaded with the main action and each sentence adding distinct information: purpose/examples, timeout default, and failure behavior. 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?
For a simple 3-parameter tool, the description supplies the essential action, a default, and the error case, and the output schema covers return expectations. It is only mildly incomplete in not addressing how set_value relates to typing/sibling functions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 parameters; it does address timeout with a concrete default rule. It does not explain what selector should select or how text maps to the value being set, leaving both required parameters to be guessed.
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 states a specific action ('Set an input's value directly') and clarifies with concrete examples (sliders, fast form fills). It does not explicitly differentiate from sibling type_text or send_keys, but the direct-assignment phrasing makes the core purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives context for when to use the tool through examples ('for sliders, fast form fills'). However, it never names alternatives like type_text or send_keys or states when not to use set_value, so the selection rule is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 states the core action (switching to a tab) and the index source, but omits possible edge-case behaviors like invalid-index handling, whether the tab gains focus, or any side effects. This is minimal but not misleading.
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 a single sentence with no wasted words. The core action and the parameter source are front-loaded, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description references get_tabs to define the index, but get_tabs is not among the listed sibling tools (only get_tabs_count is present). This leaves the agent without a clear way to obtain valid tab indices. It also does not cover error conditions or edge cases. Given the tool's simplicity and existing output schema, this is a notable completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and type (integer), with no description. The description adds meaning by defining the tab_index as the index returned by get_tabs, which goes beyond the schema. However, it does not explicitly clarify zero- or one-based indexing, though referencing get_tabs implies compatibility.
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 uses a specific verb ('Switch') and resource ('tab'), and specifies the input basis ('by its index as returned by get_tabs'). This clearly distinguishes it from siblings like switch_to_newest_tab, open_new_tab, and close_active_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a tab index from get_tabs is available, but it does not explicitly state when to use this over alternatives such as switch_to_newest_tab or open_new_tab. No exclusions or when-not guidance are provided.
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 appropriately discloses the key behavioral trait: it raises an exception if the substring is not found within 7 seconds. This goes beyond the basic assertion semantics and tells the agent about the timeout and failure mode.
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 two short sentences with no filler or redundant information. The core assertion is stated first, and the failure behavior is placed immediately after, making it easy to parse quickly.
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 one-parameter assertion tool with an output schema available, the description covers the essential behavior, the failure mode, and the timeout. It is slightly incomplete because it does not distinguish itself from the similarly named assert_url sibling, but this is a minor gap for such a straightforward tool.
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 schema provides only the parameter name 'substring' with no description, but the tool description clarifies that the substring is the expected value to search for in the current URL. This adds meaningful semantic context to the single required parameter, though it does not discuss case sensitivity or matching details.
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 clearly states that the tool asserts the current URL contains a given substring, and it defines the exact condition being checked. It does not explicitly contrast itself with the sibling assert_url tool, so it loses the last point for 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not say when to prefer this tool over assert_url, wait_for_text, or other URL-checking tools. No usage context, prerequisites, or alternatives are mentioned, leaving the agent to infer appropriate timing from the tool name and behavior.
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 burden of behavioral disclosure. It proactively explains the default timeout behavior and the exception raised when the element is not found, which is valuable. It does not mention the scroll parameter's default behavior or visibility requirements, but the core failure/success semantics 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary purpose, and includes a concrete example. Every sentence adds useful information without repetition or 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 relatively simple clicking tool, the description provides selector syntax, timeout semantics, and error behavior. The output schema exists so return values are not a gap. The only meaningful omission is the scroll parameter's behavior and any interaction with visibility.
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?
Since schema description coverage is 0%, the description must compensate. It adds real meaning to 'selector' by specifying CSS selector or text syntax, and explains the timeout parameter's default behavior. However, the 'scroll' parameter is not described at all, leaving one of three parameters undocumented.
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 clearly states the action ('click') and the resource (an element matched by CSS selector or text), including an explicit example. It is unambiguous, though it does not explicitly differentiate itself from sibling click variants such as click_visible_elements or click_nth_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what selectors are accepted but provides no guidance on when to use this tool versus the many sibling click-related tools. No exclusions or alternative recommendations are given, so the agent must infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action and targeting strategy; it does not mention waiting behavior, handling of multiple matching links, what happens if the link is not visible, or that clicking may trigger navigation. This is minimal transparency for an interaction 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 a single, front-loaded sentence with no filler. Every word adds value: 'Click', 'link', '<a> tag', and 'visible text' are all informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description covers the core operation adequately. However, given the large set of sibling click tools and missing usage guidance, an agent could be uncertain about prerequisites or alternative selection. The description is minimally viable but not fully complete.
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%, so the description must compensate. It does so by defining link_text as the visible text of the <a> tag, giving the single parameter meaningful context beyond the bare schema label 'Link Text'.
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 specifies a clear verb (Click), a specific resource (a link / <a> tag), and the targeting method (by its visible text). This distinguishes it from sibling tools like click_nth_element (by index) or click_visible_elements (by selector).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have the visible text of a link, but it does not explicitly state when to prefer this over alternatives like click, click_if_visible, or nested_click. No exclusions or selection criteria are provided, leaving the agent to infer the appropriate context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. The verb 'get' makes clear this is a read operation with no side effects, but it does not disclose behavior on missing elements or attributes (e.g., whether it returns null or throws), which is moderately important for an automated agent.
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?
A single, front-loaded sentence with no filler. Every word contributes: the scope ('one'), the action ('get'), the target ('attribute's value'), and the container ('from an element').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with only two string parameters, this is close to minimally viable. However, the lack of annotations and output schema means the agent still needs to infer return value type and error behavior, leaving some important operational ambiguity for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 source of parameter meaning. It maps 'selector' to identifying the element and 'attribute' to the attribute whose value is returned, which adds useful context beyond the raw property names, though it does not explain selector syntax or attribute name conventions.
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?
States a specific verb, resource, and scope: retrieves a single attribute value from a web element. The word 'one' differentiates it from the sibling tool get_element_attributes, so an agent can distinguish them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage: use when you need exactly one attribute value of an element. However, it does not explicitly contrast with alternatives like get_element_attributes or explain when not to use it, leaving the agent to infer based on singular/plural wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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. It only states what the tool does ('get...') but does not disclose that it is a read-only operation, that it has no side effects, or any error/edge-case behavior. The description adds little beyond restating the tool's name.
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 a single, concise sentence with no redundant words. It is appropriately sized for a tool of this simplicity and front-loads the action and object without any 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 the tool's simplicity (zero parameters), the presence of an output schema (which presumably specifies the return type), and the clear semantic meaning of 'number of tabs', the description is complete enough for an agent to know what to expect. No critical information 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?
The tool has zero parameters, and the schema coverage is 100%. According to the rubric, a baseline of 4 is appropriate for zero-parameter tools since there are no semantics to clarify. The description correctly omits any parameter-specific details.
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 action ('Get') and the resource ('how many tabs are currently open'), which is specific and distinct from sibling tools like switch_to_tab or open_new_tab. It unambiguously communicates that the tool returns the count of open tabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or comparisons to related tab-management tools. The intended usage is only implied by the tool's purpose.
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 behavioral burden. It directly states that execution pauses for a number of seconds, and for a simple sleep operation the core behavior is clear without hidden side effects or destructive implications.
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 one short, direct sentence with no filler. The action, target, and unit of measurement are front-loaded, and every word contributes to the meaning.
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 single-parameter utility with an output schema, the description plus schema is sufficient to make a correct call. The only notable missing context is usage guidance relative to condition-based wait tools, which is already reflected in the usage guidelines score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by adding meaning to the 'seconds' parameter. It only paraphrases the schema's field name and adds no constraints about range, decimals, positivity, or maximum allowed 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 names a specific verb ('Pause'), a target ('execution'), and the exact duration unit ('seconds'). This clearly distinguishes it from the conditional wait_for_element_* and assert_* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use a fixed sleep versus the many wait_for_* alternatives. The agent is left to infer that sleep is a condition-free delay rather than an element/text wait, which is a meaningful usage gap in automation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden; 'end the session' conveys finality and is a useful disclosure. However, it does not mention side effects such as loss of browser state, closing all tabs, or that a new browser must be started before further actions.
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 a single short sentence that leads with the action and includes no filler or redundant details. It is 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, terminal action this description is largely complete, and the presence of an output schema means return values do not need to be described. It lacks only explicit usage context and side-effect caveats, which keeps it from a 5.
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 the input schema is empty, so there is no parameter information for the description to add. The baseline for a zero-parameter tool applies here.
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 uses a specific verb and resource ('Close the browser') and adds that the session is ended, making the operation unambiguous. In a sibling list that includes close_active_tab, this wording clearly identifies a browser-level shutdown rather than a tab-level action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states only what the tool does, not when to call it or how it relates to alternatives such as close_active_tab. There is no mention of end-of-session workflow, prerequisites, or situations where this tool should be avoided.
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 that the highlight is brief, is meant for visible/headed browsers, and raises an exception if the element is not found within the default timeout. This is meaningful beyond the tool name, though it does not detail side effects or non-mutating behavior.
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 efficient: two short sentences that front-load the core action and then add the timeout/exception behavior. No unnecessary words or repetition.
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 single-parameter tool with an output schema, the description covers the main purpose, the environment constraint, and the failure mode. The main gap is the unspecified selector syntax, which would be more critical if this were a more complex or destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify what format 'selector' should take (CSS selector, XPath, etc.) or whether it targets the first match. The agent is left to infer the parameter semantics from the parameter name alone.
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 uses a specific verb and resource: 'highlight an element', and adds the useful context of a visible/headed browser. It is distinguishable from the large sibling list of click/input/wait tools, though it does not explicitly name a sibling alternative.
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 gives a clear usage context: 'useful when narrating actions on a visible/headed browser'. It does not explicitly state when not to use it or name alternatives, but the guidance is sufficient for an agent to understand the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the effect, but adds nothing beyond the literal action—no mention of side effects on window state, viewport, or subsequent operations. This is minimal but not misleading.
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?
A single, direct sentence that fully conveys the operation without wasted words. It is front-loaded and appropriately sized for the tool's simplicity.
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 zero-parameter, simple browser action, the description is essentially complete. The only gap is the absence of guidance on how this relates to sibling window-management tools, but that gap is more about usage than operational completeness.
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, so the schema leaves nothing undocumented. The baseline of 4 applies because there is no parameter information for the description to supplement.
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?
States a specific verb ('Maximize') and a clear resource ('the browser window'), making the action unambiguous. It is easily distinguished from the sibling 'minimize' tool, which has the opposite effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'minimize' or 'set_window_rect'. An agent must infer from the name alone that this maximizes the window; there is no explicit context about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the optional navigation and switching behavior, but does not note what happens when url is null, whether the new tab is opened as a background tab when switch_to is false, or any side effects like accumulation of tabs. Basic behavior is covered, but richer context is missing.
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?
A single sentence that is front-loaded with the action and includes both optional behaviors with no filler. Efficient and scannable.
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 two-parameter optional tool with an output schema, the description covers the essential call semantics. It lacks details on default switching behavior (though the schema supplies this) and edge cases, but an agent can infer the correct invocation. Missing usage guidance is the main gap.
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%, so the description must compensate. It maps both parameters to behavior: 'navigating' corresponds to url and 'switching' to switch_to, giving semantic meaning beyond property names. It does not explicitly name the properties or explain null-URL behavior, but the mapping is clear and the schema provides 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 uses a specific verb ('Open'), names the resource ('new browser tab'), and specifies the optional actions ('navigating and switching to it'). It is clearly distinct from sibling tab tools such as switch_to_tab and close_active_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like navigate, switch_to_tab, or switch_to_newest_tab. There are no exclusions, prerequisites, or alternative recommendations, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that an exception is raised if the element or option is not found within a 7-second default timeout. However, it does not mention side effects, whether existing selections are replaced, or what happens if multiple matches exist.
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?
Two short sentences with no filler. The core purpose is front-loaded, and the timeout/exception behavior is added as a second useful sentence without redundancy.
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 two-parameter select tool, the description covers purpose, failure behavior, and timeout. The main missing detail is selector format, but the tool is simple and the parameter name is reasonably self-explanatory. An output schema exists, so return values are covered elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the only source of parameter meaning. 'by its visible text' clarifies that the option parameter is the displayed text, but the description does not explain what format dropdown_selector should take (CSS selector, XPath, etc.). Some meaning is added, but not enough to fully compensate.
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 names a specific verb ('Select'), a resource ('a <select> dropdown option'), and a distinguishing criterion ('by its visible text'). This clearly separates it from sibling tools select_option_by_value and select_option_by_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by its visible text' implies this tool is for selecting based on text rather than value or index, but it does not explicitly state when to use this over select_option_by_value or select_option_by_index. Usage guidance is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states the mutation and the target scope ('current window'), but it does not mention coordinate units, origin, constraints on width/height, or failure behavior. This is acceptable but minimal.
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?
A single compact sentence that front-loads the action and target. Every word contributes meaning and there is no repetition or 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 mutator with four self-explanatory integer parameters and an output schema, the description is nearly complete. The main gap is the lack of explicit coordinate-system or unit context, but the operation is simple enough that an agent can likely call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 groups x/y as position and width/height as size, which adds partial meaning beyond the bare parameter names, but it leaves units and coordinate semantics implicit.
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 names a specific verb ('Set'), a specific resource ('the current window'), and the two things being changed ('position and size'). It is immediately distinguishable from sibling tools like get_window_rect, maximize, and minimize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is used to reposition/resize the active window, but it does not explicitly state when to use this over maximize, minimize, or get_window_rect. The usage context is inferable, not spelled out.
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 burden. It explicitly discloses the default 7-second timeout when 0 or None is passed and states that an exception is raised if the element remains visible. This is strong behavioral disclosure for a simple wait operation.
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 three concise sentences: the action is front-loaded, followed by the timeout rule and failure behavior. There is no filler or redundant content.
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 wait utility, the description covers the trigger condition, timeout behavior, and exception on failure, which are the essential details for invocation. It does not define visibility precisely or explain selector format, but those are minor given the tool's simplicity 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds important meaning for the timeout parameter, including the 0/None default behavior. However, the selector parameter is not described beyond its name and the general reference to 'an element', leaving a partial gap given the schema has no parameter descriptions.
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 uses a specific action ('Wait until') and target state ('element is no longer visible on the page'), making the tool's purpose clear. It is semantically distinct from siblings like wait_for_element_visible and wait_for_element_absent, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear by describing a wait condition and failure behavior, but it does not explicitly say when to prefer this over closely related alternatives such as wait_for_element_absent. Usage is implied rather than guided.
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 burden, and it discloses two important behaviors: the default timeout of 7 seconds when timeout is 0 or None, and the exception raised if visibility is not achieved. This gives the agent clear failure-mode expectations. It does not describe return behavior, but that is less significant for a wait operation.
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?
Three short sentences, each with a distinct purpose: what the tool does, timeout behavior, and failure behavior. The main action is front-loaded, and there is no redundant or filler wording.
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 two-parameter wait tool, the description covers the essential behavior, timeout default, and error condition, and an output schema exists so return-value details are not required. It does not describe selector syntax or explicitly distinguish visibility from presence, which would make it fully complete. Overall, an agent has enough to invoke it correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the timeout parameter by specifying the null/0 default and the 7-second fallback, which is absent from the schema. The required selector parameter is only indirectly represented as 'element', and no selector syntax or format is given. Schema description coverage is 0%, so this remains a partial 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 identifies a clear verb and resource: waiting until an element is visible on the page. The visibility condition and timeout failure are stated, so the tool's core job is unmistakable. It does not explicitly contrast with sibling wait/assert variants, which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when the agent must block until an element becomes visible. It does not state when to prefer wait_for_element_present or assert_element_visible, nor any exclusions. No alternatives or when-not-to-use guidance is provided.
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 itself must disclose behavior. It does so effectively by explaining the default timeout of 7 seconds when timeout is 0 or None, and by stating that an exception is raised if the element is not found within that timeout. This gives an agent a clear model of the tool's wait-and-fail behavior.
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 two sentences with no filler. The primary purpose is stated first, followed by the timeout default and exception behavior. Every sentence contributes essential operational information.
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 assertion tool, the description covers the essential behavioral contract: presence check, timeout semantics, and failure outcome. The only notable gap is the lack of detail about selector syntax, but the parameter name and tool name make the intended value reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 adds meaningful semantics for the timeout parameter, clarifying that 0 or None triggers a 7-second default. However, it does not define or constrain the selector parameter beyond its obvious relationship to the tool's purpose, nor does it mention supported selector formats.
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 precise action: asserting that an element is present in the DOM. It differentiates itself from the sibling assert_element_visible by specifying DOM presence rather than visibility, and the exception behavior reinforces the assert semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the core use case clear—asserting element presence with a configurable timeout. However, it does not explicitly contrast with sibling tools like wait_for_element_present or assert_element_visible, so an agent receives no guidance on when to choose this tool over those alternatives.
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 states that the assertion waits up to 7 seconds and raises an exception on mismatch, which is useful and non-obvious. It does not cover finer details like URL normalization or case sensitivity, but the core failure 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?
Two short, efficient sentences. The main purpose is stated first, and the timeout/exception behavior is added in the second sentence without any redundant wording.
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 one-parameter assertion tool, the description provides the key semantics: exact matching, a timeout, and failure behavior. The existence of an output schema reduces the need to describe return values. The main remaining gap is the precise URL format expected, but overall the tool is adequately described for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the required 'url' parameter, so the description must compensate. It clarifies that the parameter is the expected URL to compare against the current page URL, but it does not specify the expected format (e.g., fully qualified, with protocol, trailing slash handling). This is partial compensation for a single simple parameter.
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 action and resource: assert that the provided URL matches the current URL exactly. The word 'exactly' clearly distinguishes it from the sibling assert_url_contains, eliminating ambiguity about what is being verified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'exactly' keyword implies this tool is for exact-match assertions and not for partial/substring matches, which would be handled by assert_url_contains. However, no explicit guidance is given about when to choose this over alternatives or when not to use it, leaving the usage 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?
With no annotations provided, the description carries full behavioral disclosure. It clearly explains the timeout default (7 seconds when 0 or None) and the exception behavior when the element isn't found, which are important operational details not visible in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The primary action is front-loaded, and each subsequent sentence adds distinct, valuable behavior (timeout default and exception). Perfectly sized for the tool's complexity.
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 two-parameter tool with an output schema, the description covers the essential behavior: action, timeout default, and failure mode. It lacks explicit selector format guidance and any note about interaction side effects, but these are minor given the simplicity and the standard pattern shared with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 adds meaningful timeout semantics (0/None means 7 seconds) and implies the selector identifies the element. However, it does not clarify the selector format (e.g., CSS selector) or any constraints on timeout values beyond the default, leaving a partial gap.
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 action ('Clear an input field') and a clear resource. The verb is unambiguous and distinct from sibling tools like type_text, send_keys, or set_value, so an agent can immediately identify what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The action itself implies the use case: clear an input field. However, there is no explicit guidance about when to use it versus alternatives like set_value('') or send_keys, nor any mention of prerequisites (e.g., element must be visible). This is adequate but leaves routing to the agent's 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?
With no annotations, the description carries the full burden, and it does add meaningful behavioral context: it warns that arbitrary JavaScript can be run on any site and that precautions are necessary. This signals the tool's potentially destructive or side-effectful nature beyond what the name and schema convey. It could also mention result serialization or async behavior, but the risk disclosure is substantial.
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?
Three sentences, each earning its place: the first defines the core behavior, the second disambiguates the alias, and the third supplies a necessary safety warning. The description is appropriately sized and front-loaded with the primary purpose.
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 one-parameter tool with no output schema, the description covers what the tool does, what the parameter represents, that it returns a result, and the key safety consideration. The only meaningful gap is the lack of usage-routing guidance relative to the large set of sibling tools, but the core calling contract is otherwise complete.
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%, so the description must compensate; it does by clarifying that 'expression' is a JavaScript expression evaluated in the page context and that a result is returned. This is meaningful for the single required parameter, even though it lacks examples or advanced details.
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 action: evaluate a JavaScript expression in the page context and return the result. It is distinct from all sibling tools, which are focused on clicks, typing, navigation, waiting, and assertions, and the explicit 'Equivalent to execute_script' further anchors the tool's identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use evaluate versus the many dedicated sibling tools, nor any exclusions such as 'prefer specific click/type/assert tools when possible.' The equivalence to execute_script is mentioned, but execute_script is not among the sibling tools, so it does not help an agent choose between alternatives.
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 burden of behavioral disclosure. It does disclose the non-obvious cache behavior ('By default, ignores the browser cache on reload'), which is valuable for an agent deciding whether to use it. It does not mention side effects such as losing unsaved page state, but this is fairly inherent to a reload action.
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 two short sentences with no filler. It front-loads the core action, then adds the useful browser analogy and the cache behavior. Every sentence earns its place.
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?
This is a low-complexity tool: one optional boolean parameter, no required inputs, and an output schema exists. The description fully explains what the tool does and its most important behavioral nuance. It is complete enough for reliable invocation, though a brief note about when to set ignore_cache to false would make it fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description coverage for its only parameter, ignore_cache. The description adds that cache is ignored by default, which helps explain the default true value, but it does not explicitly state the behavior when ignore_cache is false. Thus the description partially compensates for the schema gap but leaves the parameter semantics slightly implicit.
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 uses a specific verb and resource: 'Reload the current page.' It also clarifies the action with the analogy 'Same as clicking the Reload button in the web browser,' which distinguishes it from navigation tools like go_back, go_forward, and navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when the tool is relevant by equating it to the browser Reload button, and it adds the cache behavior as a key condition. However, it does not explicitly contrast this with alternatives or state when not to use it, so usage guidance is implied rather than fully specified.
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?
The description discloses a key behavioral trait: it raises an exception if the element or option is not found within the default timeout of 7 seconds. Since no annotations are provided, this error/timeout information is essential and goes beyond the basic action; however, it does not detail other side effects or prerequisites.
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?
Two sentences with no redundancy; the core action is front-loaded and the exception behavior is stated compactly.
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 the action, the index semantics, and error/timeout behavior. It lacks explicit alternative routing and selector details, but for a simple tool with an output schema, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only clarifies that 'option' is a 0-based index, which adds meaning to that parameter. It does not explain the format or semantics of 'dropdown_selector' beyond implying it identifies the <select> element. With 0% schema description coverage, this is only partial compensation.
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 ('Select'), a specific resource ('a <select> dropdown option'), and the mode ('by its 0-based index'). This clearly distinguishes it from sibling tools like select_option_by_text and select_option_by_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for selecting a dropdown option based on its index, but it does not explicitly state when to choose this tool over the text/value-based alternatives or mention any prerequisites. There is no explicit when/when-not guidance, only the implied usage from the action.
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 it does disclose important behavior: it raises an exception if the element or option is not found, and it specifies the default timeout of 7 seconds. This goes beyond the bare operation and gives an agent a clear failure model, though it does not cover event side effects or visibility requirements.
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 two sentences with no filler: the main action is stated first, and the failure/timeout behavior is appended. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter interaction tool, the description covers the core action and failure mode, but it leaves the dropdown_selector parameter underspecified and does not mention how to distinguish this tool from select_option_by_text/index. An output schema exists, so return-value details are not required, but slightly more context would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 clarifies the meaning of the option parameter ('value attribute') but leaves dropdown_selector's expected format unspecified (CSS selector, XPath, label, etc.). This is only partial compensation for two undocumented required parameters.
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 object: 'Select a <select> dropdown option by its value attribute.' It clearly identifies the resource and the selection mechanism, and the phrase 'value attribute' distinguishes this from sibling tools select_option_by_text and select_option_by_index without needing to open 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need to select an option by its value attribute. It does not explicitly name select_option_by_text or select_option_by_index as alternatives, but the value-attribute qualifier provides enough direction for an agent to choose among the sibling select_option 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?
No annotations are provided, so the description carries the full burden of behavior disclosure. It adds useful behavioral details: the default timeout behavior (0 or None becomes 7 seconds) and the exception raised when the element isn't found. This goes beyond a basic action statement and sets clear expectations for failure and waiting.
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 concise: the primary behavior is stated in the first sentence, followed by two short sentences covering timeout and error behavior. Every sentence adds useful information with 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?
For a simple keystroke tool, the description covers the main behavioral expectations: it does not clear the element, it waits with a default timeout, and it raises an exception when the element is missing. With an output schema present and straightforward parameters, this is sufficiently complete, though explicit guidance on choosing between send_keys and type_text would improve clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 adds meaningful timeout semantics beyond the schema. However, it does not elaborate on the selector or text formats, leaving those to be inferred from their names and the phrase 'element' and 'keystrokes'. Partial compensation only.
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 action: 'Send keystrokes to an element' and highlights the key differentiator 'without clearing it first'. This distinguishes it from related input tools like clear_input and type_text, and gives an agent a precise understanding of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without clearing it first' implicitly signals this tool is for scenarios where existing element content should be preserved, but the description does not explicitly state when to prefer it over type_text, set_value, or other sibling input tools. No alternatives or exclusions are named, so usage guidance remains implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states the active-tab change, but it does not describe what happens when no other tab exists, whether the current tab is closed, or whether the operation returns any tab information. The core action is unambiguous, but edge-case behavior is undisclosed.
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 a single, front-loaded sentence with no filler or redundant phrasing. It earns its place by immediately stating the action and target.
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 zero-parameter, single-action tool, the description is mostly complete. The action is fully described, and no return-value details are needed since an output schema exists. The only gaps are comparative context with switch_to_tab and behavior when no newest tab exists.
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 the schema already fully represents this with an empty properties object. There is no parameter meaning for the description to add, so the baseline 4 applies.
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 uses a specific verb, 'Switch,' and a clear target, 'the most recently opened tab.' This distinguishes it from sibling tools like switch_to_tab, which implies switching to a user-specified tab, and open_new_tab, which creates a new tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies the intended use case: the agent should call this when it needs to focus on the newest tab. However, it does not explicitly state when to prefer this over switch_to_tab, nor does it mention any exclusions or prerequisites, such as whether a tab must already exist.
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 adds meaningful details: default timeout of 7 seconds when 0 or None is passed, and exception-raising behavior on timeout. This covers the most important runtime behaviors, though it could further clarify polling behavior or that visibility is not required.
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?
Three concise sentences with no filler. The core purpose is front-loaded, followed by timeout semantics and failure behavior. Every sentence adds essential information.
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 wait tool, the description covers purpose, timeout default, and failure mode. An output schema exists, so return-value details are not required. The main gap is the lack of explicit guidance on choosing this tool over sibling wait/assert variants, though the 'present in DOM' phrasing partially addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 explains the timeout parameter well, including the special 0/None default behavior. The selector parameter is only minimally described by its name, but 'element' in the description makes its role understandable.
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?
States a specific action: wait until the element is present in the DOM. The wording 'present in the DOM' distinguishes it from sibling tools like wait_for_element_visible, making the tool's purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need to wait for DOM presence—but does not explicitly guide selection among siblings such as wait_for_element_visible, wait_for_element_absent, or assert_element. No exclusions or alternative-referencing guidance is provided.
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 disclosure burden. It usefully reveals the default 7-second timeout for 0 or None, and states that an exception is raised if the element is not visible within the timeout. This goes beyond a simple restatement of the tool name, though it does not cover polling behavior or exact matching details.
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 two sentences with no filler. The primary behavior comes first, followed by timeout defaults and failure behavior, making it easy to scan and understand.
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 the main behavior, default timeout, and exception on failure, which is sufficient for a simple wait utility. Since an output schema is available, return-value details are not required. Minor gaps include no mention of the selector default or how quickly polling occurs, but these do not block correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 clarifies that `text` is a substring match and explains the timeout default semantics for 0 or None, which is valuable. However, it does not explain the `selector` parameter, relying on the schema's default value instead.
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 clearly states the tool's action: wait until a text substring appears within an element. It is distinct from sibling element-wait tools because it focuses on text content, but it does not explicitly name alternatives or contrast with assert_text or wait_for_element_visible.
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 a clear context: use when you need to wait for text to appear rather than immediately asserting or checking. It does not explicitly discuss when not to use it or mention sibling alternatives, but the wait-for-text purpose is immediately evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the behavioral disclosure burden. The verb 'Get' clearly indicates a non-mutating read operation, and the zero-parameter design reduces risk, but no explicit statement is made about side effects, browser-session requirements, or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, restatement, or redundant detail. Every word adds semantic value.
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 getter with an output schema available, the description covers the essential context: what is returned and that it reflects the current browser. No additional usage conditions or alternatives are necessary for correct invocation.
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?
There are no parameters and the schema already declares an empty object with 100% coverage, so no parameter documentation is needed. The description reinforces that the output concerns the user agent string, which is enough for a parameterless tool.
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 'Get the browser's current user agent string' uses a specific verb (Get), a specific resource (the user agent string), and a scope qualifier (current browser). It is immediately distinguishable from all sibling getters because no other tool targets the user agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or exclusion guidance is provided, and no alternative sibling exists for fetching the user agent. The intended usage is implied by the description: call this tool when the current user agent string is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. 'Get' clearly signals a read-only operation, but no additional detail is given about coordinate system, units, or lack of side effects. For a trivial getter this is adequate but not rich.
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?
A single, front-loaded sentence with no filler. Every word contributes meaning, and the description is appropriately sized for a zero-parameter read operation.
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 has no parameters, has an output schema, and is a simple read operation, the description fully covers what an agent needs to invoke it correctly. The sibling set_window_rect provides enough contrast to disambiguate direction.
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 takes zero parameters and schema description coverage is 100%, so there is nothing for the description to add. The baseline of 4 applies because no parameter documentation burden exists.
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 uses a specific verb ('get'), names the resource ('current window'), and specifies the exact data returned ('position and size'). It clearly distinguishes this read tool from the sibling set_window_rect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose obvious but provides no explicit guidance on when to use it versus alternatives like set_window_rect or maximize/minimize. Usage context is implied by the verb and resource, but no alternatives or exclusions are named.
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 must carry the behavioral burden. It discloses whitespace normalization, default selector, 7-second timeout fallback, and exception behavior on missing elements or assertion failures. It does not fully clarify whether the tool polls/waits or whether it only considers visible text, but the coverage is quite 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 front-loaded with the core purpose and then efficiently covers defaults and failure semantics. Each sentence contributes useful information, with only minor redundancy around the timeout explanation.
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 three-parameter assertion tool with an output schema, the description covers essential behavior, defaults, and error semantics. It is adequately complete even without explicit alternative routing, which is a minor rather than critical omission.
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?
Given 0% schema description coverage, the description compensates fully: 'text' is the expected exact content, 'selector' is a CSS selector defaulting to 'html', and 'timeout' is in seconds with 0/None mapped to 7 seconds. Every parameter receives meaningful context 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 states a specific verb ('assert') and resource ('element's text'), and clearly defines that the match must be exact. The qualifier 'exactly' differentiates it from looser text assertions such as assert_text, making its purpose immediately identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its exact-match assertion purpose and provides default selector/timeout behavior, but it does not explicitly state when to choose this tool over alternatives like assert_text or wait_for_text. The selection criteria are left largely 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?
With no annotations, the description carries the full burden. It discloses the conditional no-op and timeout wait behavior, which goes beyond the schema. However, it does not state what happens when the timeout expires before the element appears, which is a behavior an agent would need to predict.
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?
Two concise sentences, core condition first and timeout detail second. No filler or repetition of the schema.
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 guarded click tool with an output schema available, the description covers the main contract: conditional no-op and optional wait. Minor gaps remain around timeout expiry behavior and selector syntax, but these don't prevent selection of the tool; they might affect precise invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives real semantics to `timeout` (wait up to that long for appearance before clicking) and implies that `selector` identifies the target element. It does not specify selector syntax or matching rules, and since the schema has zero parameter descriptions, the agent must infer selector format from context.
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?
States a specific conditional action on an element: click only if visible, no-op otherwise. This distinguishes it from sibling click tools such as `click`, `click_visible_elements`, and `click_nth_element` by making the visibility guard and no-op behavior explicit.
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 clearly implies when to use it: when a click should succeed silently or do nothing unless the element is visible, and optionally wait for it to appear. It does not explicitly name alternatives or say when not to use it, so it falls short of a full routing guideline.
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 burden of behavior and succeeds in disclosing key traits: only currently-visible elements are clicked, clicks happen in order, and limit=0 removes the limit. It does not mention potential side effects of many clicks or behavior on no matches, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence with a parenthetical example and a tersely stated limit rule. Every phrase adds value and the core action 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 two-parameter tool with an output schema, the description is largely complete: it explains what gets clicked, the visibility restriction, ordering, and the limit behavior. It could ideally state what happens when nothing matches, but that gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It adds important semantics for `limit` ('limit=0 means no limit') but says little about `selector` beyond 'matching a selector,' leaving the exact selector syntax or expected format to be inferred.
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: 'Click every currently-visible element matching a selector, in order.' It also gives a concrete example (checkboxes) and clarifies limit=0 means no limit, making the tool's distinct purpose immediately clear even among many 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 phrase 'every currently-visible element' and the example 'checking every checkbox on a page' clearly imply this tool is for batch-clicking all matching visible elements rather than clicking a single element. It does not explicitly name alternatives or when-not-to-use, so it stops short of full guidance.
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 burden of behavioral disclosure. The verb 'Get' clearly signals a read-only operation, and the parenthetical definition explains exactly what value is returned. It does not mention failure conditions, but for a parameterless getter this is acceptable.
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?
One short sentence with no filler. The core action and the precise meaning of 'origin' are both present and 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?
Given the tool is a simple, parameterless getter and an output schema exists, the description is nearly complete. It could add a note about using get_current_url for the full URL, but nothing essential is missing for correct invocation.
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, so the schema fully defines the invocation surface. The description correctly adds no parameter information because there is nothing to explain. Baseline 4 is appropriate for a parameterless tool.
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 uses a specific verb ('Get') and names the exact resource ('origin (scheme + host) of the current page'). This clearly distinguishes it from sibling URL-related tools like get_current_url and get_title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool is useful by defining origin as scheme + host, but it does not explicitly contrast it with alternatives such as get_current_url or get_all_urls. Usage context is implied rather than stated.
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 usefully states that only visible text is returned and that an exception is raised if the element is not found within the default timeout. This goes beyond a bare 'Get text' statement and clarifies what the agent should expect.
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 two concise sentences with no filler. The main action and default scope are front-loaded, and the exception behavior is stated in the second sentence. Every sentence contributes useful information.
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 optional parameter and an output schema, the description covers the core behavior, default, and a key failure mode. Minor omissions such as selector syntax and the actual timeout duration prevent a perfect score, but the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 adds that the selector refers to an element and that omitting it targets the whole page body, which is helpful. However, it does not explain the selector syntax or matching behavior, leaving a meaningful gap for a tool with one loosely described parameter.
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 verb ('Get'), the resource ('visible text within an element'), and the default scope ('whole page body'). It distinguishes this from sibling tools like get_element_html or get_element_attribute by emphasizing visible text rather than markup or attributes.
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: use it to retrieve the visible text of an element, or the whole page body by default. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent can infer when it is appropriate.
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 explicitly documents protocol normalization (automatic https:// prefix), the wait condition (initial HTML parsed and loaded), side effects on navigation history, and error behavior for invalid URLs or load failures. This is substantial and directly useful.
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-structured. The first sentence delivers the core action, and each subsequent sentence adds a distinct behavioral fact—protocol handling, waiting, history, errors—without redundancy or fluff.
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 one-parameter navigation tool with an output schema and no annotations, the description is complete. It covers how the input is normalized, what the tool waits for, side effects on history, and failure behavior. An agent has enough information to invoke it correctly and predict results.
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 schema only defines 'url' as a required string with no per-parameter description (0% coverage). The description compensates by explaining how the URL is interpreted: missing protocols are automatically prefixed with https://, and invalid URLs raise errors. This adds meaningful semantics beyond the raw schema.
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 starts with a specific verb and resource: 'Navigate to the given URL in the web browser.' It clearly distinguishes itself from navigation-sibling tools like reload_page, go_back, or open_new_tab because the core action is loading a provided URL, though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the main use case—loading a specific URL into the browser—but provides no explicit when-to-use or when-not-to-use guidance relative to sibling navigation commands. An agent can infer intent from the name and first sentence, but there are no exclusions or comparison to alternatives.
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 full burden. It discloses that the tool clears the field, types the text, uses a default 7-second timeout when timeout is 0 or None, and raises an exception if the element isn't found within the timeout. These are key behavioral traits beyond what the schema shows.
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?
Three short sentences with no filler. The primary action is front-loaded, followed by the default timeout behavior and the exception condition. Every sentence adds 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?
The description covers the core action, timeout semantics, and failure behavior. Since an output schema exists, return value details are not needed. It does not mention selector format or element visibility requirements, but these are common and not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaningful semantics for the timeout parameter, including the 7-second default and failure behavior. Selector and text are not described, but their purpose is fairly self-evident from their names and from the action description.
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 a specific action: clear a field and type text into it. This distinguishes it from related siblings like send_keys (which types without clearing), clear_input (which only clears), and set_value (which may not clear-and-type in the same way).
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 clear-and-type phrasing provides strong contextual guidance: use this tool when you want to replace the current contents of a field. It does not explicitly name alternatives or when-not-to-use, but the behavior is distinct enough that an agent can infer the appropriate usage.
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 clearly reveals the destructive side effect (the currently active tab will be closed), and there are no parameters or auth/rate-limit concerns to disclose. It does not mention edge cases like closing the last tab or browser focus changes, but the core behavior is unambiguous.
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 entire description is one short, front-loaded sentence that says exactly what the tool does. There is no filler, no repetition, and no unnecessary 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?
This is a simple zero-argument destructive action with an output schema available. The description states the target and the action sufficiently, and with no parameters, the agent has everything needed to invoke it correctly.
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 the schema already provides complete coverage, so there is nothing for the description to add. A score of 4 is the baseline for a parameterless tool.
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 uses a specific verb ('Close') and identifies the resource ('currently active tab'), which clearly distinguishes it from sibling tools like close_browser, switch_to_tab, or open_new_tab. It tells an agent exactly what action is taken and on what.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implicit: call this tool when the current active tab should be closed. However, the description gives no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as close_browser for ending the whole browser session.
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 what is returned (tag name, text, outer HTML), how best_match resolves multiple text matches, and that timeout waits for the element to appear. It does not mention error behavior when the element never appears or which element is chosen when a selector matches multiple nodes, 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 front-loaded with the tool's purpose and output, followed by a focused Args section. Every sentence adds value, and there is no redundant restatement of the tool name or schema details.
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 read-only 3-parameter tool with an output schema and no annotations, the description covers the essential call behavior, return content, and parameter semantics. It is slightly incomplete around timeout/not-found error handling and explicit differentiation from nearby get_text/get_element_html tools, but overall it gives an agent enough to invoke it 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. It explains selector as either a CSS selector or visible-text matcher in CDP mode, best_match as choosing the element whose text length is closest to the search text, and timeout as seconds to wait for the element. This adds real meaning beyond the bare schema properties.
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: 'Find one element and return its tag name, text, and outer HTML.' This clearly distinguishes it from siblings like find_all_info, which returns multiple elements, and get_element_html or get_text, which return only one piece of the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need one element's tag name, text, and outer HTML in a single call. It also explains selector-versus-text matching in CDP mode, but it does not explicitly name alternatives or state when not to use this tool, leaving some routing 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, but 'Get' clearly signals a read-only operation with no side effects. The description does not detail return formatting, but an output schema exists, and zero parameters mean no hidden input behavior.
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 one short sentence that states exactly what the tool does. Every word is meaningful and there is no filler or repetition of schema data.
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 read-only tool with an output schema, the description is complete. It tells the agent what is retrieved and leaves no invocation decisions open.
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, so there is no parameter meaning for the description to clarify. Baseline 4 is appropriate because there is nothing the description needs to add.
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 uses a specific verb ('Get') and a specific resource ('the URL of the current page'). The singular 'current page' clearly separates it from sibling tools like get_all_urls or get_origin, so an agent can understand exactly what this tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this when you need the current page's URL. The description does not explicitly contrast it with get_all_urls, get_origin, or the assert_url tools, but the simple scope makes the intended use fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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. 'Get' implies read-only behavior, but the description does not explicitly state that it has no side effects or what it returns when no title exists. It is adequate but lacks explicit behavioral detail.
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?
A single sentence with no filler or redundant detail. The description is well-structured and front-loaded with the core action and target resource.
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 getter with a defined output schema and no side effects, this description is complete. An agent can confidently choose and invoke this tool based solely on the provided text.
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, so the baseline is 4. There is no parameter information needed beyond the schema, which is already complete.
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 action ('Get') and the resource ('the title of the current page'). This distinguishes it from sibling tools like assert_title, which checks rather than retrieves the title.
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 makes it clear this is for retrieving the current page's title, which is sufficient context for such a simple tool. It does not explicitly mention alternatives or exclusions, but the use case is immediately obvious.
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 burden of behavioral disclosure. It clearly explains what the tool does and gives a familiar mental model ('same as clicking the Back button'). It does not cover edge cases like empty history or wait behavior, but the simplicity of the action makes this acceptable.
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?
Two short sentences with zero waste. The core action is front-loaded, and the analogy adds useful context without redundancy.
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 zero-parameter tool with no annotations, the description is almost complete. It covers the action and its real-world equivalent. The only minor gap is behavior when there is no history, but this is an edge case not essential for correct invocation.
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, so there is nothing for the description to add. Baseline for 0 params is 4, and the description appropriately avoids inventing parameter details.
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?
States a specific verb ('Go back') with a clear resource ('browser history') and reinforces the action with the familiar analogy of the browser Back button. This makes it immediately distinguishable from siblings like go_forward, navigate, and reload_page.
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?
Provides clear context for use: go back one page in history, same as the browser Back button. It does not explicitly mention when not to use it or name alternatives, but the intent is unambiguous for a simple navigation action.
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 burden of behavioral disclosure. It explains the action and equates it to clicking the browser's Forward button, which conveys expected behavior. It does not mention edge cases like doing nothing when no forward history exists, but the core behavior is well described.
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?
Two concise, front-loaded sentences with no redundant content. The operation is stated first, followed by a helpful real-world analogy.
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 zero-parameter action with an output schema present, the description is sufficiently complete. The only minor gap is the lack of an explicit note about what happens when there is no forward history entry.
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, so the baseline is 4. The description appropriately adds no parameter details because there are none to describe.
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?
States a specific action ('Go forward one page in browser history') and clarifies it with the Forward button analogy. This clearly distinguishes it from sibling tools like go_back, reload_page, and navigate.
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 makes the intended use clear: move forward in browser history when that is the required navigation step. It does not explicitly mention alternatives or when not to use it, but the behavior is unambiguous for a zero-parameter tool.
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 behavioral burden. It discloses the default timeout behavior ('If no timeout given (0 or None), then SeleniumBase uses 7 seconds') and the failure outcome ('Raises an exception if the element is still present after the timeout'), making the tool's behavior 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 three short, front-loaded sentences. The purpose is stated first, followed by the timeout default and then the exception behavior. Every sentence carries useful information with no redundancy.
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 two-parameter wait operation: it specifies what to wait for, the default timeout, and the failure behavior. Since an output schema exists, return values need no explanation. A slight gap is the lack of guidance about how selector syntax works, though this is likely shared across sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 adds meaningful semantics for the timeout parameter by explaining the default value and effect, but it gives no additional guidance about the selector parameter beyond calling it a selector. This is partially sufficient but not fully comprehensive.
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 action with a clear condition: 'Wait until an element is removed from the DOM.' This distinguishes it from sibling tools like wait_for_element_visible and wait_for_element_not_visible by emphasizing removal from the DOM rather than visibility.
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 clearly communicates the tool's intended purpose: waiting for DOM removal rather than mere invisibility. It does not explicitly name alternatives or say when not to use it, but the 'removed from DOM' wording gives adequate contextual differentiation from the sibling 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, the description carries the behavioral disclosure burden. It does well by explaining that the session uses CDP rather than WebDriver, that it is stealth-oriented, and that it must precede all other tools. It could go slightly further by noting lifecycle behavior such as whether repeated calls reset or reuse an existing session, 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 tightly structured: a front-loaded purpose sentence, a key ordering constraint, a brief mode rationale, and a compact argument list. Every sentence earns its place, with no filler or repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a startup tool with six optional parameters and no annotations, the description covers the essential operational context: what the tool does, when to call it, and what each option controls. The presence of an output schema reduces the need to explain return values. A small gap is lack of guidance on calling start_browser again while a session already exists.
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: every parameter gets a meaningful, non-redundant explanation, including the proxy format example and the effect of headless/incognito/guest/ad_block. This gives the agent enough semantic detail to set options 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 clearly states the action ('Launch') and the specific resource ('a Pure CDP Mode browser session'), making the tool's purpose unmistakable. It also distinguishes this setup tool from the many browser-action siblings by emphasizing CDP mode and mandatory first-use.
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?
'Must be called before any other tool' is an explicit and unambiguous usage requirement. The description also explains why this mode is preferable (stealth/bot-detection resistance), giving the agent clear context for selecting this tool first.
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 the assertion behavior, substring semantics, whitespace trimming, default selector and timeout behavior, and the exception-raising behavior on failure. This gives an agent a reliable model of what happens when the tool is called.
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?
Three focused sentences front-load the core behavior, then cover defaults and error behavior. Every sentence adds necessary detail and there is no 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?
For a relatively simple assertion tool with no annotations and an output schema present, the description is complete. It covers all parameters, defaults, matching semantics, and failure behavior. Nothing essential for invoking the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: 'text' is described as the substring to assert, 'selector' as the CSS selector defaulting to 'html', and 'timeout' as seconds defaulting to 7 when 0 or None. This fully explains the three parameters despite 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 uses a specific verb ('Assert') and resource ('text substring appears within the given element'), and distinguishes itself from siblings like assert_exact_text by explicitly saying 'substring' and noting whitespace is ignored. It also clarifies that the target element is selected via a CSS selector, which is a distinct operation from title/URL assertions.
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 context for when to use the tool: to assert a substring within an element with optional selector and timeout. It implies the distinction from exact-text matching and other assertion tools, but it does not explicitly name alternatives or state when not to use this tool. This is clear context without exclusion guidance.
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'
If you have feedback or need assistance with the MCP directory API, please join our Discord server