Skip to main content
Glama
OMGEverdo

browser-pool-mcp

by OMGEverdo
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

Server Quality Checklist

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

  • Latest release: v1.0.0

  • Disambiguation4/5

    Most tools have distinct purposes targeting specific browser interactions like clicking, typing, navigating, or taking screenshots. However, 'browser_evaluate' (run JavaScript) and 'browser_snapshot' (page snapshot) could potentially overlap with other tools in functionality, creating minor ambiguity in certain scenarios.

    Naming Consistency5/5

    Tool names follow a highly consistent snake_case pattern with clear 'browser_' or 'pool_' prefixes, making them predictable and readable. The verb_noun structure is maintained throughout, such as 'browser_click', 'browser_navigate', and 'pool_status', ensuring no mixing of conventions.

    Tool Count3/5

    With 20 tools, the count is borderline heavy for a browser automation server, potentially overwhelming for agents. While it covers many interactions, some tools like 'browser_snapshot' and 'browser_screenshot' might be redundant, suggesting the set could be more streamlined without losing core functionality.

    Completeness4/5

    The toolset provides comprehensive coverage for browser automation, including navigation, interaction, debugging, and pool management. Minor gaps exist, such as no explicit tool for handling cookies or local storage, but agents can likely work around these using existing tools like 'browser_evaluate' for JavaScript execution.

  • Average 1.7/5 across 20 of 20 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 0 commits in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.

    If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.

    MCP servers without a LICENSE cannot be installed.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of disclosure but delivers nothing. It fails to describe: whether the click triggers navigation, waits for events, throws errors on missing elements, returns success/failure, or modifies browser state. Complete behavioral opacity.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief (two words), this represents under-specification rather than effective conciseness. The single fragment provides insufficient information density for a 2-parameter browser automation tool with zero schema documentation.

    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?

    Completely inadequate for a browser automation tool with 2 undocumented parameters and no output schema. Lacks: element identification methodology, coordinate/selector formats, interaction with page contexts, error handling, and relationship to browser_snapshot or browser_navigate.

    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?

    Critical failure given 0% schema description coverage. The description mentions 'element' (matching one parameter name) but gives no semantics—no format, selector syntax, or distinction from the 'ref' parameter. The 'ref' parameter remains completely unexplained despite being required.

    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 'Click element' is essentially a tautology of the tool name 'browser_click', merely restating the action in verb-noun form. While it confirms the general action (clicking) and target (an element), it fails to specify browser context, element types, or distinguish from sibling tools like browser_hover or browser_press_key.

    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?

    Provides absolutely no guidance on when to use this tool versus alternatives (e.g., browser_hover for hovering, browser_press_key for keyboard interaction, browser_select_option for dropdowns). No mention of prerequisites like page navigation or element visibility.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are present, yet the description provides zero behavioral context. It does not disclose whether messages are cleared after retrieval, what format data is returned in, pagination behavior, or filtering capabilities.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief (two words), this represents under-specification rather than efficient information density. The extreme brevity provides minimal value and forces the agent to guess intent.

    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 the presence of a parameter and multiple browser-related siblings, the description is inadequate. It explains neither the parameter's role nor the tool's specific value proposition within the browser tool suite.

    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?

    With schema description coverage at 0%, the description must compensate for the undocumented 'level' parameter. It completely fails to do so, leaving the parameter's purpose (log level filtering?) and valid values entirely unspecified.

    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 phrase 'Get console' is extremely vague and tautological (restating the tool name). While it uses a verb ('Get'), it fails to clarify whether it retrieves console messages, the console object, or opens the console UI, and does not distinguish from sibling tools like browser_evaluate.

    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?

    No guidance provided on when to use this tool versus alternatives (e.g., browser_evaluate for executing JS, browser_snapshot for page state), nor any prerequisites or conditions for use.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries full burden but discloses nothing about execution context (page vs worker), return value handling, Promise/async support, side effects, or sandbox constraints despite being a high-risk arbitrary code execution tool.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief (2 words), this is under-specification rather than effective conciseness. The single sentence fails to front-load critical constraints or behavioral warnings that would aid agent decision-making.

    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?

    Completely inadequate for a tool executing arbitrary code: no output schema documentation, no error handling description, no annotation coverage, and no mention of security implications or execution scope.

    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?

    With 0% schema description coverage, the description fails to compensate. It does not clarify whether the 'function' parameter expects a function body, expression, statement list, or function name, nor does it specify expected format or examples.

    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 a verb ('Run') and domain ('JavaScript') but fails to specify the browser execution context or distinguish from sibling automation tools like browser_click. It relies entirely on the tool name 'browser_evaluate' to convey context.

    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?

    No guidance provided on when to use this versus other interaction tools (e.g., browser_click for simple actions) or prerequisites (e.g., needing an active page).

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Zero annotations provided, yet the description discloses no behavioral traits. It does not specify whether the key press targets the currently focused element, what key formats are accepted (e.g., 'Enter', 'Control'), or whether modifiers are supported. No mention of side effects like form submission.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief at two words, this is severe under-specification masquerading as conciseness. The single 'sentence' fails to earn its place by providing actionable information to an LLM agent.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a 1-parameter tool with no output schema or annotations, the description provides only a tautology. It lacks critical context: what key values are valid, whether the action requires a specific browser state, and how it differs from text input operations.

    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 coverage is 0% (no description on the 'key' parameter), and the description fails to compensate. It does not specify valid values (special keys vs. characters), expected format (case sensitivity), or examples of acceptable inputs.

    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 'Press key' is tautological given the tool name 'browser_press_key'. While it restates the action with different words, it fails to specify what kind of key (keyboard vs. UI element), distinguish from sibling 'browser_type', or clarify the 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 Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance provided on when to use this versus 'browser_type' (which likely enters text) or 'browser_click'. No mention of prerequisites like having a focused element or when key presses trigger navigation vs. input.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It does not state whether this supports multi-select (implied by the array 'values' parameter), what happens if the option doesn't exist, whether it triggers change events, or what error conditions might arise.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief at two words, this represents under-specification rather than efficient conciseness. The single sentence fails to earn its place by not adding value beyond the tool name, lacking the structured context needed for 3 undocumented parameters.

    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?

    Completely inadequate for a browser automation tool with three undocumented parameters and no output schema. The description omits the element identification scheme, the browser context, multi-select support, and expected behavior—leaving the agent without sufficient context to invoke the tool correctly.

    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%, requiring the description to compensate, but it mentions no parameters. The description fails to explain the distinction between 'element' and 'ref' identifiers, or that 'values' accepts an array presumably for multi-select capability—critical gaps for a 3-parameter tool.

    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 'Select option' is tautological given the tool name 'browser_select_option'. While it vaguely indicates the action (selecting) and target (options), it fails to specify that this is for dropdown/select elements, distinguish it from sibling tools like browser_click, or clarify the 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 Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance provided on when to use this tool versus alternatives like browser_click or browser_type. Given siblings include multiple interaction methods, the description should specify this is specifically for <select> dropdown elements and when to prefer it over clicking.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, placing full burden on the description. The description discloses no behavioral traits: it doesn't explain side effects of 'close' vs 'new', authentication requirements, rate limits, or what 'select' implies. With no readOnlyHint or destructiveHint, the agent cannot determine safety profile from either source.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief (two words), this constitutes under-specification rather than efficient conciseness. The single 'sentence' adds no value beyond the tool name itself, failing the criterion that every sentence must earn its place.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a tool with 2 parameters, 0% schema coverage, no annotations, no output schema, and 4 distinct enum-driven behaviors, the description is grossly incomplete. It omits critical operational semantics that would enable correct invocation.

    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%, requiring the description to compensate for undocumented parameters. The description fails to explain the 'action' enum values (list/new/close/select) or the purpose of 'index' (which actions require it, is it 0-indexed?).

    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 'Manage tabs' is essentially a tautology that restates the tool name 'browser_tabs'. It uses the generic verb 'manage' without specifying the supported operations (list, new, close, select) or distinguishing from siblings like 'browser_close' (which closes the browser, not tabs).

    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?

    No guidance provided on when to use this versus siblings like browser_close, browser_navigate, or when specific actions are appropriate. No mention of prerequisites or workflow context.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, yet the description discloses zero behavioral traits. It does not explain whether this blocks execution, what happens on timeout, polling frequency, or how the three parameters interact (mutually exclusive? sequential?). Full burden falls on the description, which provides nothing.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief (3 words), this represents under-specification rather than efficient conciseness. The single sentence communicates almost nothing beyond the tool name itself and fails to front-load critical information about the three distinct wait modes.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    With 3 parameters, 0% schema coverage, no annotations, and no output schema, this description is completely inadequate for a browser automation tool. Critical information missing includes timeout behavior, polling mechanisms, and parameter precedence rules.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0%, and the description fails to compensate. The relationships between 'time' (units? behavior?), 'text' (substring matching? exact match?), and 'textGone' (wait until disappears?) are completely undocumented. Agent must guess parameter semantics.

    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 'Wait for condition' is almost tautological given the tool name 'browser_wait_for'. While it indicates the tool involves waiting, it fails to specify what constitutes a 'condition' (element presence, text appearance, time duration) or distinguish this from sibling tools like browser_snapshot that also observe state.

    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?

    Absolutely no guidance provided on when to use this tool versus alternatives, or how to choose between the three parameter options (time, text, textGone). The agent cannot determine if this is for explicit delays, polling for elements, or waiting for page stability.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With zero annotations, the description carries the full burden of behavioral disclosure. It fails to indicate whether this is a safe read-only probe or if it mutates pool state, what the return value contains, or how the 'message' parameter affects the test behavior.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While only three words, this represents under-specification rather than efficient conciseness. No information is front-loaded; the fragment provides minimal actionable context for an LLM to decide invocation.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a single-parameter tool with no annotations or output schema, the description should compensate by explaining the parameter's role and the test's purpose. It fails entirely, leaving the agent with no understanding of the tool's contract.

    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 coverage is 0% and the description completely omits the 'message' parameter. No indication of expected format, purpose, or whether this message gets logged, echoed, or used as a payload for the async test.

    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 phrase 'Test async response' is vague and lacks resource specificity. It does not clarify what 'pool' refers to (likely a connection/worker pool given the sibling 'pool_status'), nor what aspect of async responses is being tested. It barely distinguishes from browser automation siblings but fails to differentiate from 'pool_status'.

    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?

    No guidance provided on when to invoke this tool versus 'pool_status' or under what conditions async testing is needed. No prerequisites, sequencing, or failure modes are mentioned.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of behavioral disclosure but fails to explain synchronous/asynchronous behavior, dimension constraints, viewport vs window distinctions, or error handling for invalid dimensions.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief (two words), this constitutes under-specification rather than effective conciseness. The extreme brevity leaves critical information missing rather than efficiently conveyed.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the lack of annotations, output schema, and parameter descriptions, the two-word description is insufficient for a browser automation tool that affects visible state and requires specific pixel dimensions.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The schema has 0% description coverage for width and height parameters, and the description provides no compensation—failing to specify units (pixels), valid ranges, or whether these represent viewport or window dimensions.

    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 'Resize window' is essentially a tautology that restates the tool name (browser_resize). While it identifies the action (resize) and target (window), it lacks specificity about which window (browser viewport vs OS window) and doesn't distinguish from sibling tools like browser_navigate or browser_click.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance provided on when to use this tool versus alternatives, prerequisites (e.g., needing an open browser), or specific conditions where resizing is necessary (e.g., responsive testing vs viewport adjustments).

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, yet the description discloses nothing about behavior. It doesn't state whether this clears existing text, triggers input events, simulates human typing speed, or whether the optional 'submit' parameter triggers form submission.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is only two words, but this represents under-specification rather than effective conciseness. For a 4-parameter tool with zero schema documentation, this length is inappropriately brief and front-loaded with nothing.

    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?

    Completely inadequate for the complexity level. With 4 parameters, 0% schema coverage, no annotations, and no output schema, the tool requires detailed description coverage, yet provides only a generic two-word phrase.

    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 fails to compensate for the undocumented parameters. While 'Type text' loosely hints at the 'text' parameter's purpose, it provides no insight into 'element'/'ref' (likely selector mechanisms) or 'submit' functionality.

    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 'Type text' is tautological and extremely vague. It doesn't specify the resource being acted upon (web form elements), the context (browser automation), or how it differs from siblings like browser_press_key or browser_select_option.

    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?

    Zero guidance provided. The description doesn't indicate when to use this versus alternatives like browser_press_key or browser_select_option, nor does it mention prerequisites (e.g., requiring a focused element).

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations provided, so description carries full burden. It does not disclose whether this requires an active file input element, how it handles the browser's native file picker, what validation occurs on paths, or return behavior.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While not verbose, the brevity constitutes under-specification rather than effective conciseness. Two words are insufficient for a browser automation tool with behavioral complexity.

    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?

    Severely inadequate for a browser automation tool. No mention of browser context, DOM interaction requirements, file input targeting mechanism, or sibling tool relationships. The single optional parameter with no documentation leaves critical gaps.

    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 has 0% description coverage for the 'paths' parameter. Description minimally implies these are file paths but fails to specify they are local filesystem paths, required format (absolute vs relative), or that the parameter is optional despite being an upload tool.

    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?

    Description 'Upload files' is largely tautological, restating the verb 'upload' from the name while dropping the critical 'browser' context. It fails to distinguish from generic file upload tools or clarify this is browser automation.

    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?

    Zero guidance provided. No mention of when to use this (e.g., after clicking a file input element), prerequisites, or interaction with the browser dialog/file picker.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates a capture action but lacks critical context: output format (PNG? JPEG?), return type (file path? base64? binary?), viewport handling, and whether the operation blocks until page is stable.

    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?

    Extremely brief at two words, but this crosses into under-specification rather than efficient conciseness. The single 'sentence' does not earn its place by providing actionable guidance beyond the tool name itself.

    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?

    Inadequate for a tool with 1 undocumented parameter and a confusingly similar sibling (browser_snapshot). Without output schema or annotations, the description should at minimum clarify the capture scope and differentiate from snapshot functionality.

    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 coverage is 0% for the fullPage boolean parameter, and the description fails to compensate by explaining what fullPage controls (full page vs viewport capture) or when an agent should set it to true.

    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 'Take screenshot' is a tautology that merely restates the tool name (browser_screenshot → 'Take screenshot'). It fails to distinguish from sibling tool browser_snapshot, leaving ambiguity about whether this captures the visible viewport, full DOM, or static image.

    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?

    Provides no guidance on when to use this tool versus alternatives (e.g., browser_snapshot), when to set fullPage=true vs false, or prerequisites such as requiring an open browser 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 provided, the description carries the full burden of behavioral disclosure, yet it fails to explain what 'handle' entails, whether changes are reversible, or how the browser state changes after invocation. Minimal behavioral context is provided.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief at two words, this represents under-specification rather than effective conciseness. The fragment fails to front-load critical operational details and wastes the description field with a tautology that adds no value beyond the tool name.

    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 2-parameter browser automation tool with no output schema and no annotations, the description is inadequate. It omits dialog types supported (alert, confirm, prompt), parameter interactions (e.g., promptText only relevant when accept is true), and expected behavior, leaving significant contextual gaps.

    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% (neither 'accept' nor 'promptText' have descriptions), and the description provides no compensating information. There is no indication that 'accept' controls acceptance/dismissal or that 'promptText' is for prompt dialog input. Parameters are effectively undocumented.

    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 'Handle dialog' restates the tool name (browser_handle_dialog) using a vague verb. While it identifies the resource (dialog), it fails to specify the action (accept, dismiss, fill) or distinguish from sibling browser tools.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No explicit guidance is provided on when to invoke this tool versus alternatives, nor are prerequisites stated (e.g., that a dialog must be present). Usage is only weakly implied by the term 'handle' without operational context.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries full burden but discloses nothing about: behavior when history is empty, whether navigation is synchronous, side effects, or return values.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief (two words), this represents under-specification rather than efficient conciseness. The single phrase fails to convey necessary operational context for a stateful browser action.

    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 navigation tool with side effects and no annotations/output schema, the description is inadequate. It omits critical context like 'browser history' and failure modes.

    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?

    Zero parameters exist, establishing baseline 4. The description neither adds nor subtracts information about inputs.

    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 'Go back' is tautological given the tool name 'browser_navigate_back' and fails to specify the domain (browser history navigation). While the sibling tools provide context, the description itself restates the name without adding specificity.

    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?

    No guidance provided on when to use this tool versus alternatives like 'browser_navigate' or prerequisites such as having a browser session open with history.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of behavioral disclosure, yet reveals nothing about return format, potential errors, timeouts, or whether the snapshot includes iframes/visibility states. The agent cannot predict what data structure it receives.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While only two words, this represents under-specification rather than efficient conciseness. The single 'sentence' fails to earn its place by providing actionable information about the tool's behavior or output.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the lack of output schema and annotations, the description needed to compensate by explaining what the snapshot contains (HTML, text, accessibility tree). It provides none of this, leaving critical gaps for a tool that presumably returns complex page data.

    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 zero parameters, which establishes a baseline score of 4. The description appropriately indicates no inputs are needed, though it doesn't explicitly confirm this (but none was expected given the empty 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 'Page snapshot' is essentially a tautology that restates the tool name without clarifying what kind of snapshot (DOM, text, image?) or what it returns. While it implies a read operation on a page, it fails to distinguish from sibling tools like browser_screenshot or browser_navigate.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance provided on when to use this tool versus alternatives like browser_screenshot (likely for images) or browser_evaluate (for scripted extraction). No mention of prerequisites like needing an active navigation session.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to explain that this triggers mouseenter/hover events, whether it waits for hover effects to appear, or if it returns status. The agent cannot infer side effects or synchronous behavior.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While brief (2 words), this is under-specification rather than appropriate conciseness. The description is too short to convey necessary information for a browser automation tool, failing to earn its utility through information density.

    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 2 undocumented parameters, no output schema, no annotations, and the complexity of browser automation, the description is inadequate. It lacks critical context like element targeting syntax, timeout behavior, or session management details.

    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 must compensate but does not. It mentions 'element' (matching the parameter name) but gives no format guidance (CSS selector? XPath? ID?). It completely ignores the 'ref' parameter, leaving both parameters effectively undocumented.

    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 'Hover element' is essentially a tautology that restates the tool name ('browser_hover') with minimal elaboration. While it identifies the resource ('element'), it fails to specify what kind of hover (mouse hover) or distinguish from sibling tools like browser_click.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance provided on when to use hover versus click or other interaction methods. No mention of prerequisites (e.g., needing to navigate first) or typical use cases (revealing tooltips, dropdown menus).

    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 behavioral disclosure burden but offers none. It does not state whether the tool waits for page load completion, how it handles redirects, authentication dialogs, or invalid URLs.

    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 three-word description is concise and front-loaded with no wasted text. However, brevity crosses into under-specification given the lack of schema documentation and behavioral details.

    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 single-parameter tool with 0% schema coverage, the description fails to explain the parameter's semantics or expected values. It also omits critical browser automation context such as page lifecycle behavior, error states, or side effects on the browser session.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters2/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema coverage is 0% (url parameter has no description). The description mentions 'URL' but does not compensate for the schema gap by explaining required format (absolute vs relative), supported protocols (http:, https:, file:), or validation rules.

    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 'Navigate to URL' restates the tool name (browser_navigate) with minimal elaboration. It fails to distinguish from sibling tool browser_navigate_back, which also performs navigation but presumably uses history rather than a fresh URL.

    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 provided on when to use this versus browser_navigate_back or other navigation methods. No mention of prerequisites like having an open browser context or valid URL format.

    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, yet the description fails to disclose behavioral traits. It does not indicate this is a read-only operation, what status fields are returned, or whether the pool must be initialized first.

    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?

    At three words, it is appropriately brief for a parameterless status check, but it is under-specified rather than efficiently informative. It front-loads no actionable guidance.

    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?

    Without an output schema, the description should explain what status information is returned (e.g., available instances, utilization). Instead, it provides only a label with no behavioral or return value 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?

    Input schema has zero parameters. Per evaluation rules, zero parameters establishes a baseline score of 4.

    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 'Browser pool status' is essentially a noun phrase restating the tool name with the domain prepended. It lacks a specific verb indicating what the tool does (retrieve? check? update?) and does not distinguish from sibling tool pool_test.

    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 provided on when to use this versus pool_test or other browser management tools. No mention of prerequisites or typical use cases (e.g., health checks before 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 disclosure burden but reveals nothing about behavioral traits: whether closing is destructive (session/cookies lost), if it affects pooled resources, graceful shutdown timing, or tab disposal behavior. 'Close browser' names the action without operational context.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    Extremely brief (two words) and front-loaded, but crosses into under-specification. While no words are wasted, the brevity fails to meet the informational needs for a destructive/terminal operation.

    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 low structural complexity (0 params, no output schema, no annotations), requirements are minimal. However, for a session-terminating operation, the description omits critical context about resource cleanup and subsequent tool availability (e.g., whether browser_navigate would fail afterward).

    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?

    Input schema contains zero parameters, establishing baseline score of 4. With no parameters requiring semantic clarification, the description neither adds value nor creates deficits in this dimension.

    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 'Close browser' is tautological, simply converting the tool name 'browser_close' into words. While it identifies the verb and resource, it fails to distinguish from siblings (e.g., browser_tabs) or clarify scope (entire browser vs. specific windows).

    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 provided on when to invoke this versus leaving the browser open, what prerequisites exist (e.g., an active browser session), or the consequences of closing. Lacks explicit when/when-not directives entirely.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations provided, so description carries full burden of behavioral disclosure. 'Get' implies read-only but doesn't confirm safety, format of returned data, whether requests are cleared after retrieval, or pagination behavior. Significant gaps for a data retrieval tool.

    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?

    Extremely brief (3 words), which prevents verbosity, but underspecified rather than efficiently concise. Single sentence is front-loaded but lacks the content to earn its place effectively.

    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 retrieval tool with no output schema, the description fails to explain what data structure is returned, temporal scope, or filtering capabilities. Incomplete given the lack of structured metadata.

    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?

    Zero parameters present, meeting the baseline of 4. Schema is empty object, so there's nothing to describe.

    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?

    States the action (Get) and resource (network requests), which is minimum viable. However, lacks scope specificity (from current page? since navigation? all tabs?) and doesn't differentiate from sibling browser_console_messages or browser_snapshot.

    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?

    Provides absolutely no guidance on when to use this tool versus siblings like browser_console_messages or browser_snapshot. No mention of prerequisites (e.g., must navigate first) or temporal constraints.

    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

browser-pool-mcp MCP server

Copy to your README.md:

Score Badge

browser-pool-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/OMGEverdo/browser-pool-mcp'

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