BrowserTools MCP

by Sugatraj

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
There is significant overlap between tools, particularly in the audit category where runAuditMode appears to encompass SEO, accessibility, and performance audits that have separate dedicated tools, creating confusion. However, the console and network tools are more distinct in their focus areas, and descriptions help clarify some boundaries.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., getConsoleErrors, runAccessibilityAudit, takeScreenshot), with clear action-oriented names. The main deviation is runAuditMode, which uses a more generic 'Mode' suffix, but overall the naming is predictable and readable.
Tool Count4/5
With 14 tools, the count is reasonable for a browser testing and debugging domain, covering areas like logs, audits, debugging, and screenshots. It's slightly on the higher side but well-scoped for the purpose, with each tool having a defined role in browser interaction.
Completeness3/5
The toolset covers key browser operations like logging, auditing, and screenshots, but has notable gaps. For example, there are no tools for navigation (e.g., navigate_to_url, refresh_page) or element interaction (e.g., click_element, input_text), which are essential for comprehensive browser automation, limiting agent workflows.
Average 2.8/5 across 14 of 14 tools scored. Lowest: 1/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 MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool runs debugger mode but fails to describe what that entails—whether it's interactive, what permissions are required, if it modifies state, its output format, or any side effects. This leaves critical behavioral traits unspecified for a tool that likely involves system interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise but under-specified—it lacks detail that would help an agent understand the tool's function. While not verbose, it fails to provide necessary context, making it inefficient in conveying value. It could be more front-loaded with specific actions or outcomes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'debugger mode' (likely involving system state or diagnostics), the description is incomplete. With no annotations, no output schema, and a vague purpose, it does not provide enough information for an agent to use the tool effectively. It should explain what the debugger does, what it returns, or how it interacts with the application.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate here. A baseline of 4 is applied since the schema fully covers the absence of parameters, and the description doesn't need to compensate.
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 'Run debugger mode to debug an issue in our application' is tautological—it essentially restates the tool name 'runDebuggerMode' with minimal elaboration. While it specifies the action ('run') and target ('debugger mode'), it lacks specificity about what the debugger mode actually does or what resources it operates on, unlike clearer sibling tools like 'takeScreenshot' or 'getConsoleErrors'.
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 prerequisites, context (e.g., when debugging is needed), or exclusions (e.g., not for production). With siblings like 'runAuditMode' and 'runPerformanceAudit', there is no differentiation to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this is read-only, if it requires specific permissions, how logs are returned (e.g., format, pagination), or any side effects like clearing logs. 'Check' suggests a read operation, but this isn't explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be more specific (e.g., 'Retrieve all browser console logs'). The brevity is appropriate but borders on under-specification.
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 no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what 'browser logs' include (e.g., console, network, errors), how results are structured, or how this differs from similar tools. For a tool in a set with specialized alternatives, more context is needed to guide proper selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter semantics, and it correctly implies no inputs are required, aligning with the schema. Baseline 4 is appropriate for zero-parameter tools.
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 'Check our browser logs' states a clear action ('Check') and resource ('browser logs'), but it's vague about scope and format. It doesn't distinguish from siblings like 'getConsoleErrors' or 'getNetworkLogs' that might retrieve specific log subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'getConsoleErrors' or 'getNetworkLogs'. The description implies a general log check but doesn't specify contexts, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Check' suggests a read operation, but it doesn't disclose behavioral traits such as permissions needed, rate limits, whether it returns real-time or historical data, or potential side effects. The description adds minimal value beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
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 no annotations, no output schema, and 0 parameters, the description is incomplete. It lacks details on what 'check' returns (e.g., log format, time range, filtering), behavioral context, and usage guidelines, making it inadequate for a tool that likely interacts with system logs.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, earning a baseline score of 4 for adequately handling the lack of parameters.
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 'Check ALL our network logs' states the action (check) and resource (network logs), but is vague about scope and format. It distinguishes from siblings like 'getConsoleLogs' by specifying 'network' logs, but lacks specificity about what 'check' entails (e.g., list, retrieve, monitor).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'getNetworkErrors' or 'wipeLogs'. The description implies it's for network logs, but doesn't clarify use cases, prerequisites, or exclusions, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('Get') but does not disclose behavioral traits such as whether it requires specific permissions, how it handles errors (e.g., if no element is selected), or what the return format might be. This leaves significant gaps for a tool interacting with browser elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of browser interaction and lack of annotations or output schema, the description is incomplete. It does not explain what 'selected element' entails (e.g., DOM element, properties returned) or potential side effects, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description does not add parameter details, which is appropriate here, but it could have clarified context (e.g., implicit parameters like browser session), though not required for a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Get the selected element from the browser') with a clear verb ('Get') and resource ('selected element'), but it does not distinguish it from sibling tools like 'takeScreenshot' or 'runAccessibilityAudit' that might also interact with browser elements. It's vague about what 'selected element' means in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., needing a browser context or selection), exclusions, or comparisons to sibling tools like 'runAuditMode' that might involve element inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'optimize our application', which implies a mutation or action, but doesn't specify what the tool actually does (e.g., runs audits, generates reports, makes changes). It also omits details like execution time, side effects, or output format, leaving significant gaps in understanding the tool's 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?
The description is a single sentence that is concise but under-specified. It front-loads the purpose but lacks detail, making it efficient but potentially incomplete. While it avoids waste, it could benefit from additional context to be more helpful, balancing brevity with informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by optimizing multiple aspects (SEO, accessibility, performance) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'run audit mode' entails, what the output might be, or how it differs from sibling tools, leaving the agent with insufficient information to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it could have mentioned if any implicit inputs are required (e.g., context from the application). Since there are no parameters, a baseline of 4 is appropriate, as the description doesn't have to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('run audit mode') and resource ('our application'), and it lists three optimization targets (SEO, accessibility, performance). However, it doesn't explicitly distinguish this tool from its siblings like 'runAccessibilityAudit', 'runSEOAudit', or 'runPerformanceAudit', which appear to handle individual aspects of what this tool claims to do comprehensively.
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 its siblings, such as whether it's a combined audit or should be used instead of the individual audit tools. It also lacks context on prerequisites, timing, or exclusions, leaving the agent with no clear usage instructions beyond the general purpose stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('Check') but doesn't disclose whether it requires specific permissions, how errors are retrieved (e.g., real-time vs. stored), or what the output format might be. More context on behavior is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's purpose without unnecessary elaboration, making it easy to parse quickly.
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 and output schema, the description is incomplete for effective use. It doesn't explain what 'Check' entails operationally (e.g., returns a list, triggers a scan), the scope (e.g., current page, all tabs), or error format, leaving gaps for an AI agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required, aligning with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and target resource ('browsers console errors'), making the purpose understandable. It distinguishes from some siblings like 'getNetworkErrors' by specifying console errors, but doesn't explicitly differentiate from 'getConsoleLogs' which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'getConsoleLogs' or 'getNetworkErrors'. The description only states what it does without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Check' which implies a read operation, but doesn't specify whether this requires authentication, has rate limits, returns real-time vs historical data, or affects system state. The description is too minimal for a tool that presumably accesses logs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, with zero wasted language. It's front-loaded with the core purpose and uses all words effectively to convey the essential function.
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 log-checking tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the errors are returned in, whether they're filtered or comprehensive, time ranges covered, or how this differs from sibling logging tools. The agent lacks necessary context for effective use.
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 with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps, and it correctly implies no required inputs for checking logs.
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 ('Check') and resource ('network ERROR logs'), making the tool's purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'getNetworkLogs' or 'getConsoleErrors', which would require more specific scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getNetworkLogs' or 'getConsoleErrors'. There's no mention of specific use cases, prerequisites, or exclusions, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Run an accessibility audit' implies analysis/read operations, it doesn't disclose what the audit actually does - whether it modifies the page, requires specific page states, has side effects, or what kind of output to expect. The description is too minimal to understand the tool's behavior beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states what the tool does. There's zero waste or unnecessary elaboration. It's front-loaded with the core action and target, making it immediately understandable at minimal cognitive cost.
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 no annotations, no output schema, and multiple sibling audit tools, the description is insufficiently complete. It doesn't explain what an 'accessibility audit' entails, what results to expect, how it differs from other audit tools, or any behavioral characteristics. The agent would need to guess about the tool's output format and appropriate usage 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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since there are none, and the schema already fully documents the empty parameter set. No additional parameter information is needed or provided.
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 ('Run an accessibility audit') and target ('on the current page'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling audit tools like 'runBestPracticesAudit' or 'runSEOAudit' - it only specifies the audit type but not how it differs from other audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. With multiple audit tools available (accessibility, best practices, SEO, performance, NextJS), there's no indication of what makes accessibility audits distinct or when they're appropriate versus other audit types. No prerequisites, 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 provided, the description carries the full burden of behavioral disclosure. While 'run a best practices audit' implies a read-only analysis operation, the description doesn't specify what happens during execution (does it block the page? how long does it take?), what permissions are needed, what kind of output to expect, or whether it has any side effects on the page state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that communicates the essential action and scope without any wasted words. It's front-loaded with the core functionality and doesn't include unnecessary elaboration or repetition.
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 an audit tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'best practices' means in this context, what standards or criteria are used, what format the results will be in, or how comprehensive the audit is. Given the complexity implied by 'best practices audit' and the lack of structured documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it correctly focuses on the tool's purpose rather than attempting to describe non-existent inputs.
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 ('run a best practices audit') and target ('on the current page'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from sibling audit tools like 'runAccessibilityAudit', 'runPerformanceAudit', or 'runSEOAudit', which would require specifying what type of best practices it covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance - it only indicates the tool should be used on 'the current page'. There's no explicit guidance about when to use this tool versus other audit tools (like accessibility or performance audits), no prerequisites mentioned, and no exclusions or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but provides no information about what the audit entails, what metrics are measured, whether it requires specific page conditions, what the output format might be, or any side effects. The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a zero-parameter tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of performance auditing, the lack of annotations, and no output schema, the description is insufficient. It doesn't explain what a 'performance audit' means in this context, what gets measured, what the expected output might be, or how it differs from other audit tools. For a specialized tool with rich siblings, more context is needed.
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 with 100% schema description coverage, so the baseline is 4. The description doesn't need to compensate for missing parameter documentation since there are no parameters to document. The description appropriately doesn't mention parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('run a performance audit') and target ('on the current page'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling audit tools like runAccessibilityAudit, runBestPracticesAudit, runSEOAudit, or runNextJSAudit, which all follow the same 'run X audit on current page' pattern.
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 about when to use this tool versus alternatives. The description doesn't mention what constitutes a performance audit, when it's appropriate, or how it differs from other audit tools in the sibling list. There's no context about 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe what an SEO audit entails, what kind of output to expect, whether it's resource-intensive, or any side effects. The description is functional but lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that communicates the core functionality without any unnecessary words. It's perfectly front-loaded and wastes no space on redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is an audit tool with no annotations and no output schema, the description is insufficient. It doesn't explain what an SEO audit measures, what format results come in, or how this differs from other audit tools. For a tool that presumably produces diagnostic information, more context is needed.
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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this parameterless tool.
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 ('run') and target ('SEO audit on the current page'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling audit tools like 'runAccessibilityAudit' or 'runPerformanceAudit' beyond specifying the audit type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like other audit tools or debugging tools. It mentions 'current page' but doesn't specify prerequisites, timing considerations, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool wipes logs from memory, implying a destructive action, but does not specify whether this is irreversible, requires permissions, affects performance, or provides confirmation. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's action without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.
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 destructive nature and lack of annotations or output schema, the description is incomplete. It fails to address critical aspects like confirmation of action, error handling, or impact on system state, which are essential for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter details, but this is appropriate, resulting in a baseline score of 4 for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('wipe') and resource ('all browser logs from memory'), making the purpose specific and understandable. However, it does not explicitly distinguish this destructive operation from its read-only sibling tools like getConsoleLogs or getNetworkLogs, which would require a score of 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. The description lacks context about prerequisites, timing (e.g., after diagnostics), or exclusions, leaving the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'take a screenshot' implies a read-only operation that captures visual data, it lacks details on permissions needed, output format (e.g., image type, size), side effects, or error conditions, which are critical for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse and understand immediately, which is ideal for a tool with no parameters.
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 (0 parameters, no output schema, no annotations), the description is minimal but incomplete. It lacks behavioral details like output format or error handling, which are essential for the agent to use it effectively, especially without annotations to fill gaps.
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 schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't mention parameters, aligning with the schema. A baseline of 4 is applied as it correctly handles the absence of parameters without adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('take a screenshot') and the target resource ('current browser tab'), using precise verb+resource language. It effectively distinguishes this tool from its sibling tools, which are focused on logging, debugging, auditing, and element selection rather than visual capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., browser context), exclusions, or comparisons to sibling tools like those for audits or logs, leaving the agent to infer usage context independently.
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:

[![Cursor-Browser-Tools-MCP MCP server](https://glama.ai/mcp/servers/Sugatraj/Cursor-Browser-Tools-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Sugatraj/Cursor-Browser-Tools-MCP)

Score Badge

Copy to your README.md:

[![Cursor-Browser-Tools-MCP MCP server](https://glama.ai/mcp/servers/Sugatraj/Cursor-Browser-Tools-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Sugatraj/Cursor-Browser-Tools-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/Sugatraj/Cursor-Browser-Tools-MCP'

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