Browser-MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is some overlap that could cause confusion. For example, 'click_element' and 'click_element_by_xpath' serve similar functions with different targeting methods, and 'get_element_info' and 'get_page_state' both retrieve element details, potentially leading to misselection. However, descriptions generally clarify differences, preventing major ambiguity.
Naming Consistency4/5
Tool names follow a consistent snake_case pattern throughout, with clear verb_noun structures like 'create_chrome_instance' and 'navigate_to'. Minor deviations exist, such as 'browser_tips' being more descriptive than action-oriented, but overall naming is predictable and readable across the set.
Tool Count2/5
With 35 tools, the count is excessive for a browser automation server, making it feel heavy and potentially overwhelming. While the domain is broad, many tools could be consolidated or omitted without losing functionality, indicating poor scoping and an over-engineered surface that may hinder agent usability.
Completeness5/5
The tool set provides comprehensive coverage for browser automation, including instance management, navigation, interaction, content extraction, and utilities like downloads and screenshots. It supports full CRUD-like operations for browser sessions and tabs, with no obvious gaps that would cause agent failures in typical web automation tasks.
Average 3/5 across 35 of 35 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't indicate whether this is a read-only or destructive operation, what happens to page state, whether authentication is preserved, or what the expected outcome looks like. For a browser interaction tool with zero annotation coverage, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at just three words. It's front-loaded with the core action and target, with zero wasted words. While it's severely under-specified, this isn't a conciseness problem - it's a completeness problem. The description is appropriately sized for what it attempts to convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a browser interaction tool with no annotations, 0% schema description coverage, and multiple sibling tools that could be confused with it, the description is completely inadequate. While an output schema exists (which might help with return values), the description fails to provide the minimal context needed for an agent to understand when and how to use this tool versus alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, but with only 1 parameter and 0% schema description coverage, the baseline would be 3. The schema shows a required 'session_id' parameter, but the description provides no context about what this represents or why it's needed. The description neither compensates for the lack of schema documentation nor adds value beyond what's already in the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Refresh the current page' is a tautology that essentially restates the tool name 'refresh_page'. While it clearly indicates the action (refresh) and target (current page), it doesn't provide any additional specificity or differentiation from potential alternatives. It's better than being completely misleading but fails to add meaningful context beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With sibling tools like 'navigate_back', 'navigate_forward', 'navigate_to', and 'get_page_state', there's clear potential for confusion about when a page refresh is appropriate versus navigation or state checking. The description offers no context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'with confirmation', hinting at a safety or feedback mechanism, but doesn't elaborate on what confirmation entails (e.g., success/failure response, delays, or side effects). It fails to address critical behaviors like error handling, performance implications, or interaction with browser state, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'Click an interactive element by index with confirmation'. It is front-loaded and appropriately sized for the tool's complexity, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interactive browser operation), lack of annotations, and low schema coverage, the description is incomplete. It doesn't cover parameter meanings, behavioral details, or usage context. While an output schema exists (which might explain return values), the description fails to provide sufficient guidance for safe and effective tool invocation in a browser automation setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters 'session_id' and 'index' have no descriptions in the schema. The tool description adds no meaning beyond the schema—it doesn't explain what 'session_id' refers to (e.g., browser instance) or how 'index' is defined (e.g., zero-based, element order). With 2 undocumented parameters and no compensation in the description, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Click an interactive element by index with confirmation' states the action (click) and target (interactive element) but is vague about what 'by index' means in practice and doesn't distinguish it from sibling 'click_element_by_xpath'. It provides a basic purpose but lacks specificity about the indexing system or what constitutes an 'interactive element'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'click_element_by_xpath' is provided. The description implies usage for clicking elements via index, but it doesn't specify prerequisites (e.g., needing an active browser session) or exclusions, leaving the agent to infer context from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions setting configuration but doesn't explain whether this requires specific permissions, if changes are immediate or require restart, what happens to existing configuration, or any side effects. The example about viewport is helpful but insufficient for a tool with 7 parameters including security-related options like 'disable_web_security'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but inefficiently structured. The second sentence is redundant with the tool name and could be more informative. While concise, it lacks proper front-loading of the most important information about what this tool actually configures.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (including security-sensitive ones), no annotations, and 0% schema description coverage, the description is inadequate. It doesn't explain the scope of configuration, relationship to sibling tools like 'get_browser_config', or provide enough context for safe usage. The existence of an output schema helps but doesn't compensate for the missing behavioral and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'viewport_width' and 'viewport_height' parameters, ignoring the other 5 parameters including critical ones like 'session_id' (required), 'headless', 'no_sandbox', 'user_agent', and 'disable_web_security'. The description adds minimal value beyond what's in the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Set advanced browser configuration for a specific instance', which provides a clear verb ('Set') and resource ('browser configuration'). However, it doesn't distinguish this from sibling tools like 'get_browser_config' or explain what makes it 'advanced' versus basic configuration options available elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'If you want to change the viewport, you can use the set_browser_config tool to change the viewport_width and viewport_height.' This gives one specific use case but doesn't explain when to use this versus other configuration methods, what other parameters are for, or any prerequisites. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions uploading a file but fails to describe what happens (e.g., whether it triggers form submission, error handling, or file size limits). This leaves gaps in understanding the tool's behavior beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. However, it's under-specified rather than concise, as it lacks necessary details for a tool with three parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It doesn't cover parameter meanings, behavioral traits, or usage context, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'session_id', 'index', or 'file_path' mean in context (e.g., browser session identifier, element index, local file path). This leaves all three parameters undocumented beyond their titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Upload file to file input element' states a clear verb ('upload') and target ('file input element'), but it's vague about the context (browser automation) and doesn't distinguish from sibling tools like 'download_file' or 'set_element_value'. It specifies what it does but lacks precision about the browser session scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'set_element_value' or 'input_text', nor does it mention prerequisites such as needing an active browser session or a file input element. The description implies usage but offers no explicit 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 states the action ('Get cookies') but doesn't describe what the tool returns (e.g., cookie data format), whether it requires authentication, potential rate limits, or side effects. This leaves significant gaps for a tool that interacts with browser state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Get cookies from the browser', which is front-loaded and wastes no words. Every part earns its place by stating the core action, though it could benefit from more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, browser interaction) and the presence of an output schema (which handles return values), the description is minimally complete but lacks context. It doesn't cover behavioral aspects or parameter meanings, making it just adequate but with clear gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no meaning beyond the schema, failing to explain what 'session_id' and 'domain' represent or how they affect cookie retrieval. With 2 parameters and no param info in the description, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get cookies from the browser' states a clear verb ('Get') and resource ('cookies'), but it's vague about scope and doesn't distinguish from siblings like 'set_cookie' or 'get_browser_config'. It lacks specificity about what kind of cookies or what browser 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites like needing an active browser session, nor does it contrast with sibling tools like 'set_cookie' or 'get_browser_status', leaving usage context implied but not explicit.
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 burden but only states the basic action. It doesn't disclose behavioral traits such as whether scrolling is incremental or continuous, if it requires a loaded page, potential side effects (e.g., triggering lazy-loaded content), or error conditions. This leaves significant gaps for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, front-loaded sentence that directly states the tool's function. There is no wasted verbiage, making it efficient for quick comprehension, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely covers return values), the description's minimalism is somewhat mitigated. However, for a tool with 2 parameters (0% schema coverage) and no annotations, the description is incomplete—it lacks details on usage context, parameter meanings, and behavioral nuances, making it only minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'session_id' refers to (e.g., browser instance) or clarify 'direction' (e.g., 'up' vs 'down' as strings, default behavior). This fails to address the undocumented parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scroll page up or down' clearly states the action (scroll) and resource (page), but it's vague about scope and lacks differentiation from siblings like 'navigate_back' or 'navigate_forward'. It doesn't specify if this scrolls the entire page or a specific element, which could be important given sibling tools like 'click_element'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires an active browser session), exclusions, or how it differs from other navigation tools in the sibling list, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool provides guidance/tips (a read-only informational function), but doesn't specify behavioral traits like whether it returns structured data, if it's interactive, or if it has any side effects. The description is neutral but lacks depth about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, reasonably concise sentence that gets straight to the point. It could be slightly more front-loaded with a clearer action verb, but it efficiently communicates the core idea without unnecessary words or structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, annotations, but has an output schema, the description is minimally adequate. It explains what the tool provides (tips/guidance) but doesn't detail the format or content of the output, relying on the output schema for that. For a guidance tool among many action-oriented siblings, more context about when and how to use it would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters since none exist, and it appropriately focuses on the tool's purpose rather than parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides 'best practices and practical tips' for browser MCP tools, which gives a general purpose but is vague about what the tool actually does. It doesn't specify a clear verb+resource combination (like 'display tips' or 'retrieve guidance'), and doesn't distinguish itself from sibling tools that perform concrete browser actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'LLM-oriented best practices' and 'robust, step-by-step use', implying it should be used for guidance when working with browser tools, but provides no explicit when-to-use rules, no exclusions, and no alternatives. It doesn't specify whether to use this before, during, or after browser operations.
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 burden for behavioral disclosure. It mentions 'with confirmation' which hints at some interactive or safety behavior, but doesn't clarify what this means (e.g., user prompt, automatic check, error handling). It fails to address critical aspects like error conditions (e.g., invalid XPath, element not found), performance implications, or browser session requirements beyond the session_id parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose. While it could be more informative, it wastes no words and is appropriately sized for a basic action tool. The structure is front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (browser interaction with XPath), no annotations, and an output schema (which handles return values), the description is minimally adequate but incomplete. It covers the basic action but lacks crucial context about behavior, parameters, and differentiation from siblings, leaving gaps that could hinder effective use despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'session_id' represents (browser instance, user session) or provide guidance on XPath syntax/format. The mention of 'confirmation' might relate to parameters but isn't linked to any specific input, leaving parameters essentially undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Click') and target ('an interactive element by XPath'), specifying the method of element identification. However, it doesn't explicitly differentiate from the sibling 'click_element' tool, which likely uses a different selector method, leaving some ambiguity about when to choose this specific XPath-based version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'click_element' or other interaction tools. It mentions 'with confirmation' but doesn't explain what this confirmation entails or when it's required, offering minimal 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 provided, the description carries the full burden of behavioral disclosure. It mentions 'Get' which implies a read operation, but fails to specify if this requires special permissions, what the output includes (though an output schema exists), or any side effects like performance impacts. This is inadequate for a tool that likely interacts with browser instances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values) and only one parameter, the description is somewhat complete but lacks critical context. It doesn't explain what 'advanced browser configuration' entails or how it differs from other get-* tools, leaving gaps in understanding the tool's full scope and use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only vaguely references 'a specific instance' without explaining the 'session_id' parameter's meaning or format. Since there is only one parameter, the baseline is 4, but the description adds minimal value beyond the schema, resulting in a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get advanced browser configuration for a specific instance' clearly indicates it retrieves configuration data, with 'advanced' and 'specific instance' providing some specificity. However, it doesn't distinguish this from sibling tools like 'get_browser_status' or 'get_instance_info', leaving the exact scope and differentiation vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_browser_status' or 'get_instance_info'. The description implies it's for configuration retrieval but offers no context on prerequisites, timing, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return values (options, id, and name) but lacks critical details: whether this is a read-only operation, if it requires specific permissions, potential errors (e.g., invalid session or index), or performance implications. For a tool interacting with browser elements, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., separating purpose from return values). Overall, it's appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, browser interaction), no annotations, and an output schema (which handles return values), the description is minimally adequate. It covers the purpose and output but misses parameter semantics and behavioral context. With the output schema reducing the need to detail returns, it's complete enough for basic use but leaves gaps for robust agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters at all, failing to explain what 'session_id' and 'index' represent or how they relate to dropdown elements. This leaves both parameters semantically unclear beyond their titles in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'options from a dropdown/select element', specifying what the tool does. It distinguishes from siblings like 'get_element_info' by focusing specifically on dropdown options rather than general element information. However, it doesn't explicitly contrast with other dropdown-related tools (none appear in the sibling list), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active browser session), compare to similar tools like 'get_element_info', or specify scenarios where this tool is preferred. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool can 'get the value of the element', which hints at read-only behavior, but doesn't cover critical aspects like error handling (e.g., if element not found), performance implications, or authentication needs for the session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. However, it could be more structured by separating query methods from value retrieval, and the phrase 'can get the value of the element' feels tacked on rather than integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no annotations, but with an output schema present, the description is moderately complete. It covers the basic purpose and query methods but lacks details on parameter usage, error cases, and behavioral context, which are needed for a tool interacting with DOM elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'index or xpath query', which partially explains two parameters, but doesn't clarify the 'session_id' parameter or provide details on query syntax, default behaviors, or mutual exclusivity between index and xpath.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a DOM element'), specifying it supports index or xpath query. It distinguishes from siblings like 'get_page_state' or 'get_instance_info' by focusing on element-level details, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It mentions supporting index or xpath query but doesn't specify prerequisites (e.g., needing an active browser session) or compare to siblings like 'get_dropdown_options' for specific element types.
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 states the action but doesn't reveal critical traits: whether it requires a specific browser state, if it waits for the field to be interactable, potential side effects (e.g., triggering form validation), or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded and appropriately sized for a simple action, though this conciseness comes at the cost of missing details needed for full understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, mutation operation) and lack of annotations, the description is incomplete. While an output schema exists, the description doesn't address behavioral nuances, parameter meanings, or usage context, making it insufficient for reliable agent operation in a crowded sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It adds no meaning beyond the schema—failing to clarify what 'session_id', 'index', or 'text' represent in context (e.g., index of which element, text encoding). This leaves all three parameters undocumented, significantly hindering correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Input text into a form field' clearly states the action (input) and target (form field), providing a specific verb+resource. However, it doesn't distinguish from sibling tools like 'send_keys' or 'set_element_value', which may have overlapping functionality in a browser automation 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'send_keys' or 'set_element_value'. It lacks context about prerequisites (e.g., needing an active browser session) or exclusions, leaving the agent to 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 provided, the description carries full burden for behavioral disclosure. 'Set a cookie' implies a write operation, but the description doesn't mention permissions needed, whether this affects browser state persistently, potential side effects, or error conditions. It lacks crucial context about what 'in the browser' means operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single clear sentence with no wasted words. It's front-loaded with the essential action and resource. Every word earns its place in communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, 0% schema description coverage, no annotations, and complex browser interaction, the description is inadequate. While an output schema exists, the description doesn't address the tool's behavioral context, parameter meanings, or relationship to sibling browser tools. It leaves too many questions unanswered for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 10 parameters, the description provides no parameter information beyond what's implied by the tool name. It doesn't explain what 'session_id' refers to, how 'domain' relates to browser context, or the meaning of security parameters like 'http_only' and 'secure'. The description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('a cookie in the browser'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_cookies' or explain how it differs from browser configuration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing an active browser session), when not to use it, or how it relates to sibling tools like 'get_cookies' or 'set_browser_config'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool's behavior (taking screenshots with conditional targeting) and mentions structured results, but lacks details on permissions, rate limits, side effects (e.g., does it save files?), or error handling. The link to Playwright docs adds some context but isn't integrated into the description itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but could be more front-loaded; the first sentence is clear, but the second sentence mixes target explanation with syntax examples and a link, making it slightly cluttered. It avoids unnecessary fluff, but the structure could be improved for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers the core purpose and target parameter but misses details on other parameters, behavioral traits, and return values. For a tool with this complexity, more comprehensive information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the 'target' parameter and its selector syntax, ignoring the other 6 parameters (session_id, width, height, full_page, quality, format). This leaves most parameters undocumented, failing to add sufficient meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool takes screenshots with structured results, specifying it can target elements or capture full page/viewport. It distinguishes from siblings like 'download_image' or 'generate_pdf' by focusing on screenshot capture rather than file downloads or PDF generation. However, it doesn't explicitly contrast with all siblings (e.g., 'get_element_info' might also involve elements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing target behavior (element vs. page vs. viewport) and provides a link for selector syntax, but lacks explicit guidance on when to use this versus alternatives like 'download_image' or 'generate_pdf'. It mentions the conditional logic ('if target is not None...') which gives some context, but no clear 'when-not' scenarios or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions checking health and providing recovery suggestions, but doesn't specify what constitutes 'health status' (e.g., connectivity, errors, performance), what recovery suggestions entail, or whether this is a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding its behavior and effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose without unnecessary words. It's front-loaded with the core action and outcome, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values), the description's main job is to clarify purpose and usage. It does a decent job on purpose but lacks usage guidelines and parameter details. For a health-check tool with no annotations, it's minimally adequate but leaves gaps in behavioral context and parameter understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no information about parameters. It doesn't explain what 'session_id' represents, how to obtain it, or its format. With low schema coverage, the description fails to compensate, leaving the parameter's meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check the health status of a browser session and provide recovery suggestions'. It specifies the verb ('check'), resource ('browser session'), and outcome ('provide recovery suggestions'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_browser_status' or 'get_page_state', which might also provide status information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or how it differs from sibling tools such as 'get_browser_status' or 'get_page_state', which could overlap in functionality. Without this context, users 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behaviors: downloads to temp directory, returns file path, and opens new tab for cross-origin images. However, it lacks information about error handling, file format support, permissions needed, or rate limits. The description doesn't contradict annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two main clauses. However, the second clause about opening new tabs could be more clearly integrated. The description is front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what the return value looks like beyond 'file path', doesn't cover all parameters, and lacks error scenarios or limitations. The cross-origin behavior is helpful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'URL' which relates to 'image_url' parameter, but doesn't explain the purpose of 'session_id', 'output_filename', or 'timeout'. The description adds minimal value beyond what parameter names already suggest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'download' and resource 'image from URL', specifying it saves to temp directory and returns file path. However, it doesn't explicitly differentiate from sibling 'download_file' which appears to be a more general file download tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'it will open a new tab if the image is not from the same origin as the current page' which provides some behavioral context, but offers no explicit guidance on when to use this tool versus alternatives like 'download_file' or 'take_screenshot'. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Search Bing' implies a read-only operation, it doesn't specify authentication needs, rate limits, or what 'progress tracking' entails (e.g., real-time updates, callback mechanisms). The description is too vague about behavioral traits beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core action ('Search Bing') and adds a useful modifier ('with progress tracking'). Every part of the sentence contributes meaning, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should document return values), the description doesn't need to explain outputs. However, with 2 parameters at 0% schema coverage and no annotations, the description is incomplete—it fails to clarify parameter purposes or behavioral details adequately. The presence of an output schema raises the baseline, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'query' implicitly but doesn't explain the 'session_id' parameter at all. The phrase 'with progress tracking' might relate to 'session_id', but this connection isn't made explicit, leaving both parameters poorly explained beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'Bing', specifying the action and target. It adds 'with progress tracking' which provides additional context about the tool's functionality. However, it doesn't explicitly distinguish this from other search-related tools that might exist in the sibling list, though none are directly search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, constraints, or comparison with other tools in the sibling list (which are primarily browser automation tools, not search engines). The phrase 'with progress tracking' hints at a specific use case but doesn't clarify when this is preferred over a simpler search.
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 lacks details on permissions needed, error handling (e.g., invalid session_id), rate limits, or what happens if the browser isn't ready. This leaves significant gaps for an agent to use it safely and effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It's front-loaded with the core action, though its brevity contributes to gaps in other dimensions like guidelines and transparency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and low parameter clarity, the description is minimally adequate. It states the basic purpose but lacks critical details for safe usage in a browser automation context, making it incomplete for effective agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning beyond the schema. It doesn't explain what 'session_id' refers to (e.g., a browser instance) or what format 'keys' should be in (e.g., key names like 'Enter' or raw text). This fails to compensate for the lack of schema documentation, making parameters unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('send') and resource ('keyboard keys') with the target ('to the browser'), making the purpose understandable. However, it doesn't differentiate from siblings like 'input_text' or 'set_element_value', which also involve browser input actions, leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'input_text' and 'set_element_value' that handle text input, there's no indication of whether 'send_keys' is for special keys (e.g., Enter, Tab) or general typing, leading to potential misuse without further 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?
With no annotations, the description carries full burden but only states the action and frame support. It lacks details on permissions, side effects (e.g., if it triggers events), error handling, or response format, leaving behavioral traits unclear for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and includes an additional useful detail ('supports frames') without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It states the purpose and a key feature (frame support) but lacks parameter explanations and behavioral context, relying on the output schema for return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'session_id', 'index', or 'value' mean, their formats, or how they interact, failing to provide meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'value of an input or select element', making the purpose understandable. It distinguishes from siblings like 'input_text' or 'send_keys' by specifying direct value setting for form elements, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'input_text' or 'send_keys' is provided. The mention of 'supports frames' hints at a specific context but doesn't define when to prefer this tool or exclude others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions switching and returning tab info, but doesn't cover critical aspects like whether this requires an existing browser session, if it changes the active tab in a visible way, potential errors (e.g., invalid IDs), or side effects. This leaves significant gaps for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and outcome with zero wasted words. It's appropriately sized for a straightforward tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should document the 'tab info object'), the description doesn't need to detail return values. However, with 2 required parameters, 0% schema coverage, and no annotations, the description is too minimal—it doesn't explain parameter semantics or behavioral context, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description doesn't explain what 'session_id' or 'page_id' mean, their formats, or how to obtain them (e.g., from 'get_tabs_info'). This fails to compensate for the lack of schema documentation, leaving parameters largely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('switch to a specific browser tab') and the outcome ('return the tab info object'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'get_tabs_info' (which likely lists tabs without switching) or 'close_tab' (which closes rather than switches), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used after 'get_tabs_info' to identify a target tab, or how it relates to navigation tools like 'navigate_to'. Without such context, 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 provided, the description carries the full burden of behavioral disclosure but provides minimal information. It states what the tool does but doesn't describe important behavioral aspects: whether it requires specific permissions, how it handles errors, what the output looks like (though there's an output schema), whether it's resource-intensive, or any rate limits. The description is functional but lacks operational context needed for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 8 words, front-loading the core functionality with zero wasted language. Every word earns its place by specifying both the action and the three input sources. The structure is optimal for quick comprehension while conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is insufficiently complete. While the output schema may cover return values, the description doesn't address critical aspects: how to choose between the three input sources, what 'current page' means in relation to session_id, default behaviors, error conditions, or performance characteristics. For a tool with this many configuration options, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 11 parameters, the description fails to compensate for this significant gap. It mentions three input sources (current page, URL, HTML content) which map to some parameters, but doesn't explain the relationship between session_id and 'current page', doesn't mention the numerous formatting parameters (margins, paper size, background printing), and provides no guidance on parameter interactions or requirements beyond what's obvious from the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Generate PDF from current page, URL, or HTML content', specifying both the action (generate PDF) and the sources (current page, URL, HTML content). It distinguishes itself from sibling tools like 'take_screenshot' or 'download_file' by focusing specifically on PDF generation from web content. However, it doesn't explicitly differentiate from potential PDF-related siblings that might not exist in this list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by listing three input sources (current page, URL, or HTML content), suggesting when this tool is appropriate versus alternatives. However, it doesn't provide explicit guidance on when to choose between these sources or when to use this versus other output tools like 'take_screenshot' or 'download_file'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that closing 'will delete the instance and all related data', which indicates a destructive operation, but fails to detail critical aspects like whether this action is irreversible, requires specific permissions, or has side effects on other browser operations. This leaves significant gaps for a tool with clear destructive implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and consequence without unnecessary words. Every part earns its place by stating the tool's purpose and behavioral impact directly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive operation with no annotations and an output schema (which reduces the need to describe return values), the description is minimally adequate. It covers the basic action and data deletion but lacks details on error conditions, dependencies, or integration with sibling tools, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds meaning by specifying that 'session_id' identifies the 'specific Chrome browser instance' to close, which clarifies the parameter's role beyond the schema's basic type. However, it doesn't explain the format or source of 'session_id', such as whether it comes from 'create_chrome_instance' or other tools, leaving practical usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('close') and target ('specific Chrome browser instance by session_id'), distinguishing it from the sibling 'close_all_instances'. However, it doesn't specify what 'close' entails beyond deletion, leaving some ambiguity about whether it terminates processes or just cleans up data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'close_all_instances' or 'close_tab', nor does it mention prerequisites such as needing an existing instance. It implies usage by specifying the 'session_id' parameter but lacks explicit 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?
No annotations are provided, so the description carries the full burden. It discloses that a session_id (UUID) is returned, which is useful behavioral context. However, it lacks critical details: whether this consumes significant resources, if there are rate limits on instance creation, what happens if too many instances are open, or if it requires specific permissions. For a tool that likely launches a browser process, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create a new Chrome browser instance') and key outcome ('return session_id'). There is zero waste—every word contributes essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (creating a browser instance), no annotations, and an output schema (which likely covers the session_id return), the description is minimally complete. It states the purpose and return value, but lacks context on resource usage, error conditions, or integration with sibling tools. For a tool with potential side effects (launching processes), more behavioral detail would be helpful, but the output schema reduces the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no parameter information beyond what's inferred from the schema (e.g., 'headless' might control headless mode). It doesn't explain what 'headless' means, why viewport dimensions matter, or default behaviors. With 3 parameters and 0% coverage, the description fails to compensate adequately, but it's not misleading, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new Chrome browser instance') and the resource ('Chrome browser instance'), with the specific outcome of returning a session_id. It distinguishes from siblings like 'get_instance_info' or 'close_instance' by focusing on creation rather than querying or termination. However, it doesn't explicitly differentiate from all siblings (e.g., 'set_browser_config' might also involve browser setup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether an existing instance must be closed first), when not to use it (e.g., for reusing instances), or refer to sibling tools like 'close_all_instances' for cleanup. Usage is implied only by the action of creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions extraction from frames/iframes, which adds some context about scope, but fails to describe critical behaviors such as what 'extract' entails (e.g., text, HTML, structured data), performance implications, error handling, or authentication needs. This is inadequate for a tool with mutation-like implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes a clarifying detail about frames/iframes, making it appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, and an output schema present, the description is moderately complete. It covers the basic action and scope but lacks details on parameters, behavioral traits, and usage context. The output schema reduces the need to explain return values, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies 'query' is used to target content but doesn't explain its format or semantics (e.g., CSS selector, XPath, keyword). 'session_id' is not mentioned at all. The description adds minimal value beyond the schema, failing to fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('extract content') and the target ('from page based on query'), with the additional detail 'including all frames/iframes' that specifies scope. However, it doesn't explicitly differentiate from sibling tools like 'get_element_info' or 'get_page_state', which might also retrieve content, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active session), exclusions, or compare to siblings like 'get_element_info' for more targeted extraction. This leaves the agent with minimal 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 states it 'gets' information, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'detailed information' entails. This leaves significant gaps for a tool with an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for its content, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values, which helps completeness. However, with no annotations, low schema coverage, and multiple sibling tools, the description is minimal and lacks context on usage, parameters, or behavioral traits, making it only adequate for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which has 0% description coverage and only one parameter 'session_id'. Since schema coverage is low, the description should compensate but doesn't explain what 'session_id' represents or how to obtain it. The baseline is adjusted due to the single parameter, but the lack of semantic detail limits utility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific browser instance', making the purpose understandable. However, it doesn't differentiate from siblings like 'get_browser_status' or 'get_page_state', which might provide overlapping or related information about browser instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_browser_status' or 'get_tabs_info'. The description implies usage for a specific instance but doesn't specify prerequisites, exclusions, or contextual triggers.
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 what the tool does but lacks critical details: it doesn't specify what information is returned (e.g., URLs, titles, tab states), whether it requires specific permissions, or if there are rate limits. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly, which is ideal for conciseness in tool definitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no annotations) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context about what 'information' includes and when to use it over siblings, leaving gaps in completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what the input schema provides. With 0% schema description coverage and 1 parameter ('session_id'), the schema alone documents the parameter's existence and type. The description doesn't compensate by explaining what 'session_id' means or how to obtain it, so it meets the baseline for minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get information') and resource ('all open browser tabs'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_instance_info' or 'get_page_state' that might provide overlapping browser information, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to browser operations (e.g., 'get_instance_info', 'get_page_state'), there's no indication of whether this tool is for tab metadata, content, or other details, leaving usage context unclear.
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 burden for behavioral disclosure. It states the action but doesn't describe what happens if no forward history exists, whether it waits for page load, or any error conditions. This leaves significant behavioral gaps for a navigation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single, clear sentence that communicates the core functionality without any wasted words. It's front-loaded with the essential action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool with an output schema (which handles return values), the description is minimally complete. However, for a navigation operation with no annotations, it should ideally mention behavioral aspects like what happens when forward navigation isn't available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what the schema provides (a single 'session_id' parameter with 0% schema description coverage). However, since there's only one parameter and its purpose is reasonably inferable from context, this meets the baseline for minimal parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('navigate forward') and resource ('browser history'), making the purpose immediately understandable. It distinguishes from sibling 'navigate_back' by specifying direction, though it doesn't explicitly contrast with other navigation tools like 'navigate_to'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'navigate_back' or 'navigate_to'. The description doesn't mention prerequisites (e.g., needing forward history available) or contextual constraints, leaving usage entirely 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 provided, the description carries full burden. It discloses implementation details (fetch+blob+a.download, fallback to goto+expect_download) and mentions 'maximum compatibility', which adds useful behavioral context. However, it doesn't cover important aspects like error handling, file size limits, or security considerations for a download operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each serve a purpose: the first states the core functionality, the second adds implementation details. It's front-loaded with the main purpose, though the technical implementation details might be more appropriate in a separate section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which presumably documents return values), the description doesn't need to explain outputs. However, for a file download tool with 4 parameters and no annotations, the description should provide more guidance about parameter usage, error conditions, and security implications to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 4 parameters, the description provides no information about any parameters. It doesn't explain what 'session_id' represents, how 'url' should be formatted, what 'output_filename' does, or what 'timeout' controls. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads files from URLs to a temp directory, specifying the verb 'download' and resource 'file from URL'. It distinguishes from sibling 'download_image' by handling 'any file' rather than just images, though it doesn't explicitly contrast with other download-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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for downloading files with maximum compatibility via fallback mechanisms, but doesn't explicitly state when to use this tool versus alternatives like 'download_image' or 'upload_file'. It provides some context about compatibility but lacks clear when/when-not guidance.
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 states the action but doesn't explain what happens if there's no history to go back to, whether it's idempotent, or any error conditions. This leaves gaps in understanding the tool's behavior beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the essential action without any wasted words. It's appropriately sized for a simple navigation tool and efficiently communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple navigation action) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks details on behavioral aspects like error handling or prerequisites, which could be important for robust usage in a browser automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 0% description coverage, but the tool likely operates without requiring detailed parameter semantics for this action. The description doesn't add parameter details, but for a tool with zero parameters expected, this is acceptable, as the schema already defines the required 'session_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Go back') and the resource ('current tab's history'), making the purpose immediately understandable. It doesn't distinguish from its sibling 'navigate_forward', but it's specific enough to avoid being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'navigate_forward' or 'navigate_to', nor does it mention prerequisites such as requiring browser history to be available. It implies usage in a browser context but lacks explicit 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?
No annotations are provided, so the description carries the full burden. It mentions 'with progress,' hinting at some feedback mechanism, but doesn't detail what 'progress' entails (e.g., visual indicators, logs). It also omits behavioral aspects like whether the wait is blocking, if it can be interrupted, or error handling for invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: 'Wait for specified number of seconds with progress.' It uses minimal words to convey the core function without any redundant information, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema, the description is somewhat complete but has gaps. It covers the basic action but lacks details on usage context and behavioral transparency. The output schema might handle return values, but the description doesn't explain what 'progress' means or operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema. The schema only defines 'seconds' as an integer with a default of 3, with 0% coverage in descriptions. The description clarifies that this parameter specifies the 'number of seconds' to wait, which is crucial for understanding its purpose, compensating for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Wait for specified number of seconds with progress.' It includes a specific verb ('Wait') and resource ('seconds'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools, which are all browser automation related, while this is a timing utility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like pausing between browser actions, handling loading times, or coordinating with other tools. Without such context, users must infer usage from the tool's name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about what happens when closing the last tab (navigates to 'about:blank'), which is a behavioral trait not inferable from the schema. However, it doesn't cover other aspects like error handling, permissions needed, or the effect on browser state beyond this specific case, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that is front-loaded with the core action ('Close a specific tab') and adds a conditional behavioral note. Every word earns its place, and there is no redundancy or unnecessary elaboration, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely covers return values), the description doesn't need to explain outputs. However, as a mutation tool with no annotations and 0% schema coverage, the description is incomplete: it lacks parameter details, error conditions, and broader behavioral context. The added note about the last tab scenario is helpful but insufficient for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description provides no information about the parameters (session_id and page_id). The description does not compensate for this lack by explaining what these parameters mean, how to obtain them, or their roles in identifying the tab to close, resulting in inadequate parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close a specific tab') and the resource ('tab'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'close_all_instances' or 'close_instance' by focusing on individual tabs. However, it doesn't explicitly differentiate from 'switch_tab' in terms of closing vs. switching, which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the condition 'if the tab is the last one, it will goto about:blank', which suggests when this tool might be appropriate (e.g., for closing tabs in a browser session). However, it lacks explicit guidance on when to use this vs. alternatives like 'close_all_instances' or 'close_instance', and no prerequisites or exclusions are stated, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the frames parameter being 'unstable' and potentially incomplete, which goes beyond the basic schema. However, it doesn't describe other behavioral traits like performance characteristics, error conditions, or what 'page state' specifically includes (e.g., DOM structure, JavaScript state).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core purpose, followed by a critical warning. Every word earns its place, with no redundant information. The structure efficiently communicates essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and simple parameters, the description is moderately complete. It covers the purpose and a key behavioral warning but lacks details on parameter semantics (especially session_id) and broader usage context. For a tool with 2 parameters and no annotation coverage, it should do more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It only mentions the frames parameter ('frames mode is unstable'), providing some semantic context for that parameter. However, it doesn't explain the session_id parameter at all, leaving half the parameters undocumented. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current page state and interactive elements' - a specific verb ('Get') and resource ('page state and interactive elements'). It distinguishes itself from siblings like get_element_info (specific element) or get_tabs_info (tab-level info) by focusing on overall page state. However, it doesn't explicitly contrast with all possible alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance with the warning about frames mode being 'unstable and may not extract all details,' which implies when to be cautious with the frames parameter. However, it doesn't explicitly state when to use this tool versus alternatives like get_element_info for specific elements or extract_content for content extraction, nor does it provide clear prerequisites 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 of behavioral disclosure. It adds important context about admin-only access, which is valuable behavioral information not captured elsewhere. However, it doesn't describe what 'browser status' includes beyond 'instances and their status', nor does it mention response format, error conditions, or whether this is a read-only operation (though 'Get' implies reading).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clauses that each add value: the core functionality and the admin restriction. It's front-loaded with the main purpose. While efficient, the phrasing could be slightly more polished ('only admin can use this tool' could be 'Requires admin privileges.').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description provides adequate context. The admin restriction is crucial information, and the purpose is clearly stated. With an output schema handling return values, the description doesn't need to explain response format. For a status-checking tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. Baseline for 0 parameters is 4, and the description doesn't detract from this by incorrectly mentioning parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current browser status, including all instances and their status.' This specifies the verb ('Get') and resource ('browser status'), and distinguishes it from siblings like 'get_instance_info' or 'get_page_state' by focusing on overall browser status rather than specific instances or page states. However, it doesn't explicitly differentiate from 'check_browser_health', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage with 'only admin can use this tool', establishing an important prerequisite. This helps the agent understand when NOT to use it (non-admin contexts). However, it doesn't explicitly mention when to choose this tool over alternatives like 'check_browser_health' or 'get_instance_info', nor does it provide exclusion criteria beyond admin requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states this is a destructive operation ('delete all related data') and specifies the permission requirement ('only admin can use this tool'). However, it doesn't describe what happens to active sessions, whether the operation is reversible, or what the output contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that contains all essential information: the action, the scope, and the permission requirement. Every word earns its place with zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive admin-only tool with no parameters and an output schema, the description covers the critical aspects: what it does, its destructive nature, and permission requirements. The existence of an output schema means return values don't need explanation. However, it could benefit from mentioning irreversible consequences or confirmation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this tool's design.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Close all browser instances and delete all related data'), distinguishing it from the sibling 'close_instance' tool which likely closes a single instance. The verb+resource+scope combination is precise 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context about when to use this tool ('only admin can use this tool'), which helps differentiate it from other browser management tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives for partial cleanup scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the 'new_tab' parameter behavior ('does not auto-switch to new tab'), which isn't obvious from the schema alone. However, it lacks details on permissions needed, error conditions, or what happens if navigation fails, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded in a single sentence, with zero wasted words. Every part ('Navigate to URL in current tab or new tab' and 'does not auto-switch to new tab') adds critical information about the tool's functionality and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and moderate complexity with 3 parameters, the description is reasonably complete. It covers the core action and key behavioral nuance, though it could benefit from more details on error handling or prerequisites for a navigation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the 'new_tab' parameter by explaining its behavioral effect ('does not auto-switch to new tab'), which goes beyond the schema's 0% description coverage. It doesn't detail 'session_id' or 'url' parameters, but with 3 parameters total, this partial compensation earns a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Navigate to URL') and resource (browser tab), distinguishing it from siblings like 'navigate_back' or 'navigate_forward' by specifying navigation to a new URL rather than history navigation. It also differentiates from 'switch_tab' by focusing on URL navigation rather than tab switching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by specifying 'in current tab or new tab' and noting that it 'does not auto-switch to new tab,' which helps understand when to use this tool versus alternatives like 'switch_tab' for tab management. However, it doesn't explicitly state when not to use it or name specific alternative tools for different scenarios.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Euraxluo/browser-mcp'

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