Browser MCP
Server Quality Checklist
Latest release: v1.28.0
- Disambiguation5/5
Each tool has a clearly defined purpose, and overlapping tools explicitly reference when to use one over the other (e.g., browser_fill vs browser_set_date vs browser_set_combobox, browser_upload_file vs browser_drop_file). The descriptions are detailed enough that an agent can reliably pick the correct tool for a given scenario.
Naming Consistency5/5All tools follow the consistent browser_verb_noun snake_case pattern, making the set highly predictable. Even special-purpose tools like browser_click_xy and browser_extract_list fit the pattern well enough to remain unambiguous.
Tool Count2/5At 40 tools, the surface is quite heavy and exceeds the 25+ threshold for a 'too many' rating. While the breadth covers many browser automation scenarios, the large number increases selection cost and cognitive load for agents.
Completeness5/5The toolset covers the full browser automation lifecycle: navigation, interaction, extraction, frames, tabs, cookies, storage, console, network, dialogs, uploads, screenshots, and user fallback. There are no obvious dead ends or major missing operations for a general browser MCP server.
Average 4.1/5 across 40 of 40 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 7 community issues answered or closed in the last 6 months
- 114 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action without addressing critical details like whether existing cookies are overwritten, default values for parameters like secure or sameSite, or required domain/URL context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but not suitably sized for a tool with 9 parameters. It lacks front-loaded context or structure, though it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is inadequate. It does not explain return values, side effects, or usage context, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any meaning beyond the schema's property descriptions. It simply repeats the overall action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and resource 'cookies' for a domain, making the tool's purpose obvious. However, it does not explicitly distinguish from sibling tools like browser_get_cookies, though the action difference is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives (e.g., browser_get_cookies). There is no mention of prerequisites, such as needing a page loaded, or situations where setting cookies might be inappropriate.
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 provided, and the description does not disclose behavioral traits such as whether cookies are from all sources, if the domain must match the current page, or what the return format is. Essential information for a read operation is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is minimally complete. However, it lacks any mention of return value, error cases, or prerequisites, which would aid completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The description adds a concrete example ('.stripe.com') but does not elaborate on domain format or behavior beyond the schema. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (cookies) with a domain constraint. It distinguishes from siblings like browser_set_cookies and browser_get_local_storage by specifying 'cookies' and 'domain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., browser_get_local_storage) or prerequisites (e.g., page must be loaded). The description lacks context for appropriate invocation.
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, and the description is minimal. It does not disclose behavioral traits such as overwriting existing keys, persistence within the session, or potential side effects like triggering storage events. For a mutation tool, this is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no unnecessary words. Front-loaded and perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse. It omits crucial context like return value (or lack thereof), error conditions, and behavior when the page is not ready. The agent likely needs more information to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameters. The description adds no additional meaning about allowed values, size limits, or formatting. Baseline 3 is appropriate as it does not detract but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set'), the resource ('localStorage key-value pair'), and the context ('on the current page'). It unambiguously distinguishes this from siblings like browser_get_local_storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool. It does not mention prerequisites (e.g., page must be loaded, localStorage must be accessible) or alternatives. The agent receives no context for decision-making.
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 only states that the tool gets content, but does not disclose behaviors like whether it waits for page load, works on iframes, or handles dynamic content. The mutability or side effects are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of 12 words that efficiently communicates the tool's purpose and output format. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description is mostly complete. It covers the key functionality, though it could mention behavioral details like page load state requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter (format with enum and description). The tool description adds minimal extra meaning ('as text or HTML' which mirrors the enum values). Since schema coverage is 100%, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'content of the current page', and specifies output formats 'text or HTML'. It distinguishes from sibling tools like browser_screenshot (visual) and browser_console_logs (logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives such as browser_screenshot or browser_execute_script. The description only implies getting content, but does not mention prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to clarify whether pixel scrolling is relative or absolute, what happens when both selector and pixel parameters are provided, or error behavior (e.g., element not found). These omissions could lead to incorrect usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and contains no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It omits critical behavioral details (e.g., parameter priority, smooth scrolling, error handling). For a tool with simple parameters, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. The description adds 'by pixel amount' and 'to an element' but these are already implied by the parameter descriptions. No new semantic information beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Scroll' and the resource 'the page', with two distinct modes: to an element or by pixel amount. This effectively differentiates from sibling tools like browser_navigate or browser_click, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage context: 'Useful for reaching elements below the fold.' However, it does not specify when to use pixel scrolling vs. selector scrolling, nor does it mention alternatives or when not to use this tool.
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 provided, so description carries full burden. It describes navigation and reading but does not disclose how the token is returned, side effects on browser state, prerequisites, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 18 words, front-loaded with verb and clear purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with one parameter, but lacks clarity on return value (the token) and prerequisites (e.g., being logged in). No output schema compounds the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds 'slug' context and examples, providing modest additional meaning beyond the schema's short description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Navigate to and read) and the resource (provider's API settings page). Distinguishes from sibling tools which are general browser actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for reading API tokens, but lacks explicit guidance on when to use versus alternatives like browser_navigate or browser_get_page_content. No exclusions or context provided.
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 full burden. It mentions the dialog can include fields and returns responses, but lacks details on blocking behavior, cancellation handling, timeout consequences, or what happens if the user dismisses the dialog.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every word adds meaning. No redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists; the description only says 'Returns user responses' without detailing the response format or how to interpret cancellation/dismissal. This is insufficient for a tool expecting user interaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by grouping use cases and explaining that omitting fields yields a simple confirmation, which clarifies parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows an overlay dialog for user interaction, lists specific use cases (credentials, 2FA, CAPTCHA, OAuth), and notes it returns responses. This distinguishes it from sibling tools like browser_solve_captcha or browser_handle_dialog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when user input is needed but does not explicitly state when to use versus alternatives or provide when-not-to guidance. The context of sibling tools suggests scenarios, but no direct exclusions or alternatives are mentioned.
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?
Discloses that only session-owned tabs can be closed, but does not mention error handling, return behavior, or side effects. No annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences, front-loaded, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a simple one-param mutation tool. Minor gap: does not describe behavior when tab not found or already closed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides full coverage (100%) for the single parameter with a description. The tool description adds a constraint but no new semantic detail beyond what schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (close), resource (browser tab), and method (by ID). Distinguishes from siblings like browser_switch_tab and browser_list_tabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use by requiring tab_id from list_tabs and adds a constraint (only session-owned tabs), but no explicit when-to-use or alternatives mentioned.
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 must carry full behavioral transparency. It mentions the effect (triggering tooltips, menus, hover states) and support for selectors, but lacks details on failure modes, state changes, or element restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with purpose, and contains no unnecessary words. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple hover action with well-covered parameters and no output schema, the description is sufficiently complete. It could mention that the hover is temporary, but overall it adequately informs the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters. The description adds value by clarifying selector types ('Supports CSS and text selectors'), but the duration parameter is already well described in the schema. Overall, minimal addition beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('hover') and resource ('element'), clearly stating the action and purpose: 'trigger tooltips, dropdown menus, or hover states.' It distinguishes well from sibling tools like browser_click and browser_fill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to trigger hover-dependent UI) but does not explicitly state when to avoid or provide alternatives. Given the many sibling tools, more explicit guidance would be helpful.
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?
Without annotations, the description bears the full burden. It implies a read-only operation but does not specify scope (e.g., all windows or current window) or any limitations. Basic but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description covers the output. However, it does not specify the structure of the returned data (e.g., array of objects), which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema provides no details. The description adds meaning by specifying the output (URLs and titles), which is valuable beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all open browser tabs with their URLs and titles' clearly states the verb (list), resource (browser tabs), and output (URLs and titles), distinguishing it from sibling tools like browser_switch_tab or browser_close_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_switch_tab or browser_get_new_tab. The description only states what it does.
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 provided, so description must convey safety. States 'in the current page' implying no side effects, but does not clarify scope (e.g., nested frames) or behavior when no frames exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with essential information, no wasted words, front-loaded with verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters or output schema, the description adequately covers the action and output. No further detail needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema is empty with 100% coverage. Description adds nothing extra but is not required to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action 'List all frames' with specific resource 'current page' and outputs 'URLs and indices'. Distinguishes from sibling 'browser_select_frame' which is a selection tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'browser_select_frame'. Lacks context on prerequisites or usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default behavior (reuse tab) and a key behavioral trait (no tab spam). However, with no annotations, it could further explain side effects like page load events or dialog handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no unnecessary words. Every sentence contributes to understanding what the tool does and how to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core functionality and parameter usage adequately. Given the simplicity (2 params, no output schema), missing details are minor; however, it could mention prerequisites like page load state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond the schema by explaining the rationale for 'new_tab' (keep current page open) and the default reuse behavior. The schema already describes both parameters, so the description enhances context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Navigate the active browser tab to a URL') and the resource ('URL'). It is obvious among siblings, though no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use the default behavior vs. 'new_tab=true' ('Reuses the current tab by default ... Pass new_tab=true only when you need to keep the current page open'). Lacks explicit comparison to sibling tools like browser_get_new_tab.
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 full burden. It mentions waiting for an element and supports selectors, but does not disclose behavior on timeout (e.g., error thrown), default timeout, or whether it blocks until element appears. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. Every word adds value: states verb, resource, and supported selectors. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not mention return values (e.g., success indication) or error conditions (e.g., timeout). It could also clarify that this is typically used before other actions like clicks or fills. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds value beyond schema by providing examples of text-based selectors (e.g., 'text=Success', 'button:text(Next)'). This clarifies the format for the selector parameter, which the schema alone does not demonstrate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Wait for an element') and the resource ('on the page'), and distinguishes from siblings like browser_wait_for_network by specifying element waiting with CSS/text selectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (wait before interacting) but does not explicitly state when to use or alternatives, nor provide exclusions. The sibling list includes other waiting/action tools, but no guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the installation of an interceptor and the return behavior (last N messages). It does not mention removal or performance impact, but for a simple tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every sentence adds value. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description covers purpose, side effect, and return value. It lacks details on edge cases like empty logs, but is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'count', with a description in the schema. The description adds no new semantics beyond indicating the parameter controls the number of messages returned. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get recent console.log/warn/error messages from the page', providing a specific verb and resource. It distinguishes from sibling tools like browser_get_page_content and browser_execute_script, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a side effect ('Installs a lightweight interceptor on first call') but does not explicitly state when to use versus alternatives or when not to use. Since no sibling tool directly competes, guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description implies a simple activation without side effects, but lacks details on behavior such as whether the window comes to focus or if the tab must already be open. This is adequate for a straightforward action but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two short, front-loaded sentences with no wasted words. The action is stated first, followed by essential guidance on obtaining the tab ID.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly complete. It could mention that the tab must exist, but the guidance on getting IDs from sibling tools helps imply that. Overall, it covers what an agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description only repeats the parameter name ('tab ID') without adding new meaning beyond the schema's description ('Tab ID to activate'). Baseline score of 3 is appropriate as the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Switch to a specific browser tab by ID') and explicitly names sibling tools (browser_list_tabs, browser_get_new_tab) for obtaining the required ID, differentiating it from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool by instructing to get tab IDs from sibling tools, but does not state exclusions or explicitly say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does so well by explaining the wrapper behavior, the accepted `script` alias, the expression-only requirement, and the top-level `return` syntax error. It does not mention side effects or return-value handling, which prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense, front-loaded sentences. The purpose appears immediately, and every subsequent phrase adds critical caveats. There is no filler or redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-required-parameter tool with 100% schema coverage, the description covers the essential syntax traps and invocation requirements. It does not state whether the expression's value is returned, but this is a minor gap for such a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the expression/IIFE requirement, so the baseline is 3. The description adds value beyond the schema by warning about the `script` alias, prohibiting statements, and explaining why top-level `return` fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action and resource precisely: 'Execute JavaScript in the current page.' It is clear and unambiguous, though it does not explicitly contrast with sibling tools. Since it is the only script-execution sibling, ambiguity is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: run JavaScript in the live page, with strict invocation constraints. It does not name alternatives or exclusion cases, but the 'current page' scoping is enough to separate it from most sibling 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?
No annotations are provided, so the description carries the burden. It discloses the tool returns the most recently opened tab, but does not specify side effects or return format. The description is adequate but not rich in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately conveys purpose and usage, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not specify what is returned (e.g., tab ID or object). Given the simplicity and common sibling tools, it is somewhat incomplete, but still usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty. The description does not need to add parameter details. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the most recently opened tab and provides concrete use cases (clicking links, OAuth popups). It distinguishes from sibling tools like browser_list_tabs and browser_switch_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use this tool ('after clicking links that open new tabs, OAuth popups, etc.'), giving clear context. However, it does not mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses meaningful behavioral details: the action is a 'true double-click' implemented as 'two trusted press/release pairs with escalating clickCount', which goes beyond a simple 'double-click'. It does not mention side effects or return values, but for a click action the behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both purposeful. The action and its key behavioral trait are front-loaded, and the use-case guidance is concise without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition covers what the tool does, why it exists, and the specific condition under which to use it. Given the simple structure (one param, no output schema), this is nearly complete. It could mention alternatives explicitly or what happens after the double-click, but those omissions are minor for this action type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'selector' is fully described in the schema as 'CSS or text selector' (100% coverage), so the description does not need to add much. It slightly reinforces the targeting through 'on an element', but adds no new semantics beyond what the schema already provides. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'True double-click on an element' and explains it as 'two trusted press/release pairs with escalating clickCount'. It also differentiates itself from sibling click tools by clarifying the use case where two single clicks would trigger inline-rename (e.g., OWA month view).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit 'Use for...' instruction with concrete examples (calendar events, file lists) and explains why this tool is needed ('two single clicks would trigger inline-rename instead'). It does not explicitly name an alternative tool or provide a when-not-to-use condition, but the context is sufficiently clear to guide an agent.
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 provided. The description discloses key behavior (CORS-free, background context) but doesn't mention response format, error handling, or potential side effects. Could be more 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with key information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description adequately explains the tool's purpose and use case. Could mention return behavior, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters. The description adds no extra meaning to individual parameters beyond what the schema provides, baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool makes an HTTP request from the extension background, not subject to CORS, and distinguishes it from page-context fetch. Examples like API calls to Google, Stripe, Slack further clarify purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when page-context fetch would be blocked by CORS or CSP. Provides concrete examples of useful API calls, offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It clearly indicates a read operation with no side effects, which is appropriate for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (two sentences), front-loaded with essential information, and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and no output schema, the description provides sufficient context. It could mention the return format (string or null) but is not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description essentially repeats the schema description for the 'key' parameter without adding deeper semantics or usage details. Baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read localStorage'), the resource ('from the current page'), and the behavior with optional key. It effectively distinguishes from sibling tool browser_set_local_storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (reading localStorage) and how to use it (with or without a key). However, it does not explicitly state when not to use it or compare with alternative tools for other storage.
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 provided, so description carries burden. Describes modifier keys but does not disclose side effects, limitations, or whether it simulates physical keypress. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with examples and use cases. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and usage contexts. No output schema, so missing return info is acceptable. Sufficient for a press-key tool with 6 params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds value by listing key examples and modifier key usage, helping the agent understand context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it presses a keyboard key, lists specific keys (Enter, Tab, Escape, ArrowDown) and uses cases (forms, dropdowns, dialogs). Distinct from sibling tools like browser_click and browser_fill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios (submitting forms, navigating dropdowns, closing dialogs). Does not mention when not to use or alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explains that events are trusted CDP mouse events and explicitly warns that native Chrome context menus do not open. This is valuable and goes beyond what the tool name alone communicates, though it does not describe return values or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the action and purpose, the second provides a critical limitation. The most important caveat is placed prominently, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers purpose, valid usage scenarios, and the key behavioral limitation. It does not mention what happens when the selector does not match or what the tool returns, but these are minor given the simplicity and lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the sole parameter as 'CSS or text selector' with 100% coverage. The description does not add additional meaning about selector format, scoping, or expected element state, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Right-click an element') and the intended outcome ('open page-level context menus'). It is clearly distinct from siblings like browser_click, browser_double_click, and browser_click_xy because it names right-clicking and context-menu behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool: for applications like OWA/Google Docs that render in-page context menus. It also gives an important exclusion: Chrome's native context menu will not open via CDP. It does not explicitly name alternative tools, but the usage context is fairly clear.
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?
Describes executing JS in iframe, but omits that code parameter is optional with default returning text content (only in schema). No annotations provided, so description carries burden; lacks mention of side effects like context persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with full schema coverage and no output schema. Could mention default behavior of code parameter but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds value by reinforcing that frame_index comes from browser_list_frames. The optional code with default is not mentioned, but schema already describes it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes JavaScript in a specific iframe by frame index, distinguishing it from browser_execute_script likely for main frame. It includes a prerequisite (use browser_list_frames first).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use browser_list_frames first to find the right index, giving clear guidance on preparation. Does not explicitly state when not to use, but context from siblings implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It details the solving strategy: auto-click first, AI vision analysis, then user fallback, and mentions returning detection info and solving status. This sufficiently informs the agent of expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and contains no extraneous information. It efficiently covers purpose, process, and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description states it 'returns detection info and solving status,' which is sufficient for a high-level understanding. However, details about the structure of the return value are omitted, leaving minor ambiguity for agents that need exact formatting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema's parameter descriptions (cells and action enum). It does not elaborate on formatting or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Detect and solve CAPTCHAs on the current page' and lists specific CAPTCHA types (reCAPTCHA v2/v3, hCaptcha, etc.). It distinguishes itself from sibling browser tools by focusing solely on CAPTCHA handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a CAPTCHA is encountered on the page. It does not explicitly exclude scenarios or mention alternative sibling tools, but the specialization makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that it monitors real network traffic via Chrome DevTools Protocol, but does not specify behavior on timeout or error. For a simple wait tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose, second gives usage context, third mentions implementation. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the tool's purpose is simple. It does not describe return value, but for a wait action this is acceptable. Covers all essential aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no specific parameter semantics beyond what the schema already provides (timeout and url_pattern).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('wait') and resource ('network request'), clearly distinguishing it from generic waits like `browser_wait`. It also mentions the context of clicking buttons that trigger API calls, tying it to a common use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('after clicking buttons that trigger API calls') and implies it ensures data is loaded. However, it does not mention when not to use it or compare with alternatives like `browser_wait`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the full flow: click → type → wait for listbox → click option. Notes multi-select support and mentions wait_ms parameter. No annotations provided, so description carries full burden. Lacks details on error handling or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose and key flow details, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the action well but lacks information about return values or error scenarios. No output schema exists, so description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context by explaining the auto-detection of multi and the typing flow, which adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets values on autocomplete/combobox inputs, describing the handled flow. Distinguishes from browser_select_option by specifying when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when browser_select_option fails due to lazy rendering, and mentions multi-select support. Could be more explicit about when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses two key behavioral traits: 'fully trusted mouse events' (events bypass isTrusted checks, a meaningful differentiator) and the CSS-pixel coordinate space. It omits failure behavior (e.g., nothing at those coordinates, out-of-viewport values), but the core behavioral profile for an escape-hatch click is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: the first front-loads the core function, the second supplies the triggering condition, and the third adds the coordinate workflow. Every sentence earns its place and the escape-hatch intent is immediately graspable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter escape-hatch tool with no output schema and no annotations, the description covers what it does, when to use it, and how to gather inputs. The only gap is expectations for return/failure behavior when coordinates point at nothing, which is minor for a simple click action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — x and y are already documented as CSS pixels from left/top of viewport, so the baseline is 3. The description adds modest value by pairing the screenshot workflow ('read the button's position, click its center') with coordinate acquisition, but it does not add meaning beyond the schema's parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Click at raw viewport coordinates (CSS pixels) with fully trusted mouse events.' The 'ESCAPE HATCH' framing plus 'resists every selector strategy' clearly distinguishes it from selector-based siblings like browser_click, so an agent can tell them apart without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use condition: 'Use when a visible button resists every selector strategy,' with concrete example contexts (Azure portal dialogs, Knockout-bound divs, canvas UIs). It also prescribes an exact workflow — screenshot, read coordinates, click center — and names the companion tool browser_screenshot, so nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the arm-and-return behavior, the blocking wait mode, and the underlying hazard of dialogs freezing the tab. It doesn't state what happens if no dialog appears within the timeout, but the schema's timeout parameter partially covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The core behavior is front-loaded, followed by the most critical usage warning and the wait caveat. Every sentence contributes necessary operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a narrow dialog-handling tool with four fully documented parameters, the description covers the essential ordering, blocking behavior, and timeout meaning via schema. It doesn't describe the return value or no-dialog edge case, but these are minor for this tool's simple arming operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mostly restates the wait timing note already present in the schema. It does not add meaningful new meaning to text, action, or timeout beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Arm automatic handling') with a clear resource ('the next JavaScript alert/confirm/prompt on the active tab'). It also adds the crucial timing distinction ('Call this BEFORE the click') that makes the tool's purpose unmistakable. This clearly differentiates it from the browser sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to call the tool: before the click that opens the dialog. It also provides a precise exclusion—wait=true only when the dialog is already opening—and explains why the ordering matters via the tab-freeze behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the key trait that files are set programmatically via the Chrome Debugger API and that no dialog is needed, which prevents the agent from expecting an OS file-picker interaction. It could additionally mention side effects or return behavior, but the core non-obvious behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. It front-loads the core purpose, adds the key mechanism, and immediately routes to the sibling tool when applicable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter complexity and a complete schema, the description provides enough context for tool selection and invocation. It lacks only minor details about post-upload behavior and return value, which are not critical for deciding to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented with aliases, examples, and a default selector. The description does not add meaningful parameter-level detail beyond what the schema already provides, so 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Upload) and resource (a <input type="file"> element), and distinguishes this tool from browser_drop_file by calling out visible file inputs vs drag-drop zones. An agent can recognize exactly what this tool is for without opening other definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use browser_drop_file for drag-drop zones without a visible file input, giving a concrete when-not-to-use condition and naming the alternative. This is clear routing guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses auto-scrolling, real mouse events, and compatibility with SPAs and CSP-strict sites, adding valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus examples, no fluff, front-loaded with key action and supported selector types. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a click action with one parameter, the description covers behavior (auto-scroll, real events) and selector formats adequately. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, description adds examples of selector formats (CSS and text) that enhance understanding beyond the schema description, justifying above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Click an element on the page' with a specific verb and resource, and distinguishes from sibling tools like browser_hover and browser_fill through the focus on clicking and selector types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of selectors and mentions auto-scrolling and real mouse events, implying usage context. Does not explicitly state when not to use or alternatives, but the examples guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the heuristic-based approach (finds close affordance via aria-label, text content, or × button) and mentions return value. Without annotations, it carries full burden and adequately describes behavior, though it could mention potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. Front-loaded with the main action, each sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameters, and heuristics. Schema coverage is 100% and description compensates for no output schema by stating it returns a list. Could be more specific about return format but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains 'non_critical' preserves user data by skipping editable form inputs, and 'max_passes' handles chained overlays. This helps the agent choose correct parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool dismisses visible popups, modals, tooltips, banners, and overlays in one call. It uses a specific verb ('dismiss') and resource ('overlays'), and distinguishes it from sibling tools like browser_click or browser_handle_dialog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: when a flow is interrupted by unexpected dialogs with examples (cookie banners, onboarding tooltips, Meta Ads prompts). Does not explicitly state when not to use, but the guidance is clear and includes rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description effectively conveys key behavioral traits: it captures only the visible area and returns a base64 PNG or saves to disk based on the path parameter. It could mention prerequisites like page load state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences. No unnecessary words. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the core behavior, output format, and parameter effect. It is complete and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the path parameter already described. The description adds value by explaining the conditional output format (base64 vs. file save) based on parameter presence, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Take a screenshot' and specifies the resource 'visible area of the current tab'. It effectively distinguishes from sibling tools, as no other sibling performs screenshot actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (taking a screenshot of the current tab) and explains the conditional behavior based on the path parameter. However, it lacks explicit guidance on when not to use it or any alternatives, though none exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It details the fallback strategy (native, masked, ARIA picker) and mentions read-back verification and skip_picker option, adding transparency beyond basic input setting. Could mention error behavior if all methods fail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the main action. It is concise without being terse, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description adequately explains the tool's behavior, when to use, and the skip_picker option. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters (100%), so baseline is 3. The description adds context by explaining the strategy and the role of skip_picker (skipping calendar navigation) beyond the schema description, providing operational meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a date input robustly, listing specific input types (native, masked, calendar pickers) and explicitly distinguishes from sibling tool browser_fill. Verb+resource 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool instead of browser_fill when fill fails or for calendar-widget inputs, providing clear when-to-use and when-not-to-use guidance with a specific alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does well by explaining the hidden-input search scope, the native OS file-chooser interception, and that the dialog never appears. However, it does not disclose failure behavior, such as what happens if neither strategy finds a target or if the file path is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary trigger condition ('when browser_upload_file fails'), then organizes the two strategies clearly. Every sentence earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the lack of annotations, and the absence of an output schema, the description covers the main contextual needs: when to use, how the two strategies work, what the selector refers to, and a real-world example. The only notable gap is the absence of success/failure indicators or behavior when both strategies fail, which would be useful for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds real semantic value by clarifying that the selector's meaning depends on the strategy: it acts as a drop-zone target for strategy 1, but as the button that opens the dialog for strategy 2. It also reinforces the file alias, which is already in the schema, but the strategy-dependent selector clarification pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Upload a file when browser_upload_file fails.' It clearly distinguishes itself from the sibling browser_upload_file by explicitly positioning this tool as the fallback. It also outlines two concrete strategies, making the 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: when browser_upload_file fails. It then provides decision guidance between the two strategies: strategy 1 when a hidden file input exists in the subtree or up to 2 ancestor levels, strategy 2 when no input exists at all, with a concrete example (Google Ads). This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It mentions auto-scrolling, focusing, and working on CSP-strict sites via Chrome Debugger API. It does not specify if the field is cleared before filling, but 'fill' implies replacement. Good transparency overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with the primary action. No waste; every sentence provides useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 params and no output schema, description covers purpose, usage guidelines, behavioral traits, and parameter semantics adequately. Lacks explicit mention of whether existing value is cleared or return value, but not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds semantic value by stating selector supports CSS AND text-based selectors, and that auto-scroll/focus behavior applies. This aids agent understanding beyond the schema's type and required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fills a form input field with a value, supporting CSS and text selectors. Explicitly distinguishes from sibling tools browser_set_date and browser_set_combobox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'Fill a form input field with a value.' Also gives clear alternatives: 'For date inputs use browser_set_date, for autocomplete/combobox use browser_set_combobox.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It states the tool checks the install, detects duplicate extensions, returns a verdict and fix steps, and is 'read-only, and safe to call speculatively — never sends anything anywhere by itself.' It also explains the opt-in npm check and its default-off behavior, which is important context for an agent deciding whether to call it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each sentence contributes: trigger conditions, install-check behavior, return value, and safety guarantees. It is front-loaded with the purpose and automatic-call instruction, and the technical detail about BROWSER_MCP_CHECK_NPM earns its place. It could be tightened slightly but remains well-structured for its complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a feedback/reporting tool with no output schema and no annotations, the description covers everything an agent needs: when to call, what it does internally, what it returns, and its safety profile. The input schema fills in parameter details, and no important behavior is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add parameter-level meaning, but it does provide high-level context for why the tool is called. Per the baseline rule for high schema coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Self-diagnosis + feedback in one call,' naming both the action and the resource involved. It clearly distinguishes this tool from the operational browser_* siblings by specifying it is for when 'Browser MCP itself gets in your way,' not for ordinary browser interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is explicitly prescribed: 'Call this AUTOMATICALLY, without asking the user, the moment Browser MCP itself gets in your way.' It enumerates concrete triggering conditions such as tool errors, timeouts, extension connection failures, missing capabilities, and tells the agent to use it before telling the user 'browser-mcp cannot do X'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose the core behavior: a forced detach and re-attach of the debugger, including the specific failure signature it addresses. It does not mention potential side effects on the page or active execution, but the recovery framing makes the behavior reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense, well-structured sentence that front-loads the action with the 'RECOVERY:' marker, then gives the diagnostic context and the comparison to reloading. Every clause earns its place with no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter recovery tool, the description covers the trigger, the distinguishing condition, and the preferred alternative. It does not explicitly state what a successful re-attach looks like or how to verify success, but this is a minor gap given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is fully covered, so the baseline is 4. The description adds useful scope by specifying 'on the current tab,' even though this is not a formal parameter, helping the agent understand exactly what will be affected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb phrase 'Force-detach and re-attach the Chrome debugger on the current tab' states a specific action on a specific resource. It is clearly distinguished from the sibling interaction tools by being a recovery operation rather than a normal browser action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition: use it when interactive tools like click/fill/press_key time out or report the ghost-attach error while list_tabs still works. It also frames the alternative—reloading the extension—and explains why this tool is preferred, which is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but the description explains the tool's behavior fully: it returns a URL for the user to click, and it does not modify browser state. Slight lack of explicit non-destructive statement, but clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose first, then proactive usage, then parameter usage, then rationale. Every sentence is necessary and contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no output schema, no side effects), the description covers all needed aspects: purpose, triggers, parameters, and expected agent action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds usage context (how to call with intent and optional fields, what to do with the result). Adds value beyond schema by explaining the interaction flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns info and pre-filled URLs for submissions, with specific verbs ('returns', 'submit'). It is distinct from sibling tools like browser_navigate or browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists four triggers (feature wish, missing/broken, how it works, cool builds) and tells the agent to call proactively. This sets clear when-to-use boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the scrolling mechanism, automatic scrollable-ancestor detection, deduplication of row text, and the reached_end return value. It does not detail failure modes or potential side effects like triggering lazy-loading requests, but the core behavior is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, usage guidance, rationale, parameter guidance, and return behavior are each covered in a clear, front-loaded structure. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 6 parameters and no output schema, and the description covers all essential decision-making information: what it does, when to use it instead of a sibling, how to invoke it, what the selector should be, and what the return value indicates. The remaining parameter details are fully documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful parameter context beyond the schema: it clarifies the selector should match ONE repeating row, gives concrete selector examples for different UIs, and states that the scrollable ancestor is auto-detected. This helps an agent choose the right selector value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: read EVERY row of a long or virtualised list by scrolling until no new rows appear. It clearly distinguishes itself from browser_get_page_content by naming it directly and describing the exact scenario where it applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this instead of browser_get_page_content whenever a page shows a repeating list longer than the viewport' and gives concrete examples such as Outlook mail lists, invoice tables, search results, and transaction histories. It also explains why the alternative fails in these cases, leaving no ambiguity about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It reveals the click-trigger-wait-click mechanism for custom dropdowns, the matching priority (exact value, exact text, partial text), and the failure behavior of failing loudly rather than falsely succeeding. This is strong behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main purpose, and every sentence adds distinct value: scope, mechanism, and sibling differentiation. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations and no output schema, the description provides enough context to call the tool correctly: target element types, the exact interaction flow, matching behavior, and the relevant alternative. The complexity of supporting both native and custom dropdowns is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds some useful behavioral context around how option matching is performed, but it does not add meaningfully to the parameter definitions already present in the schema, which are detailed and sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Select an option from a dropdown menu.' It clearly distinguishes native <select> handling from custom dropdown frameworks and explicitly points to browser_set_combobox for autocomplete cases, separating it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete when-to-use guidance by covering both native and custom dropdowns, and explicitly states when NOT to use it: 'For autocomplete (typing filters options) use browser_set_combobox instead.' This leaves little ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Agent360dk/browser-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server