Browser MCP
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation4/5
Most tools are clearly distinct, but browser_console_log and browser_get_console_logs are easily confused, and browser_wait/browser_wait_for could be ambiguous without reading descriptions. Overall, the purposes are well differentiated.
Naming Consistency4/5All tools use a consistent browser_ prefix and snake_case naming. However, there is a mix of verb-first (navigate, click) and noun-like (console_log, network_log) patterns, and some tools use 'get_' while others don't, creating minor inconsistency.
Tool Count2/5With 39 tools, the server exceeds the 25+ threshold for 'too many'. While the breadth reflects a comprehensive browser automation scope, the sheer number makes tool selection heavier and suggests possible consolidation.
Completeness4/5The tool set covers navigation, interaction, waiting, extraction, cookies/storage, console/network monitoring, and tab management—nearly all core browser automation needs. Minor gaps exist (e.g., no explicit alert/dialog handling or dedicated URL/page title getter), but most can be worked around via execute_js or snapshot.
Average 3.2/5 across 39 of 39 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. However, 'Set a cookie' only restates the tool's basic action and does not mention side effects (e.g., overwriting existing cookies), persistence, URL matching rules, or any security implications. No additional behavioral information is provided beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. The single sentence 'Set a cookie' does not earn its place because it adds no information beyond the tool name. It is not front-loaded with useful detail; it is simply a minimal restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, and no output schema, the description is severely incomplete. It omits return values, error conditions, behavioral details, and any contextual information about how cookies are set. The description is far too minimal for the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43% (3 out of 7 parameters have descriptions), yet the description provides zero parameter information. It does not mention required fields like 'url', 'name', or 'value', nor does it clarify any of the optional fields. With low schema coverage, the description fails to compensate by explaining parameter semantics.
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 'Set a cookie' clearly states the action (setting) and the resource (cookie). It is specific and unambiguous, though it does not explicitly differentiate itself from sibling tools like browser_set_storage or browser_get_cookies. This aligns with a clear purpose without sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., a current page), context for when setting a cookie is appropriate, or exclusion of cases where another tool might be preferred. The user is left without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of explaining behavior, but it reveals nothing beyond the action. It does not mention scroll behavior (e.g., whether it is smooth or instant), how direction and amount interact, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which is inherently concise, but it under-specifies the tool's purpose. It is more of a minimal label than an informative explanation, lacking the depth needed for an agent to fully understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters, no annotations, and no output schema, the description is too thin to provide a complete picture. It fails to mention that direction is required, that amount has a default, or how the scrolling is applied, leaving significant gaps in an agent's understanding.
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 has full description coverage for both parameters (direction and amount), so the description does not need to restate them. However, it also does not reinforce or add any contextual meaning to the parameters, resulting in no added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scroll the page' clearly identifies the action and resource, and there is no sibling tool that performs a similar scrolling function. It is direct and unambiguous, though it could be more descriptive about the page context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage solely from the tool's existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Click an element' and to use the ref, but does not describe what happens on success, failure, whether the tool waits for element actionability, or any side effects. The description is too brief to inform the agent about the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: 'Click an element. Use the exact ref from the latest snapshot.' It is front-loaded with the action and keeps every sentence useful. No unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description should explain return values and behavioral context, but it does not. It fails to mention what the tool returns (e.g., a snapshot, success status), how it handles missing or stale refs, or any permissions. Given the simplicity of the action, the description is too sparse to be fully 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 description coverage is 100%, with detailed descriptions for both 'ref' and 'element'. The tool description adds only 'Use the exact ref from the latest snapshot,' which largely reiterates the schema's 'ref' description. Since the schema already documents the parameters thoroughly, the description provides minimal added meaning, warranting the baseline score of 3.
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 clearly: 'Click an element.' This is a specific verb and resource. However, it does not explicitly differentiate from sibling tools like browser_right_click or browser_double_click, leaving some ambiguity about which click event is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is 'Use the exact ref from the latest snapshot,' which explains how to reference the element but not when to use this tool versus alternatives. There is no mention of when to prefer click over hover, type, or other interaction tools, nor any exclusions or prerequisites beyond using the snapshot ref.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. 'Monitor console.log/warn/error' is extremely vague: it doesn't clarify whether monitoring persists across page navigations, whether it accumulates logs in memory, what happens on stop, or how the 'get' action returns data. The tool's statefulness and side effects (if any) are completely undisclosed.
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 concise and free of filler, fitting within one short sentence. It effectively communicates the high-level purpose without excess. However, the brevity borders on under-specification, as it omits critical details about the action parameter and behavior, so it doesn't earn a 5.
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 has a single enum parameter and no output schema, the description still fails to explain observable behavior: what 'start' and 'stop' do, how 'get' returns logs, or what happens to accumulated logs. The existence of a sibling tool for getting logs adds confusion without clarity. The description is insufficient for an agent to use the tool correctly across all three actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, but the only description is 'Action'—essentially meaningless. The enum values (start, stop, get) are listed, but their semantics are not explained. The tool description doesn't elaborate on these actions either, so the parameter meaning remains ambiguous. Baseline 3 applies due to high coverage, but the description adds no value beyond the schema's minimal text.
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 'Monitor console.log/warn/error' clearly identifies the resource (console logs) and a specific action (monitor), which differentiates it from the sibling tool 'browser_get_console_logs' that likely retrieves logs. However, it doesn't explicitly state that this tool manages a monitoring session via start/stop/get actions, which would fully distinguish it from simply fetching 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 guidance is provided on when to use this tool versus alternatives like browser_get_console_logs. The actions start/stop/get suggest a lifecycle, but their intended usage contexts and prerequisites are not explained. There is no mention of when monitoring is useful or when to use 'get' instead of directly retrieving logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only states the action without revealing side effects (e.g., highlighting matches, scrolling to results) or the return format. It also does not clarify whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core action, making it highly concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks essential context such as what happens after text is found (e.g., highlighting, scrolling), whether multiple matches are handled, and how the agent should interpret the outcome. No output schema exists to compensate, leaving significant gaps for a full understanding.
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% with the parameter 'text' described as 'Text to find'. The description's phrase 'on the page' adds minimal context beyond the schema, but the schema already fully defines the parameter, so the baseline of 3 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 'Search for text on the page' uses a specific verb ('Search') and identifies the resource ('text on the page'), making the core purpose clear. However, it does not explicitly differentiate from sibling tools like browser_get_elements or browser_snapshot, which could also involve text retrieval.
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_get_elements or browser_snapshot. There is no mention of prerequisites, typical scenarios, or excluded cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without revealing important behavioral traits such as the need for a prior snapshot, whether the hover triggers side effects like tooltips, or any prerequisites. The schema's ref description covers some mechanics, but the main description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct (4 words) and directly to the point, which is appropriate for a simple tool. It is front-loaded and every word earns its place, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two well-documented parameters and no output schema, so the description need not explain return values. However, it omits workflow context, such as the need for a prior snapshot and the fact that hovering may reveal dynamic content. The schema partly compensates, making the description minimally complete but lacking contextual depth.
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%, with detailed descriptions for both 'ref' and 'element' parameters. The description 'Hover over an element' adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover over an element' clearly states the specific verb (hover) and resource (element). It distinguishes the tool from sibling actions like browser_click or browser_double_click by its unique action, but it does not explicitly differentiate itself from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use hover versus clicking, dragging, or other element interactions. The description gives no context about use cases like tooltips, drop-down menus, or hover-triggered content, so the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'monitor' without explaining the start/stop/get lifecycle, whether requests are logged persistently, whether it is per-tab or global, or if any side effects occur (e.g., altering request headers). This leaves critical behavioral traits undisclosed for an agent that must invoke start/stop/get actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the core purpose. It is efficient and avoids unnecessary words. However, it may be too sparse for a tool with multiple actions and a filter, making it slightly under-specified, though it still earns its place as a concise summary.
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 has three actions (start, stop, get), a filter parameter, no annotations, and no output schema, the description is far from complete. It leaves out expected return values, how to use the filter, whether monitoring is browser-wide or tab-specific, and potential interactions with other browser tools. An agent would lack critical information for correct invocation, especially for the 'get' action which implies reading collected data.
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% because both parameters (action and filter) have descriptions, but those descriptions are minimal ('Action' and 'Filter by URL'). The tool description adds no extra semantics, such as how the filter interacts with each action or whether filter is used during start or retrieval. The baseline of 3 is appropriate since the schema already documents the parameters adequately, but no additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'monitor' and identifies the resource as 'fetch/XHR network requests', making it clear what the tool observes. It is distinct from sibling tools like browser_get_console_logs, which handle console output rather than network activity. No ambiguity or tautology; it communicates the core function effectively.
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, nor any exclusions or prerequisites. The description does not hint at typical use cases (e.g., debugging API calls, tracking performance) or contrast with logging or console tools. It simply states what it does without 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 must carry the burden of behavioral disclosure. 'Open a new tab' does not explain whether the new tab becomes active, whether it navigates to the provided URL or opens a blank page, or what the return value is. This leaves key behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence with no wasted words. It is appropriately sized for a simple tool and immediately communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is minimal. It does not explain the behavior when 'url' is omitted, whether a new tab is automatically focused, or what the function returns. Given no output schema, the description should compensate but does not.
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 has one parameter 'url' with a clear description 'URL to open', and schema coverage is 100%. The tool description adds no additional meaning beyond the schema, but the schema already adequately documents the parameter.
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 'Open a new tab' clearly states the action (open) and the resource (new tab). It is specific enough to distinguish from siblings like browser_switch_tab or browser_close_tab, though it does not explicitly differentiate from browser_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like browser_navigate or browser_switch_tab. The description lacks any context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and omits any details about side effects, whether it operates on the current page, or whether it supports modifiers or key combinations. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and immediately clear, though it could arguably include more context without sacrificing conciseness.
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 simplicity, the description is somewhat adequate, but it lacks important operational context such as the fact that it operates on the current browser page and the absence of any mention of return values or waiting behavior. The presence of many sibling tools also increases the need for clearer differentiation, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description of the 'key' parameter with examples ('Enter', 'Tab', 'a', 'ArrowLeft'), achieving 100% coverage. The tool description adds no additional semantic meaning, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press a key on the keyboard' clearly states the action (press) and the target (a key on the keyboard), making the tool's purpose unambiguous. It does not explicitly distinguish from siblings like browser_type, but the action is specific enough to be self-explanatory.
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_type for text input or browser_click for mouse interaction. The description lacks any contextual cues about suitable scenarios or prerequisites (e.g., needing a focused element).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry safety and behavior info. It only states the action, without disclosing side effects like opening a context menu, visibility requirements, or whether the action is reversible. This is minimal and doesn't add value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy or fluff. It's front-loaded and appropriately sized given the schema's coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple action, the lack of usage guidance, behavioral disclosure, and context about context menu effects makes it incomplete. The tool could be used in many scenarios, but the description doesn't explain when right-click is appropriate or what to expect.
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 descriptions for both parameters (ref and element) are detailed and cover 100% of params, so the description doesn't need to add parameter info. The description itself adds no parameter semantics, matching the baseline for high schema coverage.
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 'Right-click an element' uses a specific verb and resource, clearly distinguishing it from siblings like browser_click and browser_double_click. However, it doesn't explicitly mention the use of aria refs or when to choose this over alternatives, so it's clear but not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't state when to use right-click vs hover or key press, nor any exclusions or context. The agent receives no direction on selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states the action itself and discloses no behavioral details such as whether the screenshot is saved to a file, returned as base64, captures the full page or viewport, or any side effects. This is essentially a tautology of the function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is immediately clear and front-loaded. Every word earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the action itself but lacks crucial context about what the output or result will be. With no output schema, the agent is left wondering whether the screenshot is returned directly, stored, or requires retrieval. This is a significant gap for a tool with minimal structured metadata.
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 explain parameter semantics. Per the rubric, a score of 4 is the baseline for tools with no parameters.
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 ('Take a screenshot') and the resource ('current page'). It is specific and unambiguous. However, it does not distinguish this from the sibling tool browser_snapshot, which could potentially be interpreted as a similar capture operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, or any exclusions. The description simply states the operation without context. For example, it does not clarify whether this should be used for visual debugging, documentation, or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It does not disclose timeout handling, whether it waits for visibility or just presence, what happens on timeout, or the return value. The term 'appear' is vague and leaves critical behavioral gaps.
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, concise sentence with no wasted words. However, it is also under-specified, which slightly reduces its value despite being appropriately sized.
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 absence of annotations and output schema, the description needs to explain return values and failure modes. It fails to do so and also does not clarify the timing semantics (e.g., default timeout is only in schema). The tool is left incomplete for an agent to use confidently.
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 provides descriptions for both parameters (selector and timeout), covering 100% of the parameter semantics. The description adds no extra meaning beyond restating that it waits for a CSS selector, which mirrors the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a CSS selector to appear, using a specific verb and resource. However, it does not explicitly distinguish itself from the sibling tool browser_wait, which may cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_wait. It simply states what it does without any context, exclusions, or use-case examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. However, it only restates the action without any additional details about effects, prerequisites, or failure modes. It adds no transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, directly stating the tool's purpose. It is efficiently front-loaded and contains zero waste.
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 to be complete. It does not explain return values, error conditions, or when to use double-click versus other actions. For a browser interaction tool, this leaves significant gaps in practical usage context.
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 has 100% description coverage for both parameters (ref and element), so the schema already documents their semantics. The tool description adds no extra parameter information, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Double-click an element' clearly states the action (double-click) and the resource (element). It distinguishes this tool from siblings like browser_click and browser_right_click by specifying the double-click action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus single-click or right-click alternatives. It does not mention typical scenarios (e.g., selecting words, opening items) or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats the basic purpose. It does not disclose side effects (DOM changes, navigation, network requests), return value behavior, async handling, or potential dangers. With no annotations, this is a critical omission for a powerful tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste. It is as concise as possible and front-loads the core action. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has only one parameter and no output schema, executing JavaScript on a page can produce side effects and returns a value. The description does not cover expected outcome, return format, or side effects, making it incomplete for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'script', which is described as 'JavaScript code'. The description adds no extra meaning beyond the schema, but the baseline of 3 is appropriate since the schema already provides full parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the resource 'JavaScript on the page', giving a specific action with scope. This distinguishes it from all sibling tools, which are for navigation, clicking, typing, etc., and none other execute arbitrary JS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention use cases, prerequisites, or exclusions, leaving the agent without explicit direction on when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the action of dragging. It does not disclose whether it simulates events (mousedown, mousemove, mouseup), whether elements must be visible or in viewport, what happens if refs are stale, or any side effects. The description is essentially a tautology of the tool name, offering no extra transparency.
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, concise sentence with no wasted words, and it front-loads the core action. However, it is so minimal that it borders on under-specification, lacking any structural elements like examples or additional context. It earns a 4 for being appropriately brief but not 5 because it omits useful structural guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and moderate complexity (4 required params), the description is incomplete. It does not explain the relationship between start/end elements and refs, whether the action waits for completion, or any side effects on the page state. Sibling tools likely have more detailed descriptions, making this tool's contextual information insufficient for an agent to use it correctly without extra inference.
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 has 100% coverage with descriptions for all four parameters (startElement, startRef, endElement, endRef), identifying source and target elements and their refs. The description 'Drag from one element to another' adds no semantic meaning beyond the schema, so the baseline score of 3 is appropriate since the schema already handles parameter understanding.
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 'Drag from one element to another' clearly states the action (drag) and the resource (elements), distinguishing it from sibling tools like browser_click or browser_hover which are all distinctly named and scoped. It is specific and unambiguous, providing a complete verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, lacks any mention of prerequisites (e.g., needing an active snapshot or specific element refs), and does not indicate scenarios where drag is preferable to other browser actions. It only gives a bare action statement with no contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description bears full responsibility for behavioral transparency. It states 'inject custom CSS' but does not disclose the effect scope (e.g., whether it persists across navigations, replaces existing styles, or is reversible). No details about side effects or limitations are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the action and target. Every word is meaningful and there is no redundant fluff. It is appropriately front-loaded for quick agent reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is minimally sufficient but lacks important context about the behavior of the injected CSS. It does not mention whether the styling persists, how it interacts with existing CSS, or if it affects the current page only. For a browser automation tool, this additional context would aid correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'css' with description 'CSS to inject'. The tool description repeats this concept but adds no new meaning. Since the schema already documents the parameter adequately, the baseline of 3 is appropriate, though the description does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Inject custom CSS into the page' with a specific verb (inject) and resource (custom CSS). It is distinct from most sibling tools like browser_navigate or browser_click, but does not explicitly differentiate itself from browser_execute_js, which could also inject CSS via JavaScript. Thus it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that browser_execute_js could be used for the same purpose, nor does it explain any prerequisites or scenarios where this tool is preferred. Usage is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., page load, unsaved form data loss), wait behavior, or error handling, leaving the agent with only the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose. Every word is necessary and there is no redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with full schema coverage, the description is minimally adequate. However, it lacks behavioral details such as return value or side effects, which would be useful given there is no output schema or annotations.
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% (the only parameter 'url' has a description). The tool description adds no extra meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigate to a URL' is a clear verb+resource statement. It distinguishes from siblings like browser_go_back and browser_go_forward by specifying a URL destination, though it does not explicitly clarify it applies to the current tab vs. opening a new tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool over alternatives such as browser_new_tab, browser_go_back, or browser_reload. The description only states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention that the tool operates on a select element, requires a valid ref from a snapshot, or triggers change events. This leaves the agent unaware of important operational details.
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 concise, consisting of a single short sentence with no redundant wording. It is front-loaded and easy to parse, though it could arguably be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description lacks usage guidelines and behavioral transparency. The schema covers parameter semantics, but the agent is left without sufficient context on when to use this tool versus other browser interaction tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (element, ref, values) already described. The tool description adds no extra semantic meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'select' and a clear resource 'dropdown', making the tool's function unambiguous. It distinguishes from sibling tools like browser_click or browser_type by targeting dropdown selection specifically.
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. There is no mention of prerequisites such as obtaining a snapshot to get the 'ref', nor any comparison with browser_click or browser_type for interacting with dropdowns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core function and output type, but does not disclose how it handles multiple tables, table headers, malformed selectors, or the exact structure of the JSON output. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essential operation and output format without any superfluous words. It is highly concise and immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with one optional parameter, the description lacks important context: no output schema exists, yet the return format is only vaguely described as 'structured JSON'. There is no mention of what the JSON contains, which table is selected if multiple match, or error behavior. This leaves the description incomplete for an agent to confidently use the 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?
The sole parameter 'selector' is fully documented in the schema with a description and default value. The tool description adds no additional parameter context, but since schema coverage is 100%, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Extract') on a specific resource ('a table') with a defined output format ('structured JSON'). It is easily distinguishable from sibling tools like browser_extract_meta and browser_extract_images, and the tool name reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention selection criteria, exclusions, or how it differs from extracting other content types. Context from sibling names implies the use case, but the description itself offers no explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits such as whether the operation is read-only, the format of returned logs, or potential side effects. It only states 'Get browser console logs' without any of this context, offering minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler words. It front-loads the action and resource, making it instantly understandable, and every word is relevant.
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, parameterless getter, the description is adequate but not complete. It doesn't explain what 'console logs' includes (e.g., errors, warnings) or how it relates to sibling tools, which could impact usage decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (100%) and there is nothing to document. According to the baseline rule, 0 params warrant a score of 4, and the description adds no extra parameter semantics needed.
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 the resource ('browser console logs'), making the tool's purpose evident. However, it doesn't explicitly differentiate from the similar sibling tool 'browser_console_log', so it misses the distinction criterion for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_console_log or browser_network_log. The description lacks context about prerequisites, typical use cases, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic purpose, but does not disclose whether the operation is read-only, what the return format is (e.g., text, attributes, element handles), or any side effects. This is a significant gap for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that states the core functionality in five words. There is no redundancy or filler, and it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should clarify what is returned (e.g., matched elements and their properties). It does not, and it also fails to mention default behavior like the limit of 50 results. The description is too sparse for an agent to predict the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'selector' and 'limit' have descriptions in the input schema. The description adds no additional semantic detail beyond what the schema already provides, but that is acceptable given the schema's completeness.
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 'Query elements by CSS selector' uses a specific verb ('Query') and resource ('elements'), and clearly distinguishes the tool from siblings like browser_find_text (which searches by text) or browser_get_links (which extracts links). It is unambiguous and concise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_snapshot or browser_find_text. There are no prerequisites, exclusions, or context about typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the read action without revealing what happens if 'key' is omitted, the return format, or error behavior. Minimal transparency for an effective agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no filler. Every word contributes to the core purpose, making it highly 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?
With no output schema and a minimal description, the agent has no information about return values, behavior when 'key' is omitted, or potential limitations. This is incomplete for a tool that reads storage data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters (key and type) with clear descriptions. The description adds nothing beyond what the schema already states, so it meets the baseline but does not enhance understanding.
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 'Read' and identifies the resource 'localStorage or sessionStorage', making the tool's purpose unambiguous. It clearly distinguishes from sibling browser_set_storage (write operation) and other browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_get_cookies or browser_set_storage. The read/write distinction is only implicit in the verb, but there is no explicit context on choosing storage over other browser state tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and visual effect but does not disclose whether highlighting is temporary, whether it modifies the DOM, whether it affects all matching elements or just the first, or if there are side effects. This is a significant gap for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words or repetition of the tool name. It is front-loaded with the action and effectively communicates the core function in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, but it is a browser interaction tool with potential side effects. The description is too sparse to be complete: it does not clarify scope (all matching elements vs first), lifetime of the highlight, or relationship to the current page. This ambiguity could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (color with default red, selector as CSS selector). The description adds no extra parameter semantics, but since the schema already documents them clearly, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Highlight' with a resource 'elements' and a modifier 'colored outline', clearly stating the tool's function. It distinguishes from siblings like browser_get_elements or browser_inject_css because no other tool performs visual highlighting. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as browser_inject_css or browser_get_computed_style. The description does not mention prerequisites (e.g., page loaded) or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the tool captures only <img> tags, whether it includes lazy-loaded or dynamically inserted images, or what the return format looks like. It is a minimal one-liner that provides no deeper insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is short, front-loaded with the action ('Get all images'), and contains no filler words. Every word contributes to the meaning, making it highly efficient.
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, read-only tool with no output schema, the description is mostly adequate. It conveys the essential function but lacks explicit mention of scope (current page) and potential limitations like excluding background images. Given the tool's simplicity, it is nearly 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?
The tool has zero parameters, so the description does not need to explain parameter meanings. According to the rubric, this yields a baseline of 4. The description is consistent with the empty parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all images with src, alt, and dimensions. The verb 'Get' and resource 'images' make it specific, and it is distinct from sibling tools like browser_screenshot or browser_get_links. A minor omission is not explicitly stating 'from the current page', but the intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. Sibling tools like browser_get_elements could also capture images, but the description does not differentiate or suggest preferred scenarios. It simply states what the tool does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not describe potential side effects, error conditions (e.g., what happens if the tab ID is invalid), or whether the operation is destructive beyond the obvious close. More context could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the primary action and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description and schema together provide enough context to understand the operation. However, it could be improved by noting that tab IDs come from list_tabs or that closing the active tab may switch focus, so a perfect score is not warranted.
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%, with the parameter tabId already documented as 'Tab ID to close'. The description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close a tab by ID' clearly states the action (close) and the resource (tab), with a specific method (by ID). It is distinct from sibling tools like browser_new_tab or browser_switch_tab, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention how to obtain a tab ID (e.g., from browser_list_tabs) or that closing a tab is irreversible. Context is limited to the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Extract...', implying a read operation but omitting whether the page must be loaded, whether the tool modifies state, or what failure modes exist. No extra behavioral context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. Every word adds meaning and the structure is entirely appropriate for the tool's simplicity.
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?
There is no output schema and no annotations, so the description must explain what the tool returns. It does not describe the format, keys, or shape of the extracted metadata, nor any dependency on a loaded page. The absence of return-value details makes it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description adds no parameter-specific details, but none are needed.
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 'Extract meta tags, OpenGraph, Twitter Cards' clearly specifies the exact data source (meta tags) and the action (extract), making it distinct from sibling tools like browser_get_links or browser_readability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It simply states the action without any contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply says 'Write' without explaining that it overwrites existing keys, that sessionStorage is cleared when the tab closes, or that the value must be a string. It also does not disclose potential side effects or whether the page must be loaded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's function without any filler or redundancy. It is appropriately sized for a simple operation and front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It omits important context like overwrite behavior, storage lifetime nuances, and any conditions that could cause the write to fail. This is a significant gap when the agent needs to understand the consequences of setting storage.
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 covers all three parameters with descriptions such as 'Key', 'Storage type', and 'Value', giving 100% coverage. The description does not add any meaning beyond the schema, such as clarifying value constraints or the relationship between type and storage behavior, 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?
The description 'Write to localStorage or sessionStorage' clearly specifies a verb (Write) and a resource (browser storage types), making the tool's purpose immediately obvious. It also distinguishes from the sibling tool browser_get_storage, which likely reads storage, and from cookie-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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to write to browser storage, but it does not explicitly state when to use it instead of alternatives like browser_get_storage or browser_execute_js. No exclusions, prerequisites, or recommended contexts are mentioned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately describes the action but adds no extra behavioral context such as whether the wait blocks the page, its effects, or common use cases. It is adequate but shallow for a tool that could benefit from noting it is a simple sleep.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, perfectly sized for the tool's simplicity. Every word contributes to the meaning with no waste.
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 with no output schema, the description sufficiently communicates its behavior. It lacks a note about potential blocking or relationship to 'browser_wait_for', but is otherwise complete for basic 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% (the 'time' parameter is described as 'Seconds to wait' in the schema). The description adds no additional meaning beyond the schema, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Wait for a specified time in seconds' clearly states the verb and resource, making it obvious this tool pauses execution. However, it does not distinguish itself from the sibling tool 'browser_wait_for', which likely waits for a condition, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'browser_wait_for'. It only defines the action without giving context, exclusions, or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation, which implies non-destructive behavior. However, with no annotations, it does not add further context such as return format, behavior on missing elements, or whether all properties are returned when not specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose without unnecessary 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?
As a simple getter tool, the description covers its core functionality, but it omits details about the return value format and optional behavior of the properties parameter. Given the lack of an output schema, this would benefit from additional context.
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 fully describes both parameters (selector and properties) with clear descriptions, so the tool description does not need to add parametric details. It does not provide additional semantics 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 uses the verb 'Read' and identifies the specific resource as 'computed CSS properties of an element'. This clearly distinguishes it from sibling browser tools like browser_get_elements or browser_execute_js.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description is limited to a single sentence with no contextual usage instructions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. 'Extract all links' states the core read-only behavior, but it does not detail what constitutes a link (e.g., anchor tags only, href attribute), what format the output takes, or any limitations. The behavior is basic but not fully 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 a single, concise sentence that is front-loaded and contains no filler. Every word adds value, making it an excellent model of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the absence of an output schema means the description should ideally clarify what 'links' returns (e.g., an array of URL strings, objects with href and text). This gap makes the description adequate but not fully complete for an agent needing return value details.
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 description coverage is 100% for the single optional 'filter' parameter, which is described as 'Filter by URL or text'. The tool description adds no additional parameter semantics, 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 'Extract all links from the page' uses a specific verb ('Extract') and resource ('all links from the page'), clearly distinguishing this tool from siblings like browser_get_elements or browser_extract_images. The purpose is immediately understandable and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or suggest other tools for different scenarios, leaving the agent without explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose what the returned list of tabs contains (e.g., tab IDs, titles, URLs) or whether any side effects occur. While 'list' implies a read operation, the lack of additional behavioral context leaves the agent uncertain about the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and immediately clear, making it an effective and concise statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is minimally viable but lacks detail about the return value structure. It could benefit from noting what information about each tab is provided, making it complete for an agent to use confidently.
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 input schema is fully covered and no parameter explanations are needed. The description adds no confusion, so the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all open tabs' uses a specific verb and resource, clearly indicating a read-only operation that lists tabs. This distinguishes it from siblings like browser_new_tab, browser_close_tab, and browser_switch_tab, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as browser_snapshot or browser_switch_tab. The description simply states what it does without contextual use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the primary effect (switching tabs) but does not disclose any behavioral details such as error behavior, impact on the current page, or whether it works across windows. The description is minimally transparent but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded and immediately states the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is adequate but not complete. It lacks context about how to obtain tab IDs or what happens on invalid IDs. However, the schema and sibling tools provide some implicit context, so the description is minimally viable.
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 provides full coverage for the single parameter (tabId with description 'Tab ID to activate'). The description adds no additional meaning beyond restating that the tool switches to a tab by ID. High schema coverage yields a baseline of 3, and the description does not exceed 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 'Switch to a tab by ID' uses a specific verb (switch) and resource (tab) with a clear scope (by ID). It clearly distinguishes from sibling tools like browser_new_tab, browser_close_tab, and browser_list_tabs, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that tab IDs are typically obtained from browser_list_tabs, nor any prerequisites or conditions for switching. The context is entirely omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states a read operation without mentioning return format, whether URL is required (schema shows 0 required params), domain/path matching behavior, or potential side effects. Minimal context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core function. No filler or redundant information; it is appropriately sized for a tool with one parameter.
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, the description is nearly complete. It falls slightly short because it does not indicate the optionality of 'url' (schema shows 0 required properties) or the absence of a return value specification, but overall it provides enough context for an agent to use the tool effectively in most scenarios.
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 'url' is already fully described in the schema as 'URL to get cookies for', and the description adds no additional semantic detail. Per the rubric, when schema coverage is 100% and the description does not enhance it, the 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 'Read cookies for a URL' uses a specific verb ('Read') and resource ('cookies') with a clear scope ('for a URL'). It unambiguously distinguishes this from sibling tools like browser_set_cookies or browser_get_storage, which involve different operations. This is a textbook example of clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need cookies for a given URL. However, it does not explicitly state when to choose this over browser_get_storage or browser_set_cookies, nor does it provide any prerequisites or context (e.g., whether a browser session must be active). The usage context is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Extract main article content (Reader Mode)' without explaining what the output looks like, whether it strips formatting, or what happens when no article is found. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase that is front-loaded with the core action. Every word serves a purpose, and there is no fluff.
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?
With no output schema and no annotations, the description should explain return values and failure modes. It does not; it only gives a very basic statement of intent. This is insufficient for an agent to fully understand what will happen when the tool is invoked.
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 vacuously complete (100% coverage). The description does not need to add parameter details, and the baseline for zero 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's function with a specific verb and resource: it extracts the main article content. 'Reader Mode' adds useful context and distinguishes it from other browser tools that navigate, click, or extract tables/metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the main article content is needed, but it does not explicitly state when not to use it or mention alternatives like browser_extract_table or browser_extract_meta. The usage context is clear enough but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the core action without mentioning state-changing effects, error conditions (e.g., no previous page), or implications like page unload or form data loss. This is a navigation action that modifies browser state, so more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or repetition. It gets straight to the point, which is ideal for such a simple tool. Front-loaded with the verb 'Go back', it is highly efficient.
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 simplicity (no parameters, no output schema, no annotations), the one-sentence description is mostly sufficient. It clearly explains the action. However, it omits edge-case behavior (e.g., failure when at the first page) and does not mention that this is a state-changing navigation operation. Still, for this simple tool, the description is largely 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?
The tool has zero parameters, and the schema is empty, so schema coverage is 100%. Per the rubric, a baseline of 4 applies for zero-parameter tools. The description correctly avoids adding nonexistent parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Go back to the previous page' uses a specific verb ('go back') and resource ('previous page') that clearly identifies the browser history navigation action. It distinguishes from sibling tools like browser_go_forward (opposite direction) and browser_navigate (URL-specific), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when the agent needs to return to the previous page in browser history. However, it provides no explicit guidance on when not to use this tool or mentions alternatives (e.g., browser_go_forward or browser_navigate). The context is clear but lacks explicit differentiation criteria.
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 only states the basic action. It does not disclose what happens when there is no forward history (e.g., error, no-op), whether it waits for page load, or other behavioral traits. This leaves the agent potentially unaware of edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that fully expresses the tool's purpose. No filler words or redundant information. It is front-loaded and easy to parse.
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 simplicity of the tool (no parameters, no output schema), the description is largely complete for a basic navigation action. However, it would be more complete if it mentioned behavior when no forward history exists, but this is a minor gap for such a simple 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 trivially 100% covered. The description does not need to explain parameters. With 0 params, the baseline is 4, and there is no additional requirement for the description to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Go forward to the next page' clearly states the action (go forward) and the target (next page in browser history). It distinguishes itself from siblings like browser_go_back and browser_navigate by specifying a distinct navigation direction.
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 usage is implied by the name and description: it moves forward in browsing history. However, there is no explicit guidance on when to use it versus alternatives, nor any mention of prerequisites (e.g., must have gone back first) or 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It simply states the action without detailing side effects like losing page state, waiting for load, or how the optional 'hard' parameter affects behavior. This is a significant gap for a navigation/mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It's front-loaded and contains no filler, following best practices for minimal relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter fully documented in the schema, the description adequately covers the core function. However, given the lack of annotations and output schema, a brief mention of behavioral context (e.g., page state loss) would make it more complete. Still, the tool's simplicity raises the acceptable bar.
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 documents the 'hard' boolean parameter with description 'Bypass cache', covering 100% of parameters. The description itself adds no parameter information beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reload the current page' uses a specific verb and resource, clearly distinguishing it from sibling navigation tools like browser_navigate, browser_go_back, and browser_go_forward. The action is unambiguous and unique among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage context: use it when you want to reload the current page. It doesn't explicitly mention alternatives or exclusions, but for a simple reload action, the context is sufficiently clear and there are no competing tools that perform the same function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses one useful behavioral trait (select-all before replacing) but does not elaborate on other aspects like focusing the element, error handling, or interaction with hidden elements. The provided tip adds some value but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and a useful tip. There is no wasted word, and the structure is clear and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and all parameters are documented in the schema, so the description need not restate them. However, without annotations or an output schema, it could provide more context about prerequisites (e.g., need for snapshot) and behavior (e.g., element visibility). It is adequate but lean.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all four parameters, so the baseline is 3. The description itself does not add new meaning beyond the schema; the Control+a tip relates to usage rather than any specific 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 ('Type text into an element') with a specific verb and resource, and distinguishes this tool from siblings like browser_click, browser_press_key, and browser_hover. The use case of inputting text is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (typing into an element) and includes a practical guideline for replacing text via Control+a. It doesn't explicitly name alternatives or state when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral disclosure. It discloses that the tool returns refs like 'e42', which is key behavior, but it does not mention whether the snapshot represents the whole page or a specific element, nor any limitations. Since it is a capture operation, the read-only nature is implied but not explicit, so a moderate score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and immediately followed by the key output detail and usage guidance. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool without an output schema, the description covers the essential purpose (capture snapshot) and the practical application (refs for interactions). It could elaborate on what the accessibility snapshot contains, but the current text is sufficient for an agent to use the tool correctly in most flows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is effectively 100% (empty schema). The description does not need to add parameter details. The baseline for zero parameters is 4, and the description adds no conflicting information.
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 captures an accessibility snapshot and returns refs for use in interaction calls. This specific verb-resource pairing distinguishes it from sibling tools like browser_click or browser_get_elements, which do not produce reusable refs.
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 when to use the tool: before click/type/hover calls, to obtain refs. It provides clear context for usage, though it does not explicitly mention alternatives or when not to use it. This aligns with a 'clear context, no exclusions' level.
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/IlGabbia998/browsermcp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server