Superior Browser MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Many tools have overlapping purposes, such as browser_interact vs click_by_overlay_id/hover_by_overlay_id, browser_fill_form vs smart_fill_form, and several detection tools (popups, ads, captcha, login). The visual/interactive map tools also overlap heavily. Agents will struggle to choose the right tool.
Naming Consistency1/5
Tool names mix snake_case (click_by_overlay_id, detect_popups) with camelCase (browser_navigate, browser_take_screenshot), and some use the 'browser_' prefix while others do not. There is no consistent verb_noun pattern, making the API feel chaotic.
Tool Count2/5
42 tools is excessive for a browser automation server, especially when many could be consolidated (e.g., unified interaction tool, unified form tool, unified detection tool). The high count with redundancy suggests the set is not well-scoped.
Completeness4/5
The server covers a wide range of browser automation needs: navigation, interaction, forms, screenshots, popups, ads, captchas, cookies, storage, network, console, performance, tabs, windows, dialogs, and extensions. Minor gaps exist (e.g., explicit element selection or file upload tool, though browser_interact covers them), but overall the surface is quite comprehensive.
Average 3.2/5 across 42 of 42 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior1/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 disclosing side effects such as session creation, invalidation, or read-only status. 'Manage PRO authentication' reveals nothing about whether actions mutate state, require prior login, or what responses look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words, which is terse but not effectively concise—it omits nearly all relevant information. Under-specification is not the same as conciseness; every word should earn its place, and here the words communicate only a vague domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a single action enum, the description must explain the tool's behavior, side effects, and expected return states. It does none of that. The description is insufficient for an agent to confidently invoke the tool with correct expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does 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 single 'action' parameter. It does not explain the semantics of login, logout, or status, nor how each action behaves. The enum names are self-explanatory but the description itself contributes zero parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Manage PRO authentication,' which names a resource but uses the generic verb 'manage' and does not specify the concrete actions (login/logout/status) beyond what the schema provides. It is not clearly differentiated from sibling tools like status or detect_login_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 any alternatives. The description does not mention login forms, session management, or any exclusion criteria, leaving the agent to infer usage only from the action enum.
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 must disclose behavior but only says 'handle', not whether it accepts or rejects, how text is used, or what the outcome is. This is minimal and unhelpful for an agent needing to understand 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise and free of fluff, but it is under-specified and lacks structure that would help an agent. It is not verbose, but its brevity comes at the cost of informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should provide significantly more context about dialog behavior, return values, and when to invoke it. The current text is too sparse for reliable use in a complex browser automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (text has a description, accept does not), and the description adds no parameter insight. It does not explain the role of 'accept' or 'text' beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (alert/confirm/prompt dialogs) but uses the vague verb 'handle' without specifying what action occurs (accept, dismiss, etc.). It is clear enough to distinguish from siblings, but not precise about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 browser_interact or browser_evaluate. The description lacks any context about prerequisites, exclusions, or recommended usage scenarios.
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 mentions lazy loading support but doesn't explain side effects, return behavior, or whether scrolling triggers events. 'Smart' is marketing language without concrete 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it includes a filler emoji and the vague 'Smart'. It's not poorly structured, but the word choice adds little informative value per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, a one-line description is severely inadequate. It fails to explain the differences between action types, the purpose of loadAll vs lazy_load, the meaning of x/y coordinates, or any return values or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes action, loadAll, and selector, and the description adds only a general sense of elements/areas and lazy loading. x and y remain completely undocumented in both schema and description, and the description doesn't clarify coordinate origin or interaction with the action parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a scroll tool with lazy loading support and the ability to scroll to elements or areas, distinguishing it from sibling tools. However, 'smart' is vague and doesn't enumerate the specific action types, so it's not a perfect 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/5
Does 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, no exclusions, and no explicit context. The action enum implies usage scenarios, but the description doesn't elaborate on when to choose scroll_page over other browser interaction 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 mentions 'smart field matching' without explaining whether it overwrites existing values, triggers input/change events, requires visible fields, or handles hidden elements. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, making it concise and front-loaded. However, its brevity comes at the cost of missing critical details, which slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one complex parameter (array of objects), no output schema, and no annotations, yet the description provides only a high-level phrase. It fails to explain the return value, side effects, or parameter structure, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does not clarify the meaning of 'fields,' 'value,' or 'selector,' nor how 'smart matching' interacts with them. The phrase 'multiple form fields at once' adds minimal context but fails to explain the array-of-objects structure or optional selector behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fill multiple form fields at once with smart field matching,' which clearly identifies the action (fill), the resource (form fields), and the scope (multiple at once). However, it does not explicitly differentiate from the sibling tool 'smart_fill_form,' so it stops short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 smart_fill_form or browser_interact. The description implies a bulk-fill use case but offers no exclusions, prerequisites, or contextual cues.
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 burden, but it only repeats the core action. It does not explain whether the tool waits, scrolls, returns a boolean, or throws on failure, leaving the agent to guess the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no padding. However, it is slightly under-specified, but for a simple tool this is efficient rather than wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description omits return value, visibility definition, and behavior with missing text. Given no output schema or annotations, the description is insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds only that 'text' is the text to verify. It does not specify matching semantics (exact match, substring, case sensitivity) or whether it accepts CSS selectors. The description fails to compensate for the blank schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (verify) and the subject (text visibility on page). It distinguishes from sibling browser_verify_element_visible by focusing on text rather than element, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 browser_verify_element_visible or get_accessibility_tree. There is no exclusion criteria or context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It merely says 'execute' without mentioning side effects, security implications, return behavior, or whether execution is in an isolated context, which is a significant gap for a potentially dangerous capability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. Every word contributes to stating the tool's purpose, and it is front-loaded with the verb 'Execute'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary JavaScript, the description is severely incomplete. There is no output schema, no annotations, and it lacks crucial context such as return values, error behavior, potential page manipulation effects, or how to choose between 'function' and 'expression'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full description coverage for both parameters ('function' and 'expression'), clearly defining them. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes JavaScript in the page context, which is a specific action on a specific resource. It is distinct from all sibling tools, as none of them explicitly mention arbitrary JavaScript execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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, nor any mention of prerequisites or exclusions. The description simply states what it does without suggesting any use cases or comparisons.
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 does not state whether the tool is read-only, what the output format is, whether it modifies the page, or any limitations (e.g., false positives). The phrase 'auto-detect' implies a non-mutating analysis, but this is not explicit, and the lack of output schema makes the description insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the tool's purpose. The list of component types is efficient, and the '🆕' emoji is a minor but harmless addition. Every word earns its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain what the analysis returns (e.g., a structured report, confidence scores, or a visual map). It does not. The tool has 5 optional parameters, and the description fails to clarify how they influence the output or whether the tool can be run with no flags. This gap in behavioral detail makes it incomplete for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each boolean parameter having a clear description. The tool description lists the same categories (forms, ads, popups, etc.), which reinforces the schema but adds no deeper meaning. It does not explain default behavior when no flags are set, but the schema already makes each parameter self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'auto-detects and classifies page components' with a specific list of examples (forms, navigation, ads, popups, etc.). It distinguishes itself from specialized siblings like detect_popups or detect_ads by covering many component types in one tool, though it does not explicitly name these 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/5
Does 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 the specialized sibling tools (detect_popups, detect_ads, get_form_analysis, etc.). The description does not mention any prerequisites, exclusions, or alternative recommendations, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'Drag element to another element' without detailing event simulation, waiting behavior, side effects, or error handling, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, making it concise and front-loaded. However, it sacrifices informative content for brevity, so it lacks some structural richness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a drag action) and the absence of annotations or an output schema, the description is incomplete. It does not explain the drag mechanics, success criteria, or post-conditions, leaving critical information missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both fromSelector and toSelector described as source and target selectors. The description does not add extra semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'drag' and identifies two elements (source and target), making the operation clear. It is distinct from siblings like click or hover, as drag is a unique interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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, nor any prerequisites or exclusions. It simply states the action without 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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It merely lists interaction types without explaining how actions are executed (e.g., sequential order, waits for page load, element visibility requirements) or how errors are handled (despite the 'onError' parameter existing). The description adds no safety or side-effect context, making it insufficient for an agent to predict the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary verb and a concrete list of interactions. It has no fluff or redundancy. However, it is somewhat generic and could have been slightly more informative, but for a broad tool, this level of brevity is acceptable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complex schema (actions array with many possible types and nested properties) and the existence of many specialized sibling tools, the description is far too brief. It lacks guidance on constructing actions, specifying selectors or coordinates, handling the onError parameter, and understanding the relationship to single-purpose siblings. No output schema exists to clarify return values, so the description must carry more weight but fails to do so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters, with the 'actions' array containing many nested fields. Schema description coverage is only ~50% (some properties like 'key', 'text', 'value', 'selector' have descriptions, but many do not). The tool description enumerates action types that mostly mirror the enum values in the schema, adding little new meaning. It does not explain how to structure an action object, use selectors, or handle the 'onError' option, so it fails to compensate for the schema's gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: performing browser interactions like click, type, hover, scroll, and file upload. It uses a specific verb ('Perform') and identifies the resource ('interactions'), making the core function clear. However, it does not explicitly differentiate from sibling tools such as click_by_overlay_id or scroll_page, though the broad list of capabilities implies a multi-action tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one or more interactions' implicitly suggests the tool is for batching/sequencing multiple actions, which distinguishes it from the single-action sibling tools. But it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or specific conditions. The implied usage is present but not clearly articulated.
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 states the basic action but fails to mention return type, whether it waits for visibility, timeout behavior, or what happens if the element is not visible. This leaves significant ambiguity for an 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately sized for a tool with one parameter and a straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple verification tool with one parameter and no output schema, the description is minimally viable. However, it leaves gaps around return values, waiting behavior, and sibling differentiation, making it incomplete for fully informed tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the parameter 'selector', and the tool description adds no elaboration on acceptable selector formats or examples. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Verify' and the resource 'element is visible on page', making the tool's purpose evident. The parenthetical '(for testing)' adds context but doesn't explicitly differentiate from the sibling tool browser_verify_text_visible, though the 'element' vs 'text' distinction is implied by the 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/5
Does 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 such as browser_verify_text_visible or wait_for. There is no mention of prerequisites, typical scenarios, or conditions under which this tool should be preferred.
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 disclosing behavioral traits. It only says 'detect,' which implies a read-only operation, but the schema shows that setting blockAds=true injects a blocker, a potentially page-modifying side effect that is not disclosed. The description also doesn't mention permissions or what happens to the page after detection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, and contains no filler words. However, the phrase 'detailed information' is vague and could be more specific, slightly reducing the clarity per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the tool returns (e.g., ad positions, sizes) and any side effects (e.g., blocking ads). It does neither, leaving the agent to guess the tool's full behavior. The schema covers parameters, but the overall contextual picture is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides thorough descriptions for both parameters (blockAds and includePositions), achieving 100% coverage. The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('detect') and resource ('ad elements on the page'), making the tool's core function clear. It is distinguishable from sibling tools like detect_popups and detect_captcha, though it doesn't explicitly highlight what makes it unique or what 'detailed information' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. There is no mention of typical scenarios, prerequisites, or situations where another tool (e.g., browser_extract_content) would be more appropriate.
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 mentions 'handle' but does not disclose whether it closes popups, what side effects occur, or what the function returns. With no annotations, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. The emoji is minor, but overall it's efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's behavior is underspecified: it lacks details on what 'handle' means, whether autoClose is destructive, and expected return values. Despite schema coverage, the absence of an output schema and annotations leaves significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters well (types and autoClose). The description adds little beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects and handles popups, modals, cookie banners, and notifications, listing specific resource types. It uses a specific verb, though 'handle' is slightly vague, preventing a higher score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 manage_cookies or click_by_overlay_id. The description doesn't mention exclusions or preferred contexts.
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. It implies a read-only operation via 'Get' but does not explicitly state side effects, permissions, or what happens on failure. It mentions the types of information returned, which is useful, but lacks assertions about safety or potential disruptions to the page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with front-loaded action ('Get detailed information'), making it easy to scan. The leading emoji '🆕' adds minor noise but does not detract significantly. It is efficient, though slightly vague in structure by not separating the info types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and four optional parameters. The description does not explain the return format, error behavior, or how it relates to sibling tools like get_accessibility_tree. Given the tool's simplicity as a getter, more context would be expected to ensure correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented in the schema (e.g., selector, overlayId, includeStyles, includeAccessibility). The description adds only a high-level mention of 'computed styles, accessibility info, and state', which partially maps to the boolean flags but does not deepen understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('detailed information about specific elements'), listing concrete types of info (computed styles, accessibility, state). It distinguishes itself from sibling tools like get_accessibility_tree by covering a broader scope, though 'detailed information' is somewhat generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It does not mention related tools like get_accessibility_tree or get_visual_map, nor any exclusions or prerequisites. The only hint is the description itself, which implies usage but offers no explicit direction.
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 lists actions without explaining consequences (e.g., scope of deletion, persistence of set cookies, or permission requirements). 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's core functionality. No fluff or repetition. The emoji is decorative but harmless. It earns its place as an efficient summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (multiple actions, array parameter) and no annotations or output schema. The description covers only the action types, omitting how parameters interact, what the get action returns, or side effects. It is incomplete for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra semantic meaning beyond the schema's parameter descriptions, such as the purpose of the 'cookies' array for the set action or the role of 'domain' in filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get, set, or delete browser cookies'. It uses a specific verb (manage) and identifies the resource (cookies). However, it omits the 'clear' action from the enum and does not explicitly differentiate this from related tools like manage_storage, relying on the name for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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, prerequisites, or exclusions. The purpose implies usage (when cookie manipulation is needed), but no explicit context is given.
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 'Access and modify', which does not reveal that delete and clear are destructive operations or that modifying storage can affect the current page's runtime behavior. It does not mention side effects, reversibility, or the scope (current origin).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core function. There is no redundant text, and the message is immediately clear. The emoji '🆕' is minor noise but does not detract significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema having good parameter descriptions, the tool description lacks any context about the operational environment (e.g., current page), return values, or error conditions. There is no indication of when to use this tool in a broader browser automation workflow. Given that no output schema exists and annotations are absent, the one-sentence description is insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 4 parameters (100% coverage), including the action and type enums, so the schema already explains parameter meaning. The description does not add any extra information about parameters, but since coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (localStorage and sessionStorage) and the general actions (access and modify). It distinguishes itself from sibling tools like manage_cookies since it covers storage, not cookies. However, it could be more explicit about the specific actions (get, set, delete, clear) rather than using the broad 'modify'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It does not mention that manage_cookies should be used for cookie operations, nor does it provide context about when storage manipulation is appropriate. The description lacks any usage scenarios or exclusions.
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 disclosing behavior. It mentions auto-detection and intelligent filling, but fails to disclose side effects like optional form submission (submitAfter), selector targeting, or any errors or return values. The behavioral surface is largely 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It efficiently conveys the core purpose without wasted words, earning top marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It does not cover the behavior of submitAfter and formSelector, nor what the tool returns or how it handles failures or ambiguous field detection, leaving the agent with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds marginal value by explaining that field detection is based on labels, names, and types, which relates to the formData parameter, but does not elaborate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: auto-detecting form fields and filling them intelligently based on labels, names, and types. While it distinguishes itself from a generic fill tool by emphasizing 'auto-detect' and 'intelligently', it does not explicitly name or contrast with sibling tools like browser_fill_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as browser_fill_form or get_form_analysis. The description implies use for forms with ambiguous selectors, but there is no clear context, prerequisites, or exclusions.
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 burden for behavioral disclosure. It mentions 'with retry' but fails to explain timeout behavior, polling mechanics, or error handling, and 'Smart' is undefined. This leaves significant uncertainty about side effects and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core behavior and an emoji for visibility. It is efficient but the word 'Smart' adds little value; still, every word earns its place for a brief description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are five parameters, no annotations, and no output schema, the description is too brief to be contextually complete. It does not explain what happens on timeout, whether the tool returns a boolean or throws, or how retry logic is configured, which are critical for a wait operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all five parameters, so baseline is 3. The description's reference to 'elements, text, or conditions' loosely maps to selector, text, and condition parameters, but it adds no additional semantic detail beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for elements, text, or conditions with retry, using a specific verb ('wait') and resource types. It distinguishes from sibling tools like browser_verify_element_visible which verify rather than wait, though 'Smart' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The description does not mention using browser_verify_element_visible for verification or mention scenarios where waiting is appropriate, 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.
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. It discloses that the tool targets unpacked/development extensions, but it does not mention side effects, behavior when extensionName is omitted, whether it reloads all extensions, or any prerequisites. Significant behavioral unknowns remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasteful words, front-loading the action and the target. It is well-structured and easily parsed, though very brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, no annotations, and no output schema, the description leaves critical gaps: the parameter is unexplained, the scope of the reload is ambiguous, and side effects are undeclared. It is not sufficient for an agent to confidently invoke the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter (extensionName) with no description, and the tool description does not mention it at all. With 0% schema description coverage, the parameter's meaning and usage are completely unexplained, leaving the agent without guidance on how to populate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reload') and the resource ('unpacked/development browser extensions'), distinguishing it from sibling tools like browser_list_extensions or enable/disable. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage (during development to reload unpacked extensions) is implied but not explicitly stated. No alternatives or exclusions are provided, though the description does give some context by limiting to unpacked/development extensions.
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 must disclose behavioral traits. It does not warn that 'close' terminates the browser window, mention whether actions are synchronous, or describe side effects. This is a significant omission for a tool capable of closing the window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence listing the core actions with no fluff. It is appropriately sized for a simple tool, even though it under-specifies behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It fails to explain parameter conditions, return values, or the destructive nature of 'close', making it insufficient for an agent to invoke the tool correctly in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the tool description only repeats the action enum values. It does not explain that width and height are only relevant when action is 'resize', leaving the conditional parameter relationship undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages the browser window and lists four specific actions (resize, minimize, maximize, close), distinguishing it from sibling tools focused on navigation or tabs. The verb 'manage' is broad, but the enumerated actions ground the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives, nor are there exclusions or prerequisites. The intended usage is only implied by the listed actions; for instance, it does not mention that resize may require width and height.
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 fails to mention side effects (e.g., replaying requests may cause duplicate submissions), whether authentication is needed, or any rate limits. The description only states high-level functionality without revealing behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose and key feature without unnecessary fluff. It is appropriately concise, though it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 9 parameters and four distinct actions, yet the description provides only a one-line summary. It does not explain what each action does, what the output format is, or how parameters interact. Given the absence of output schema and annotations, the description is grossly insufficient for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at the 'jsonPath' parameter via 'JSONPath filtering'. All other eight parameters (limit, offset, method, status, requestId, urlPattern, resourceType, action) are left undefined by the description, forcing the agent to infer meaning from parameter names and types alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: monitoring and replaying network requests. It mentions a specific distinguishing feature (JSONPath filtering) and is easily differentiated from sibling tools, which focus on other browser interactions. The verb-resource combination is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for network request inspection and replay, but it does not explicitly state when to use this tool over alternatives or how to choose among the 'list', 'details', 'replay', and 'clear' actions. Sibling tools do not offer network request functionality, so the context is inferable, but explicit guidance is missing.
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 disclosing behavioral traits. It states the snapshot is 'fast, text-based', implying a read-only, non-mutating operation, but it does not describe the output structure, whether it includes hidden elements, or any limitations. The description is too sparse to give the agent confidence about side effects or the exact nature of the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action, and contains no fluff. Every word adds value: 'accessible DOM snapshot' specifies what is retrieved, 'fast' indicates performance, and 'text-based' implies the format. It is appropriately terse for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description must convey enough for the agent to select the tool correctly among many similar siblings. It does not explain how this snapshot differs from 'get_accessibility_tree' or 'browser_extract_content', nor does it describe the output format beyond 'text-based'. This is insufficient for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description need not explain parameter meanings. The baseline for 0 parameters is 4, and the description does not introduce any ambiguity that would lower this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an accessible DOM snapshot of the current page, using a specific verb ('Get') and resource ('accessible DOM snapshot'). It also adds a performance characteristic ('fast, text-based'). However, it does not explicitly distinguish this from the sibling 'get_accessibility_tree' or other snapshot-like 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/5
Does 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. It does not mention when this is preferred over 'get_accessibility_tree', 'get_visual_map', or 'browser_extract_content'. Only a few adjectives ('fast, text-based') hint at a potential use case, but there is no explicit when/when-not.
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 lists actions without explaining side effects or requirements—e.g., whether closing a tab is irreversible, whether attach brings a tab to the foreground, or what stealth mode does. This lack of behavioral context is a significant gap for a tool that can close or create tabs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, then enumerates the actions with a colon list. Every word serves a purpose and there is no redundancy or filler, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a broad overview but leaves out details that would fully support usage: what the 'list' action returns, how index relates to attach/close, or the meaning of stealth and activate. Given there is no output schema, the description could have elaborated on return values or side effects. However, the schema richly documents parameters, so the description is minimally viable rather than inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all five parameters, so the baseline is 3. The description adds no extra meaning to url, index, stealth, or activate; the action enum already mirrors the four listed actions. Therefore, the description neither enhances nor detracts from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Manage' and explicitly lists the four supported actions (list, create, attach, close) with the resource 'browser tabs'. This distinguishes it from sibling tools like browser_navigate or browser_snapshot, though it does not name them explicitly. It is more specific than a generic 'manage' and adequately conveys the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 phrase 'Manage browser tabs' implies tab-specific operations, but there is no mention of when to prefer this over related tools (e.g., browser_navigate for navigation, browser_window for window management). No exclusions or alternative tool names are given.
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 mentions 'smart content detection' but does not explain how it works, what happens with dynamic or complex pages, or whether it waits for rendering. It also does not indicate what the output structure looks like or any 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's core purpose without unnecessary words. It is front-loaded with the action and resource, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), this one-sentence description is insufficient. It does not explain the return format, how modes affect output, or what 'clean markdown' means in practice, leaving significant gaps for an agent trying to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters, so the baseline is 3. The tool description itself adds no additional parameter-level meaning beyond the schema. The description does not elaborate on mode behavior, selector usage, or pagination semantics further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Extract', the resource 'page content', and the output format 'clean markdown'. The phrase 'smart content detection' adds a clear sense of scope and helps distinguish this from sibling tools like browser_snapshot or browser_interact, which focus on different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. Sibling tools such as browser_snapshot or browser_interact may serve overlapping purposes, but the description does not mention any exclusions or provide context for selection. The usage is only implied by the description's 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 full responsibility for behavioral context. It does not disclose what specific metrics are returned, whether it refers to the current page, or the shape of the output, which is a significant gap for a tool that returns data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or repetition. It front-loads the core purpose and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters), but the description is thin: it does not specify which Web Vitals are included, whether it reports field or lab data, or what the return format is. In the context of many sibling browser tools, a bit more detail would aid correct invocation, though the current text is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. As per the baseline for 0 params, the description does not need to explain parameters; this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and names the resource 'Web Vitals and performance metrics', clearly stating what the tool does. It does not explicitly distinguish from siblings like browser_network_requests or browser_evaluate, but the focus on Web Vitals is a distinct enough 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/5
Does 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, no prerequisites, and no mention of context or exclusion criteria. The description simply states what it does, 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.
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 states the core actions (deactivate, disconnect) but omits important behavioral details such as whether the action is reversible, what happens to in-flight automation, or whether any state is preserved. For a state-changing tool, this is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the core action adequately. However, it lacks contextual information about the relationship with 'enable' and 'status', and does not mention the effect on browser extension state or whether the action is reversible. It is the minimum viable description for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately does not need to explain parameter syntax or meanings since there are none. Schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Deactivate browser automation and disconnect from browser extension.' It uses specific verbs ('Deactivate', 'disconnect') and identifies the resources affected. It distinguishes from sibling tools like 'enable' and 'status' by naming the deactivation/disconnection behavior, though it does not 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 Guidelines2/5
Does 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. Given sibling tools like 'enable' and 'status', the description does not state that this is the counterpart to 'enable' or when disconnection is appropriate. There is no mention of prerequisites, workflow position, or exclusions.
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 burden of behavioral disclosure. It states a 'check' action, which implies a read-only operation, but it does not disclose what specific state information is returned, whether any side effects occur, or whether connection status includes network latency, WebSocket, etc. This is minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of unnecessary words. Given the tool's simplicity (no parameters), this conciseness is appropriate and every word contributes to conveying the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 output schema, the description is adequate but lacks completeness. It does not explain what 'browser state' entails or what the response will contain (e.g., a status code, JSON fields). The simplicity of the tool might make this acceptable, but the description could still provide more detail about the returned information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does 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% (trivially). Since there are no parameters to describe, the baseline score of 4 applies, and the description correctly focuses on the tool's action without parameter-related ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check current connection status and browser state' uses a clear verb ('check') and identifies the resource (connection status and browser state). It clearly describes the tool's purpose but does not explicitly differentiate from sibling tools like browser_snapshot or browser_console_messages that also inspect browser 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/5
Does 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. It does not mention prerequisites, exclusions, or cases where another sibling (e.g., browser_performance_metrics) would be more appropriate. The usage context is only implied by the purpose.
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. The verb 'Get' implies a read-only operation, and 'with filtering' suggests parameterizable behavior. However, it does not disclose details such as whether messages are only from the current page, whether filters are combined, or any side effects. This is minimal but acceptable for a seemingly simple 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and the resource. Every word contributes to meaning, and it remains brief without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, and annotations are absent. The description does not explain what the tool returns (e.g., the actual messages, count, or format) or mention any prerequisites or limitations. This leaves significant gaps for the agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% with descriptions for url, text, limit, and offset, while level has an enum but no description. The description only says 'with filtering,' which adds little beyond the structured schema. Since the schema already defines most parameter semantics, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('browser console messages'), and adds a scope modifier ('with filtering'). This clearly differentiates it from sibling tools like browser_network_requests (which gets network data) or browser_extract_content (which gets page content), so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It does not mention typical use cases (e.g., debugging JavaScript errors) or any exclusions, leaving the agent to infer appropriateness 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 must fully disclose behavioral traits, but it only states the primary action. It does not mention file overwrite behavior, permissions, side effects, or return values, leaving the agent uninformed beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states exactly what the tool does. Every word provides value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is largely complete for basic use. However, it lacks mention of potential side effects like file overwriting, which would be useful in a complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as the 'path' parameter is described in the input schema. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save current page as PDF' uses a specific verb and resource, clearly distinguishing it from sibling tools like screenshots or content extraction. It immediately conveys the tool's function without 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/5
Does 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 only states the action, leaving the agent to infer usage context without any exclusions or alternative tool references.
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 burden of behavioral disclosure. It does mention optional overlays, element highlighting, and partial capture, which are meaningful behavioral traits. However, it omits key side effects like file creation/overwrite behavior, default to full-page vs viewport, and what the tool returns (e.g., a path or success flag). This is some value over zero, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the core action and key optional features. Every word earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no annotations or output schema, the description is too thin. It does not explain how parameters like fullPage, deviceScale, or quality interact, nor does it mention default behaviors or expected return values. The complexity of the tool is not matched by the description's completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description groups parameters into feature categories (overlays, highlighting, partial capture), which provides a high-level mental model. However, it does not add specific meaning beyond what the schema already describes for each parameter, so it neither elevates nor degrades the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Capture screenshot with optional overlays, element highlighting, or partial capture' clearly states the verb ('capture') and resource ('screenshot'), while also distinguishing the tool from siblings like browser_snapshot or get_visual_map by highlighting its unique features (overlays, highlighting, partial capture). This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 browser_snapshot or get_visual_map. It implies a general screenshot capture use case, but does not mention any exclusions, prerequisites, or context in which another tool would be more appropriate.
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 click action and the overlay ID source; it does not mention potential side effects, timing, page-load requirements, or what happens if the overlay ID is stale/invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and target. It contains no unnecessary elaboration, making it concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter click tool, the description provides the essential context: what to click and where the ID comes from. It could mention the need to generate a visual map first, but the sibling context and the phrase 'from the visual map' make this reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes overlayId as 'The number shown on the visual overlay' (100% coverage). The description repeats the concept without adding new parameter detail, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Click'), identifies the resource ('an element by its overlay ID'), and names the source ('from the visual map'). This clearly distinguishes it from sibling tools like hover_by_overlay_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as hover_by_overlay_id. The description implies usage when an overlay ID has been obtained, but it does not state prerequisites, exclusions, or alternative choices.
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 burden for behavioral disclosure. It only says 'list', which implies a read operation but adds no detail about return format, whether disabled extensions are included, or other behavioral traits. The description largely restates the tool 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. There is no unnecessary wording, and it 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and is simple in scope, but the description is minimal. It does not specify what the returned list contains (e.g., names, IDs, versions) or whether it includes all extensions or only enabled ones, leaving some ambiguity for an agent that needs to parse the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. No parameter information is needed, and the description does not attempt to describe parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'installed browser extensions', clearly stating the tool's function. It distinguishes from siblings like browser_reload_extensions, which performs a different 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/5
Does 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, nor any context about use cases. It simply states the action without mentioning any exclusions or alternative tools.
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 carries the full burden. It communicates the core behavior (detecting presence) and implies a non-mutating read-only action, but it does not specify the return format (e.g., boolean) or whether any page interaction occurs. For a simple detection tool, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it includes an unnecessary emoji (🆕) that adds no informative value. The core sentence is efficient and front-loaded, but the emoji makes it slightly less clean than a purely functional one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter detector with no output schema and no annotations, the description provides the essential purpose but leaves important context missing. It does not state the return value, possible false-positive behavior, or any caveats. This makes it adequate but incomplete for an agent to fully predict the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain beyond the schema. The baseline for 0-param tools is 4, and the description does not need to add parameter detail. It correctly uses no parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Detect' with a clear resource 'CAPTCHA or bot verification' and the scope 'present on the page'. It distinguishes itself from sibling detection tools (detect_popups, detect_ads, detect_login_form) by naming a distinct detection target, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. There is no mention of context, prerequisites, or exclusions. The description simply states the detection function without situating it in a workflow or distinguishing 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.
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 does not explicitly state whether the tool is read-only, modifies the page, or has any side effects. While 'get analysis' suggests a read operation, it does not openly disclose safety or behavior beyond the purpose, leaving a gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with an emoji indicating newness. It conveys the core purpose and output details efficiently with no redundant phrases. Every word contributes to understanding, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage for parameters, the description offers adequate context. It lists the analysis contents (field types, labels, required status, validation rules), which provides a clear picture of the return value even without an output schema. However, it does not mention any limitations like whether only visible forms are analyzed, but overall it is sufficiently complete for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions (formSelector, includeSuggestions). The tool description adds no additional parameter-level information, but the baseline for high schema coverage is 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting a detailed analysis of forms on a page, listing specific elements like field types, labels, required status, and validation rules. The verb 'get' plus the resource 'analysis of forms' is specific and distinguishes it from related tools like detect_login_form or smart_fill_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need form analysis, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context of analyzing forms is clear, but there is no guidance on when not to use it or which sibling tool would be more appropriate.
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 behavioral disclosure. It mentions 'clean JSON map' and 'ALL interactive elements', giving a sense of scope and output format. However, it does not disclose potential limitations like whether it includes iframe content, waits for page load, or performance 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose and output. The extra phrase 'Perfect for AI understanding of page layout' adds contextual value without waste, making it appropriately sized and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters and no output schema, the description partially describes the return structure (IDs, types, labels, positions). It does not explain whether filters affect the output shape or if the result is paginated, but it covers the core fields sufficiently for a read-only mapping tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have schema descriptions with 100% coverage, so the schema already documents each parameter thoroughly. The description adds no additional parameter-specific detail, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a JSON map of all interactive elements with IDs, types, labels, and positions. It is specific about the resource and output format, though it does not explicitly distinguish itself from sibling tools like get_accessibility_tree or get_visual_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Perfect for AI understanding of page layout' implies a use case but does not provide explicit when-to-use vs not-use guidance or mention alternatives. This is minimal implied usage context, not sufficient for a 4.
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. It states the core actions but does not reveal whether navigation waits for page load, how errors are reported, or side effects on browser history. These are relevant for an agent invoking the tool repeatedly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists every action without redundant wording. It is concise, scannable, and every word contributes to understanding the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with two well-documented parameters and an enum, and the description covers all actions. However, with no output schema, it omits information about return values or failure behavior, which are important for an agent to verify success. It is adequate but not fully complete for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters, including the action enum and the URL description. The tool description adds no additional parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Navigate' and clearly enumerates the supported actions: URL, back, forward, and reload. This unambiguously distinguishes the tool from sibling browser tools like browser_tabs or browser_snapshot, which handle different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for page-level navigation) but provides no explicit alternatives or exclusions. It doesn't mention when to use browser_tabs or browser_window instead, leaving the agent to infer the appropriate context from the action list 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 says 'visual diff' without explaining side effects, prerequisites, or how the comparison works. It does not mention whether the tool modifies state, requires a prior screenshot, or how it handles both previousPath and previousUrl.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with an emoji that concisely conveys the core purpose. It uses zero wasted words 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters and no output schema. The description is brief and does not explain return values, parameter interactions (e.g., whether previousPath and previousUrl are mutually exclusive), or potential error conditions. While the core purpose is clear, the lack of output details and usage nuances makes it somewhat incomplete for a tool with this parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters having descriptions, so the baseline is 3. The description adds marginal value by mentioning 'previous screenshot or URL', which maps to previousPath and previousUrl, but it does not clarify relationships like mutual exclusivity or the purpose of highlightChanges beyond the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool performs a visual diff between the current page and a previous screenshot or URL. It specifically identifies the resource (page state) and the action (visual diff), distinguishing it from sibling tools like browser_take_screenshot which captures without comparing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for comparing the current page state to a historical reference (screenshot or URL). It does not explicitly name alternatives or exclusions, but the purpose is clear enough to infer when it should be used.
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 bears the full burden of disclosing behavior. It only says 'provide structured information' without detailing what that structure looks like, whether it is read-only, or how it handles multiple/absent forms. The lack of behavioral detail 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear verb and object. The emoji 🆕 adds irrelevant flourish but does not detract from the message. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is somewhat thin. It identifies the main function but omits details about return format, behavior when no login form is found, and whether it works on the current page or across the site. These details would provide better completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which sets a baseline of 4. The description doesn't need to explain parameters but does hint at the output nature (username/password fields), which adds slight semantic value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Auto-detect login forms and provide structured information about username/password fields'. It uses a specific verb (auto-detect) and resource (login forms), and the focus on username/password fields differentiates it from sibling detection tools like detect_popups, detect_ads, and detect_captcha.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when you need login form detection. However, no explicit guidance is given about when to prefer this over related tools like get_form_analysis or smart_fill_form, nor are any exclusions mentioned.
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 for behavioral disclosure. It only says 'Activate browser automation,' which is vague about side effects, whether activation is idempotent, if it resets state, or what happens if called repeatedly. It does not describe any prerequisites or consequences beyond being a first step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action ('Activate browser automation') and immediately followed by the key usage constraint. Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and few parameters, the description is adequate for a simple enable tool. It explains what it does and when to call it, which is the minimal viable context. However, it lacks detail about session lifecycle, idempotency, or interaction with the 'status' sibling, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with both parameters (client_id, force_free) fully described in their own definitions. The description adds no parameter-level detail beyond what the schema provides. Per the rubric, this is a baseline 3; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Activate browser automation.' It also adds a critical scoping detail: 'Required first step before any browser interaction,' which distinguishes it from sibling tools like disable and status. This is a precise, non-tautological purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Required first step before any browser interaction.' This is a strong contextual signal, but it does not mention when not to use it (e.g., if already enabled) or name alternative tools (like disable). It lacks the 'when-not/alternatives' dimension needed for a 5.
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 full burden. It states the output includes ARIA roles, names, and states, but does not disclose default behavior for hidden elements, the return format, or any access requirements. This is comparable to the mid-tier example where mutation details were omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, immediately front-loaded with the primary action and resource. The emoji is decorative but does not detract. Every word contributes meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has moderate complexity with no output schema and no annotations. The description explains what the accessibility tree contains but lacks return format, default behavior details, or pagination/filtering implications, leaving gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the input schema (100% coverage), so the baseline is 3 as the schema carries the semantics. The description adds no additional parameter-specific context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'Get the full accessibility tree with ARIA roles, names, and states', using a specific verb and resource. The '(screen reader view)' qualifier distinguishes it from sibling tools like get_visual_map and get_interactive_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for accessibility inspection via the '(screen reader view)' context, which is clear guidance. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the action and source of the ID, omitting any details about simulated input, event triggering, error handling, or side effects. This is a significant gap for a user-facing 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the key information front-loaded. The emoji adds a minor new-feature signal but does not hurt. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool and full schema coverage, the description covers the core action and source of the ID. However, with no annotations and no output schema, it fails to disclose return behavior or failure conditions, leaving a moderate completeness gap for an interaction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes overlayId as the number on the visual overlay. The description merely restates this association ("by its overlay ID from the visual map") without adding format, validation, or usage nuances, so it adds no meaningful semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (hover), the target (element), and the identifier (overlay ID from the visual map). It is distinct from the sibling tool click_by_overlay_id by explicitly specifying hover rather than click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from the visual map' implies the prerequisite of obtaining an overlay ID via a visual map tool. It does not explicitly discuss alternatives or exclusions, but the context is clear enough for an agent to infer when to use it.
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. It discloses the fuzzy matching criteria (text, role, attributes) but does not state what the tool returns (e.g., a new selector or element), behavior on no match, or any side effects. This is a significant gap for an agent to understand the tool's 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It conveys the action, trigger, and method efficiently. The emoji is unnecessary but does not hurt clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (3 parameters, no nested objects), but the description omits the return value and failure behavior. Since there is no output schema, the description should explain what 'find the best matching element' actually returns. This gap makes it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters at 100% coverage, so the baseline is 3. The description adds meaning by explaining that textHint and roleHint are used for fuzzy matching, and mentions attributes (though no attribute parameter exists). This slight inconsistency prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Find') and resource ('the best matching element'), with a clear trigger condition ('when a selector fails') and matching method ('fuzzy matching on text, role, and attributes'). This distinguishes it from sibling tools like click_by_overlay_id or get_element_details, which do not perform healing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the usage context: 'when a selector fails'. This gives clear guidance on when to use the tool. It does not explicitly name alternatives or exclusions, but the unique purpose is evident from the 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 full burden. It discloses that a screenshot is captured with numbered overlays, implying a read-only screenshot operation. However, it does not mention potential side effects such as file saving for the 'path' parameter, full-page scrolling for 'fullPage', or whether the result is returned as a file path or inline image. This partial disclosure is adequate but leaves 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the core purpose, and includes actionable guidance about click references. Every sentence serves a purpose: stating the tool's function, elaborating on the output, and explaining how to use it. The emoji is harmless and does not detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should convey what the agent will receive. It says 'Shows a screenshot' but does not specify whether the screenshot is returned as a file, image data, or displayed inline. It also does not mention how parameters like fullPage, elementTypes, or includeLabels affect the map, which would be useful context for a tool with 6 optional parameters. The description is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already having a description. The tool description adds minimal parameter-level meaning beyond the schema, only implying that overlays can be filtered (e.g., through elementTypes) and labeled (includeLabels). Since the schema handles parameter semantics, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get visual map of interactive elements with numbered overlays' and explains it shows a screenshot with number badges. This distinguishes it from siblings like get_accessibility_tree (text-based) and click_by_overlay_id (action-oriented). The reference to 'click(42)' style links it to subsequent interaction tools, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly presents a usage pattern: 'Use "click(42)" style references', indicating this tool is a precursor to interacting via overlay IDs. While it doesn't contrast with alternatives like get_interactive_map, the context is clear for an agent to know when to invoke it—before clicking or hovering by number. The absence of explicit exclusions leaves it at a 4 rather than 5.
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:

[![superior-browser-mcp MCP server](https://glama.ai/mcp/servers/SikandarMirza/superior-browser-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SikandarMirza/superior-browser-mcp)

Score Badge

Copy to your README.md:

[![superior-browser-mcp MCP server](https://glama.ai/mcp/servers/SikandarMirza/superior-browser-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SikandarMirza/superior-browser-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/SikandarMirza/superior-browser-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server