browser-connect-mcp

Server Quality Checklist

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

Latest release: v0.4.3
Disambiguation2/5
Multiple tools have overlapping purposes: console_search and console_advanced_search are nearly identical, network_performance and performance_profile both cover performance metrics, and log_analyze and backend_logs_stream both deal with log analysis. This creates confusion about which tool to select for a given task.
Naming Consistency2/5
Tool names use a mix of prefixes and patterns: browser_list_tabs and browser_connect follow verb_noun, but network_performance is a noun, performance_profile is a noun, and debug_localhost uses a different prefix. Prefixes are inconsistent (some tools have no domain prefix).
Tool Count4/5
16 tools is slightly above the typical 3-15 range, but the broad scope covering browser debugging, network analysis, performance profiling, security scanning, and backend logging justifies the count. Each tool has a distinct role, even if a few could be consolidated.
Completeness3/5
The tool set covers core debugging workflows like connecting, analyzing network/console, and exporting HAR, but lacks general browser interaction (e.g., navigation, DOM inspection, JavaScript execution) and tab management (closing tabs). Some important lifecycle operations are missing.
Average 3.2/5 across 16 of 16 tools scored. Lowest: 2.5/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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose whether profiling is read-only, how long it takes, whether it modifies state, what data it collects, or what the output format resembles. 'Advanced performance profiling' is too vague to convey meaningful 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, short sentence with no fluff, but the word 'Advanced' adds no concrete information. The description is efficient but under-specifies the tool's functionality, making it neither well-structured nor truly informative.
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?
With no output schema, no annotations, and three parameters, the description leaves major gaps. It does not explain return values, edge cases, or how this profiling relates to the broader tool ecosystem, making it incomplete for an agent to invoke correctly.
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?
All three parameters are fully described in the schema, so the description adds little semantic value. The mention of 'recommendations' loosely aligns with includeRecommendations, but the description does not explicitly map parameters to behavior or add usage syntax.
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 identifies a profiling action with bottleneck detection and recommendations, but it lacks a concrete resource target and does not distinguish it from sibling tools like network_performance. 'Advanced performance profiling' is generic and could apply to multiple 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 guidance is provided on when to use this tool versus network_performance, network_analyze, or log_analyze. There are no exclusions or alternative recommendations, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'Disconnect from a specific browser tab' without mentioning side effects, prerequisites, error behavior, or what happens to the tab. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short phrase with no wasted words. It is front-loaded and concise, but it lacks full sentence structure and contextual detail. As a result, it is concise but slightly under-specified.
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 (one parameter, no output schema) and lack of annotations, the description is insufficient. It does not explain what 'disconnect' does to the tab, when it should be used, or what the return value is. More context is needed for an agent to use it correctly.
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 schema already documents the 'tabId' parameter with a clear description, and schema coverage is 100%. The tool description adds no additional meaning beyond the schema, so the schema carries the load. A baseline 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 uses the verb 'Disconnect' and identifies the resource 'browser tab', making the action clear. It subtly distinguishes from sibling tool 'browser_connect' by describing the opposite action, but it does not elaborate on what 'disconnect' entails (e.g., closing a debugging session), so it is not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool, any prerequisites (e.g., the tab must already be connected), or alternatives, leaving the agent to infer from the name and 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states a high-level outcome ('find patterns, anomalies, trends, and suggestions') without mentioning side effects, read-only nature, permissions, or operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately sized, though it could pack more useful information within the same length.
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?
With no output schema and no annotations, the description must supply context but fails to mention the required tabId parameter or the optional includeAllInsights flag. It also does not indicate what the analysis output looks like, making it incomplete for a tool with modest complexity.
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?
Both parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description adds no additional parameter semantics 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 clearly states the tool's purpose with a specific verb 'analyze' and resource 'logs', and lists expected outcomes (patterns, anomalies, trends, suggestions). However, it does not differentiate from sibling tools like network_analyze or console_search, which also deal with logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 lacks any context about prerequisites, suitable scenarios, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure, but it only gives a high-level action. It does not state whether the operation is read-only, how it interacts with browser tabs, what the returned data structure is, or any side effects/limitations.
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, front-loaded sentence with no redundant words. It is appropriately concise for its level of detail.
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 having a detailed schema and multiple parameters, the description lacks essential context for a complex tool: no return value description, no usage context, and no positioning relative to sibling tools. The tool appears useful but is under-specified.
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 schema already provides detailed descriptions for all 7 parameters (100% coverage), so the description adds no additional parameter semantics. This matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Analyze') and resource ('network requests and responses from connected browser tabs'), which distinguishes it from sibling tools like network_export_har (export) and network_performance (performance). However, 'analyze' is somewhat broad and doesn't specify the filtering or querying nature explicitly.
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 over alternatives. There is no mention of prerequisites (e.g., needing a connected tab) or exclusions, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool retrieves statistics (implying a read operation), but does not disclose return format, whether a live connection is required, error behavior, or any limitations. This is a significant gap for a tool with no annotation safety hints.
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, front-loaded sentence with no redundancy. It conveys the action and target efficiently, earning full marks for conciseness and structure.
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 a single parameter, the description is thin. It fails to explain the context for use (e.g., when a tab is connected, what constitutes 'performance statistics'), and does not reference sibling alternatives. A minimal description may be acceptable for a trivial tool, but this one lacks essential behavioral and usage context.
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: the only parameter tabId has a description ('The ID of the tab to analyze'). The tool description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 network performance statistics for a connected browser tab'. It uses a specific verb ('Get') and resource ('network performance statistics') and specifies the target ('connected browser tab'). However, it does not distinguish itself from sibling tools like network_analyze, which likely performs similar or overlapping analysis.
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 context: it implies a browser tab must be connected. It gives no guidance on when to use this tool versus alternatives like network_analyze or network_export_har, and there are no exclusions or prerequisites 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 states the action (scan) but does not mention whether the scan is read-only, whether it requires permissions, what it returns, or if there are any side effects. This is insufficient for a security tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core 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?
Without an output schema, the description should explain what the scan results look like or how to interpret them. It does not. The description also fails to mention potential security implications or the meaning of the includeRecommendations parameter in practice. For a security-related tool, this is a significant informational gap.
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 tabId and includeRecommendations fully described. The tool description adds no additional parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scan' and the resource 'security vulnerabilities in console and network traffic', which distinguishes it from sibling tools like console_search and network_analyze. However, it does not specify the exact scope or output, so it is not perfectly distinct.
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 console_search or network_analyze. There are no explicit conditions, prerequisites, or examples of suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'attach' without explaining session duration, permissions, or side effects. It also omits that the tool supports Deno and Chrome in addition to Node.js, which is relevant for correct usage.
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 front-loads the core action and purpose without filler or redundancy. It is appropriately sized for the tool's simplicity.
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 concise phrasing, the tool has four parameters and no output schema, yet the description does not explain return values, whether attaching is blocking, or how to detach. For a debugging tool, this leaves significant gaps in understanding expected behavior.
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?
All four parameters have descriptions in the schema, giving a baseline of 3. The tool description adds no extra parameter semantics, such as how host/port relate to processId or which runtime requires which parameters, so it neither improves nor degrades the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Attach' with a clear resource ('Node.js process debugger') and purpose ('breakpoint debugging'), which distinguishes it from sibling tools like debug_localhost or backend_logs_stream. It is unambiguous and directly states the tool's function.
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 such as debug_localhost or backend_logs_stream. The description implies usage for breakpoint debugging but lacks explicit 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?
With no annotations, the description carries full responsibility for disclosing behavior. It only states the purpose ('for debugging') but does not explain what 'connect' entails, whether it changes browser state, requires a previously launched debugging server, or returns any confirmation. No side effects or prerequisites are disclosed.
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 sentence, concise and front-loaded with the action. Every word contributes to the core purpose, and there is no redundant or tangential 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?
The tool is part of a debugging workflow with siblings like browser_list_tabs and browser_disconnect, but the description does not explain how tabId is obtained, what happens after connection, or how to interpret the lack of an output schema. Given the complexity of the workflow, the description is too sparse to be fully actionable.
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 all three parameters (host, port, tabId) having descriptions. The tool description adds no parameter-level semantics beyond what the schema 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.
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: 'Connect to a specific browser tab for debugging.' It uses a specific verb ('Connect') and resource ('specific browser tab'), and the 'for debugging' qualifier positions it within the tool suite. It distinguishes itself from siblings like browser_list_tabs (listing) and browser_disconnect (disconnecting).
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 about when to use this tool versus alternatives, nor any prerequisites such as launching the browser with a debugging port. The description only implies usage for debugging, but lacks direction to first list tabs via browser_list_tabs or to prefer other tools in specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'debugging enabled' but does not disclose side effects (e.g., process lifetime, port binding, whether it blocks), prerequisites (e.g., executable path), or what the function returns. This is insufficient for a tool that launches a browser.
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 is front-loaded with the action and resource. Every word earns its place, with no filler or redundancy.
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 or annotations, the description must be self-sufficient, but it fails to convey critical context such as expected return values, blocking behavior, or whether the browser remains open. For a tool with four optional parameters and potential side effects, this is a significant gap.
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 provides descriptions for all four parameters, resulting in 100% schema description coverage. The description itself adds no additional parameter meaning beyond the schema's field descriptions, so a baseline 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 clearly states the verb 'Launch' and the resource 'a new browser instance', with the specific qualifier 'with debugging enabled'. This distinguishes it from sibling tools like browser_connect (which likely attaches to an existing instance) and browser_disconnect.
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 use this tool versus alternatives. The description does not mention connecting to an existing browser, listing tabs, or other contexts, leaving the agent without exclusions or alternative recommendations.
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 should disclose side effects, prerequisites, or return behavior, but it only restates the function; no mention of file size implications, tab binding, or output format beyond the format name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that states the core purpose with no redundant information; extremely efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema, the description is minimal but sufficient for the core action; however, it lacks context about the return value, usage timing, or limitations, making it only partially complete.
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 already provides complete descriptions for both parameters (tabId and includeResponseBodies), so the description adds no further semantic value; baseline score applies.
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 'Export' and target 'network traffic to HAR format', clearly distinguishing it from sibling tools like network_analyze or network_performance.
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 statement of when to use this tool vs alternatives; it lacks any contextual guidance or exclusions, relying solely on the tool's name and basic function.
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 must carry the full burden of behavioral disclosure. 'Stream and search logs' is a high-level summary that does not explain key behaviors such as whether the stream blocks, how follow works, whether Docker access is required, or whether it returns historical logs by default. This is insufficient for a tool with real-time streaming and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, and contains no filler. It conveys the core purpose and scope efficiently. Every word contributes meaning, making it an exemplary model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested filters object, no output schema, no annotations), the one-sentence description is insufficient. It does not explain streaming semantics, return format, or how search/filtering works. It merely states the obvious purpose without covering behavioral or output expectations, leaving significant ambiguity for an agent.
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 high (80%), so the baseline is 3. The description adds minimal value beyond the schema: it enumerates source types that already appear in the 'source' enum and uses 'stream' and 'search' which loosely map to 'follow' and 'filters'. No additional parameter semantics are provided, so the score stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Stream and search logs from backend applications (files, processes, Docker containers)'. It uses a specific verb pair ('stream and search'), identifies the resource ('logs from backend applications'), and enumerates source types, which distinguishes it from sibling tools like console_search (browser console) and network_performance.
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 backend logs from files, processes, or Docker containers, which provides some context. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The phrase 'from backend applications' hints at use cases but lacks direct guidance like 'use this instead of console_search for server-side logs'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior, but only states it is a 'search' operation. It does not disclose whether it is read-only, what it returns, potential side effects, or any limitations. This is insufficient for a tool with nested options and no annotation 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, focused sentence that front-loads the key phrase 'Advanced console search' and then lists the specific features. Every word contributes to the message, with no redundancy or filler, making it exceptionally concise while still conveying the tool's core purpose.
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 moderate complexity (nested objects, correlation, statistics) and the absence of an output schema, the description should explain what the tool returns or how results are presented. It only lists features without describing the output or usage context, leaving a significant gap for agents to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for every parameter (100% coverage), including definitions for 'patterns', 'correlate', and 'includeStats'. The description's mention of 'pattern matching, correlation, and statistics' merely summarizes the schema without adding new information, so it meets the baseline but does not enhance parameter understanding.
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 performs 'Advanced console search' with specific capabilities ('pattern matching, correlation, and statistics'), providing a specific verb, resource, and scope. This distinguishes it from the sibling 'console_search' which likely handles simpler queries.
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 word 'advanced' implies this tool is intended for complex search scenarios, and the presence of a sibling 'console_search' suggests a simpler alternative, but the description provides no explicit 'when to use' or 'when not to use' guidance. It does not name alternatives or state exclusions, leaving usage largely implied rather than clearly directed.
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 for behavioral disclosure. It only says 'launch' and 'automatically connect', without noting side effects like opening a visible browser window, potential port conflicts, resource usage, or whether the connection is ephemeral. This is minimal for a tool with side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that clearly states the action and purpose with no redundant words. It earns its place efficiently.
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 tool with one required parameter and no output schema, the description covers the core purpose. However, without annotations, it lacks details on success/failure behavior, return values, or the debugging connection mechanics. It is adequate but not comprehensive.
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 each parameter (port, path, protocol, debugPort, executablePath) described. The description adds no additional parameter semantics beyond 'localhost URL', so a baseline 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 clearly states the tool launches a browser with a localhost URL and automatically connects for debugging. It distinguishes itself from siblings like browser_launch (launch only) and browser_connect (connect only) by combining both actions with a debugging focus.
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 localhost debugging but does not explicitly state when to use this tool over alternatives (e.g., browser_launch + browser_connect) or mention any exclusions or prerequisites. The debugging context is evident, but no clear guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the tool works on 'connected browser tabs', adding some behavioral context. However, with no annotations, it does not disclose return format, edge cases, or any side effects beyond the basic search functionality.
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, front-loaded sentence with no wasted words. It communicates the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with full schema coverage, the description is adequately complete. It does not explain return values or provide detailed usage context, but the tool's straightforward nature and schema descriptions cover most needs.
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 every parameter already documented. The description itself adds no parameter-specific meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches and filters console messages from connected browser tabs, using a specific verb and resource. It is distinct from other browser utilities but does not explicitly differentiate from console_advanced_search.
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 searching console messages but does not provide explicit when-to-use guidance or exclude alternative tools. No mention of when to choose this over console_advanced_search or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool 'automatically' correlates and finds root causes, but does not explain how correlation works, whether it modifies data, requires prior data, or what output format to expect. This is insufficient for a tool that likely performs complex analysis.
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 sentence, front-loaded with the primary action 'Automatically correlate errors', and contains no extraneous words. It is concise and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description should provide more detail about the return value or side effects. 'Find root causes' is vague and does not clarify the output format. It is adequate for a basic understanding but leaves significant gaps for an agent to invoke it correctly.
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 already documents all parameters (tabId, timeWindow, minSeverity) with descriptions. The tool description adds no further semantics beyond naming the correlation task, so it meets the baseline but does not exceed it.
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: 'Automatically correlate errors between console and network, find root causes.' It uses a specific verb ('correlate') and resource ('errors between console and network'), and the goal of root cause analysis distinguishes it from sibling tools like console_search or network_analyze which focus on individual sources.
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 implies when to use this tool: when you need to connect errors across console and network logs to identify root causes. However, it does not explicitly name alternatives or specify when not to use it, so it falls short of a 5 but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It indicates a read-only operation (listing), but does not mention potential errors, prerequisites (e.g., browser must be running with debugging enabled), or any side effects. For a simple list, this is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys exactly what the tool does without any fluff. Every word earns its place, and there is no unnecessary repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no output schema and well-documented parameters, the description is nearly complete. It could mention that it relies on the browser debugging port, but this is implicitly clear from the schema. Overall, it adequately covers the tool's purpose and requirements.
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 (host and port) with defaults and descriptions, achieving 100% schema coverage. The description adds no additional parameter context beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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: listing all available browser tabs that can be connected to. It uses a specific verb ('List') and resource ('available browser tabs'), and distinguishes itself from sibling tools like browser_connect and browser_launch by focusing on listing connectable tabs.
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 this is a precursor to connecting ('that can be connected to'), but it does not explicitly state when to use it versus browser_connect or other sibling tools. It lacks clear 'when/when-not' guidance, though the purpose is contextually clear enough for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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