Enhanced Browser MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct browser action: navigation, history, interaction, state inspection, and waiting. Snapshot and screenshot are clearly separated (accessibility tree vs visual capture), and no two tools overlap in purpose.
Naming Consistency5/5
All tools follow the browser_verb_noun pattern consistently, using lowercase and underscores. The verb clearly indicates the action (navigate, click, type, wait), making the set predictable and easy to navigate.
Tool Count5/5
With 12 tools, the server is well-scoped for browser automation, covering essential actions without unnecessary bloat. This fits comfortably within the ideal range, and each tool earns its place.
Completeness4/5
The set covers core browser workflows: navigation, history, interaction, state reading, and waiting. Minor gaps exist (e.g., explicit scroll or page reload), but agents can work around them, making the surface reasonably complete for basic automation.
Average 3.2/5 across 12 of 12 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Navigate to a URL' without mentioning whether the tool waits for page load, handles redirects, returns a result, or affects the page state. This is a significant transparency gap for a tool that likely changes the browser context.
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 short sentence with no fluff, making it very concise. However, it is almost too sparse, providing minimal value beyond the name. It is still well-structured and front-loaded, just lacking substance.
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 one parameter, no output schema, and no annotations, the description is expected to explain basic behavioral context. The description alone is insufficient for an agent to understand what happens after navigation (e.g., does it return a snapshot? does it block until loaded?). The low complexity mitigates the issue slightly, but the complete lack of behavioral information makes this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is simple with one required parameter 'url' that has a description ('The URL to navigate to'), covering 100% of the schema. The tool description adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigate to a URL' states the core action, but it essentially restates the tool name and does not distinguish from sibling navigation tools like browser_go_back or browser_go_forward. It lacks specificity about what 'navigate' entails (e.g., loading a new page vs. history navigation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. For instance, it does not clarify that this tool is for navigating to a specific URL rather than using browser_go_back or browser_go_forward for history traversal. No when-to-use or when-not-to-use context is provided.
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, the description carries the full burden of behavioral disclosure, but it only restates the action implied by the tool name. It does not specify what happens when no forward history exists, whether the tool waits for page load, or any error handling, leaving the agent without critical behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. It efficiently conveys the core action 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?
Although the tool is simple with no parameters, the description omits crucial context about browser history navigation and edge cases. It is minimally viable for understanding the basic action but incomplete for an agent to anticipate outcomes or decide when to invoke it relative to other navigation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is complete with no properties. The description accurately reflects that no inputs are needed, and no additional parameter semantics are required.
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 forward' with the target 'next page', which is specific and distinguishes it from sibling tools like browser_go_back. While it doesn't explicitly mention 'browser history', the context of the browser tool set makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_go_back or browser_navigate. It lacks any context about prerequisites (e.g., requiring prior navigation history) or how this tool fits into navigation workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Hover over element on page' and does not mention any side effects, state changes, whether a snapshot is required, or what happens after hovering. This is a significant transparency gap for a tool that can trigger UI changes via hover events.
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, short sentence that is front-loaded with the action. It is concise and has no unnecessary words. However, it is so brief that it sacrifices important behavioral context, but for pure conciseness it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide complete context. It only states the basic action and lacks information about prerequisites, effects, or edge cases. For a tool that interacts with a live page, this is insufficient for an agent to fully understand its impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'ref' and 'element' well-described in the schema. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Hover over element on page', which is a specific verb+resource. It distinguishes itself from sibling tools like browser_click and browser_type by the action 'hover'. However, it does not explicitly call out differences from siblings, so it misses the top 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. It does not mention typical scenarios (e.g., triggering tooltips, dropdowns) or any exclusions. The usage is only implicitly conveyed by the action itself, which is not enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Type text into editable element' without revealing whether text is appended or replaced, how the 'element' permission field works, or any error or side-effect behavior. This is minimal and leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, front-loading the core action. However, it is under-specified, which slightly detracts from its overall value despite being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is part of a browser automation suite, but the description fails to mention that 'ref' comes from a page snapshot, the role of the human-readable 'element' description, or the behavior of the 'submit' flag. With no output schema or annotations, these contextual details are necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all four parameters have descriptions), so the schema handles parameter semantics. The description adds no additional meaning beyond the schema, which meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Type') and target ('editable element'), clearly distinguishing it from sibling tools like browser_click or browser_press_key. It states exactly what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., obtaining a ref from a snapshot), nor any exclusions or comparisons with browser_press_key or other 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 the full burden of behavioral disclosure. It simply states 'Perform click' without describing side effects, requirements, or potential outcomes such as page navigation. This is insufficient for an action that could trigger significant UI changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. It contains no unnecessary words and is easy to parse, though it sacrifices depth for brevity. It earns its place by stating the tool's purpose clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity of a click action, the description is incomplete. It fails to mention that a page snapshot is required, that clicking may cause navigation or other side effects, or any constraints. There is no output schema or annotations to compensate, leaving the description inadequately contextualized.
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 fully documents both parameters (ref and element) with detailed descriptions, and schema description coverage is 100%. The description adds no additional parameter semantics, but the schema already provides the necessary meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'click' and identifies the resource as a web page, which clearly distinguishes it from sibling tools like browser_hover, browser_type, and browser_press_key. It unambiguously states the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites (e.g., needing a snapshot) or context in which clicking is appropriate, leaving the agent without useful decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the literal action and says nothing about focus requirements, potential side effects (e.g., triggering form submission), or whether key combinations are supported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words or irrelevant details. It is appropriately sized for a simple one-parameter 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?
While the schema is rich and covers the parameter well, the description lacks usage context and behavioral details. It is adequate for a basic tool but leaves gaps in when to use it and what side effects may occur.
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 fully documents the 'key' parameter with examples such as 'ArrowLeft' or 'a', providing 100% coverage. The description adds no additional semantic meaning beyond what the schema already 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 'Press a key on the keyboard' uses a specific verb and resource, clearly indicating the action. It does not explicitly differentiate from sibling tools like browser_type, but the action is distinct enough by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as browser_type for typing text or browser_click. No exclusions or alternative recommendations 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, the description carries the full burden of behavioral disclosure. It only says 'take a screenshot' without detailing what the output looks like, whether it captures the full page or just the viewport, where the image is saved, or any side effects. This is a significant gap for a tool with no structured annotation support.
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, efficiently worded sentence that conveys the core action without any filler. Every word earns its place, and the length is perfectly matched to the tool's trivial parameter surface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple tool the description is minimally adequate, but it lacks important context about the output format, whether it waits for network idle, or how it differs from the sibling browser_snapshot tool. This prevents it from being fully complete for an agent deciding between capture methods.
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 takes no parameters, and the input schema confirms this with 0 properties. Since there are no parameters to document, the baseline of 4 is appropriate; the description correctly avoids inventing unnecessary parameter details.
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 ('Take a screenshot') and the target ('current page'), making its purpose immediately understandable. However, it does not differentiate from sibling tools like browser_snapshot, which could also capture page state, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_snapshot. The description does not mention any prerequisites (e.g., page must be loaded) or exclusion scenarios, leaving the user to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not disclose prerequisites (e.g., a visible dropdown, a prior snapshot), side effects (e.g., triggering change events), or behavior with multi-select. For a simple interaction, this minimal info leaves gaps about runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is appropriately sized for the tool's simplicity, though it could include a brief usage tip without becoming verbose. It is well-structured and immediately comprehensible.
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 simplicity, 100% schema coverage, and no output schema, the description is minimally adequate. However, it lacks guidance on when to use it versus sibling tools, and it does not mention multi-select behavior or prerequisites such as a snapshot. These are clear gaps, but not severe given the straightforward nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (ref, values, element). The description adds no additional meaning beyond the schema, so the baseline score of 3 applies. It does not clarify how 'values' interacts with multi-select or how ref is obtained.
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 'Select an option in a dropdown' uses a specific verb ('select') + resource ('option in a dropdown'), clearly distinguishing it from sibling tools like browser_click, browser_type, and browser_press_key. There is no ambiguity about what operation it performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used specifically for dropdown elements, nor does it exclude scenarios where browser_click might be more appropriate. There is no explicit comparison or 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?
There are no annotations, and the description does not disclose any behavioral traits beyond the bare action. It doesn't specify whether the wait is blocking, whether it can be interrupted, or whether it interacts with page load state. For a wait operation, this lack of detail leaves important behavioral aspects unaddressed.
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 one short, front-loaded sentence that conveys the core function without any fluff. Every word earns its place. It is appropriately sized for a simple, single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the complete schema, the description is still minimal. It doesn't explain why one might use this wait (e.g., to allow page loading), whether it blocks further actions, or what the return value is. There is no context to help the agent decide when to apply it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the parameter description ('The time to wait in seconds'). The description adds no additional meaning beyond the schema, but the baseline for high coverage is 3, and no parameter information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Wait for a specified time in seconds'. It uses a specific verb ('wait') and identifies the resource ('specified time'). It distinguishes itself from sibling browser tools which are navigation, clicking, typing, etc. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is a fixed delay, or that it might be preferable to wait for elements or conditions. As a result, the agent receives no context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the action and does not mention browser history dependencies, behavior when no previous page exists, or whether the navigation waits for page load.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous information. It is appropriately sized for a simple command.
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 (zero parameters, no output schema, low complexity), the description covers the core functionality. However, it omits edge-case behavior such as handling an empty browsing history, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately adds no parameter details, as there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('go back') and the resource ('previous page'), distinguishing it from sibling tools like browser_go_forward and browser_navigate. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_navigate or browser_go_forward. The description does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing what format the logs are returned in, whether logs are cleared after retrieval, or any side effects. This is minimal and lacks behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly communicates the tool's purpose. Every word is necessary and there is no redundancy or filler. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters or output schema. The description states the core function but omits details about the return value (e.g., format, structure, or whether it represents an array of messages). While this may be acceptable for such a simple tool, the lack of return information leaves the description slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with high coverage by definition. The baseline for zero parameters is 4. The description adds no extra parameter semantics, but none are required since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the console logs from the browser'. It uses a specific verb and resource, and it is distinct from all sibling tools that handle navigation, interaction, or screenshots. This is a precise and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving browser console logs, but it does not explicitly state when to use this tool versus others, nor does it mention any prerequisites or exclusions. Given the absence of alternative log-related tools, the intended context is somewhat implied but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Capture accessibility snapshot' implies a non-destructive read operation, but it does not explicitly state side effects, return format, or limitations. It adds some context about the purpose (references for interaction) but lacks deeper behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no filler. Every word adds value by conveying what the tool does and why to use it.
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 no parameters and no output schema, the description adequately covers its purpose and usage. It does not detail the snapshot's format or content, but for a simple read-only tool with no inputs, this is acceptable. The context relative to siblings is clear enough for an agent to decide when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage (empty properties object), so the schema fully documents parameters. The description adds meaning by explaining the tool's output is used for interaction references, which is useful beyond the schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures an accessibility snapshot of the current page, which is a specific verb+resource. This distinguishes it from siblings like browser_screenshot (visual) and browser_navigate (navigation), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for getting references to elements to interact with,' providing clear context for when to use the tool. It does not mention when not to use it or name specific alternatives, but the usage context is directly stated.
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:

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

Score Badge

Copy to your README.md:

[![enhanced-browser-mcp MCP server](https://glama.ai/mcp/servers/The-Thought-Magician/enhanced-browser-mcp/badges/score.svg)](https://glama.ai/mcp/servers/The-Thought-Magician/enhanced-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/The-Thought-Magician/enhanced-browser-mcp'

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