Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@browser-connect-mcp Debug my app running on localhost:3000"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants to connect to browser DevTools and backend debuggers for comprehensive full-stack debugging. Works with any MCP-compatible tool including Claude Desktop, Claude Code, Cursor, Cline, Roo-Cline, and more!
Browser Connect MCP gives AI assistants the ability to:
Frontend Debugging:
š Launch Chrome with debugging enabled automatically
š Read console logs and errors from your web pages
š Monitor network requests and API calls
š Analyze performance issues
š Scan for security vulnerabilities
Backend Debugging (NEW!):
š Stream and analyze backend logs in real-time
š Attach to Node.js debuggers for breakpoint debugging
š³ Monitor Docker container logs
š Parse structured and unstructured log files
š Search and filter logs with pattern matching
AI-Powered Analysis:
š¤ Intelligent error correlation between frontend and backend
š” Root cause analysis across the full stack
šÆ Performance bottleneck detection
š”ļø Security vulnerability scanning
All through natural conversation - no coding required!
Related MCP server: Chrome DevTools MCP
Add to your AI assistant's MCP configuration. Here are examples for popular tools:
IMPORTANT: Due to how MCP clients handle spawning commands, you MUST use the following configuration format with npx as the command and the package name as an argument:
Claude Desktop (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"browser-connect": {
"command": "npx",
"args": ["-y", "browser-connect-mcp"],
"env": {
"LOG_LEVEL": "info"
}
}
}
}Note: The -y flag ensures npx runs without prompting. NPM will automatically use the latest version.
Cursor/Cline/Other MCP Tools: Check your tool's documentation for MCP server configuration location.
After saving the configuration, restart your AI assistant application to load the browser debugging capabilities.
Just talk to your AI assistant naturally:
You: "Help me debug my website at localhost:3000"
AI: I'll help you debug your website. Let me launch Chrome with debugging enabled
and connect to it.
[AI launches Chrome and connects automatically]
Now I'm connected to your browser. I can see the console messages and network traffic.
What specific issues are you experiencing?
You: "The page is loading slowly"
AI: Let me analyze the performance of your page...
[AI automatically runs performance analysis]
I found several performance issues:
1. Large uncompressed images (3.2MB total)
2. Render-blocking JavaScript in the header
3. Multiple API calls that could be batched
Would you like me to investigate any of these issues in detail?This MCP server works with any tool that supports the Model Context Protocol:
Claude Desktop - Anthropic's official desktop app
Claude Code - Anthropic's CLI for developers
Cursor - AI-powered code editor
Cline - Command-line AI assistant
Roo-Cline - Enhanced version of Cline
Any MCP-compatible IDE or platform
"Launch Chrome and help me debug my website"
"Debug my app running on localhost:3000" - Automatically launches and connects
"Open localhost:8080 in my default browser" - Opens in your preferred browser
"Connect to my existing Chrome browser"
"Show me any JavaScript errors"
"Are there any failed API calls?"
"Why is my page loading slowly?"
"Check for security vulnerabilities"
"Find memory leaks"
"Debug CORS issues"
"Export network traffic for analysis"
"Analyze the performance of this page"
"Which requests are taking the longest?"
"Find performance bottlenecks"
"Show me the slowest API endpoints"
"What errors are happening?"
"Find all TypeErrors in the console"
"Show me errors related to authentication"
"Are these errors related to each other?"
"Run a security scan"
"Check if any sensitive data is exposed"
"Look for security vulnerabilities"
"Are there any insecure requests?"
"Stream logs from my Node.js server"
"Show me backend errors from server.log"
"Attach debugger to my Node.js process on port 9229"
"Monitor my Docker container logs"
"Find all database errors in the backend logs"
"Correlate frontend errors with backend logs"
"Show me slow API endpoints from backend logs"
You: "My app isn't working, can you help debug it?"
AI: I'll help you debug your app. Let me connect to your browser and see what's happening.
[Automatically launches/connects to Chrome]
I can see your application. Let me check for any errors...
I found several issues:
1. API calls to /api/user are returning 401 Unauthorized errors
2. There are CORS errors when trying to access the payment service
3. Several "undefined is not a function" errors in your React components
The 401 errors suggest an authentication issue. Would you like me to:
- Look at the request headers to check authentication tokens?
- Find when the authentication errors started?
- Check if there are any related console errors?You: "Users are complaining the checkout page is slow"
AI: I'll analyze the checkout page performance. Let me connect to your browser and load the checkout page.
[Connects and monitors the page load]
Here's what I found analyzing your checkout page:
Performance Issues:
1. Initial page load: 4.3 seconds (should be under 3s)
2. Largest Contentful Paint: 3.8 seconds
3. Time to Interactive: 5.2 seconds
Main bottlenecks:
- Product images are not optimized (2.1MB total)
- Stripe SDK loads synchronously, blocking render
- 3 sequential API calls that could run in parallel
Recommendations:
1. Compress and lazy-load product images
2. Load Stripe SDK asynchronously
3. Parallelize the API calls
Would you like me to show you the specific network requests causing delays?You: "Can you check my app for security issues?"
AI: I'll run a comprehensive security scan on your application.
[Automatically scans console logs and network traffic]
Security Scan Results:
ā ļø High Priority Issues:
1. API keys exposed in console logs (GitHub API key found)
2. User passwords visible in network requests (should use HTTPS)
3. Missing security headers (CSP, X-Frame-Options)
š Medium Priority:
1. Cookies without 'Secure' flag
2. LocalStorage containing sensitive user data
3. Mixed content warnings (HTTP resources on HTTPS page)
ā Good Security Practices Found:
1. HTTPS enabled on main domain
2. Authentication tokens expire appropriately
3. Input validation on forms
Would you like me to explain how to fix any of these issues?You: "My users are getting 500 errors but I can't figure out why"
AI: I'll help you debug this issue by examining both frontend and backend. Let me start by connecting to your browser and checking for errors.
[Connects to browser and analyzes network traffic]
I see multiple 500 errors from /api/checkout. Now let me check your backend logs to understand what's happening server-side.
[Streams backend logs]
Found the issue! Here's what's happening:
Frontend (Browser):
- POST /api/checkout returning 500 errors
- Errors started 15 minutes ago
- Affecting 23% of requests
Backend (Server Logs):
- Database connection pool exhausted
- "Error: Connection timeout" in checkout handler
- Memory usage spiking before errors
Root Cause:
Your checkout process isn't closing database connections properly, leading to connection pool exhaustion under load.
Quick Fix:
Add connection.release() after your database queries in the checkout handler.
Long-term Fix:
Implement connection pooling with automatic cleanup and monitoring.You: "I need help debugging my React app"
Your AI assistant will automatically:
1. Launch Chrome with debugging enabled
2. Navigate to your app
3. Start monitoring console and network
4. Provide insights on any issues foundYou: "Are there any errors on my website?"
Your AI assistant will:
1. Connect to your browser
2. Search for all error-level messages
3. Analyze error patterns
4. Suggest fixesYou: "Help me debug why my API calls are failing"
Your AI assistant will:
1. Monitor network traffic
2. Identify failed requests
3. Analyze request/response details
4. Identify patterns in failuresYou: "Analyze my server logs for errors"
Your AI assistant will:
1. Connect to your log source (file, process, or Docker)
2. Parse and structure log entries
3. Filter for errors and warnings
4. Identify patterns and anomalies
5. Correlate with frontend issuesYou: "Debug my Node.js application"
Your AI assistant will:
1. Attach to Node.js debugger (--inspect)
2. Monitor runtime errors and exceptions
3. Analyze performance bottlenecks
4. Track memory usage
5. Provide optimization suggestionsAutomatic Chrome Launch: Your AI assistant launches Chrome with debugging enabled - no manual setup!
Multi-Browser Support: Works with Chrome, Chromium, Brave, Edge, and more
Default Browser Support: Can open URLs in your system's default browser
Tab Discovery: Find and connect to existing browser tabs
Smart Connection: Maintains connection throughout debugging session
Localhost Debugging: Special support for debugging localhost applications
Error Detection: Automatically finds JavaScript errors
Pattern Matching: Search logs with intelligent patterns
Error Correlation: Links related errors together
Smart Filtering: Focus on relevant messages
Request Analysis: Monitor all HTTP/HTTPS traffic
Performance Metrics: Identify slow requests
Error Detection: Find failed API calls
HAR Export: Export traffic for external analysis
Automatic Analysis: AI assistants proactively identify issues
Root Cause Detection: Find the source of cascading errors
Performance Recommendations: Get optimization suggestions
Security Scanning: Detect vulnerabilities automatically
Log Streaming: Real-time log monitoring from files, processes, or containers
Node.js Debugger: Attach to Node.js processes with --inspect
Log Parsing: Automatic parsing of JSON and text log formats
Pattern Matching: Advanced filtering with regex support
Docker Support: Monitor container logs directly
Process Monitoring: Track stdout/stderr from running processes
npm install -g browser-connect-mcpThen update your AI assistant's config:
{
"mcpServers": {
"browser-connect": {
"command": "browser-connect-mcp",
"env": {
"LOG_LEVEL": "info"
}
}
}
}git clone https://github.com/perception30/browser-connect-mcp.git
cd browser-connect-mcp
npm install
npm run build// macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
// Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"browser-connect": {
"command": "npx",
"args": ["-y", "browser-connect-mcp@0.4.1"]
}
}
}Important: Always use npx as the command with the package name as arguments. Do NOT use the package name directly as the command - this will cause a "spawn ENOENT" error.
Check Cursor's MCP settings in the preferences/settings panel for adding MCP servers.
These CLI tools typically use a configuration file like .cline/config.json. Consult their documentation for MCP server setup.
Configuration varies by extension. Look for MCP server settings in the extension's configuration panel.
Make sure you've restarted your AI assistant application after updating the configuration
Try asking "Launch a new Chrome browser for debugging"
Check that Chrome/Chromium is installed on your system
Ensure the web page is loaded and active
Try refreshing the page after your AI assistant connects
Ask your AI to "Check the connection status"
The MCP server will try to find Chrome automatically
If it fails, make sure Chrome or Chromium is installed
On Linux, you might need to install chromium-browser
For Node.js debugging, ensure your app is started with --inspect flag
Check that log files have read permissions
For Docker logs, ensure Docker is running and you have permissions
Verify the debug port (default 9229) is not blocked by firewall
When you ask your AI assistant to debug your application, this MCP server:
For Frontend Debugging:
Launches or connects to Chrome with debugging protocol enabled
Establishes a debugging session using Chrome DevTools Protocol
Monitors console and network events in real-time
Captures errors, performance metrics, and security issues
For Backend Debugging:
Connects to log sources (files, processes, Docker containers)
Attaches to Node.js debuggers when available
Streams and parses logs in real-time
Correlates backend issues with frontend errors
AI Analysis: 5. Provides your AI assistant with comprehensive debugging data 6. Enables intelligent analysis across the full stack 7. Maintains context throughout your debugging conversation
All of this happens automatically - you just describe what you need!
Local Only: All debugging happens on your local machine
No Data Storage: Information is only kept during the active session
Secure by Default: Uses Chrome DevTools Protocol securely
Permission-Based: AI assistants ask before performing actions
We welcome contributions! Please see our Contributing Guide for details.
Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
š Full NPM Documentation - Comprehensive guide with all features and API reference
š Quick Reference - Cheat sheet for common commands and workflows
š§ API Reference - Detailed tool specifications
š” Examples - Real-world usage examples
š API Usage Examples - Detailed API request/response examples
š Backend Debugging Best Practices - Guide for debugging backend applications
Issues: GitHub Issues
Discussions: GitHub Discussions
Documentation: See links above
This project is licensed under the MIT License - see the LICENSE file for details.
Built on the Model Context Protocol by Anthropic
Powered by Chrome DevTools Protocol
Inspired by developers who need better debugging tools
Made with ā¤ļø for developers who want to debug with AI assistance
This server implements the Model Context Protocol (MCP) standard, making it compatible with:
Claude Desktop & Claude Code (Anthropic)
Cursor IDE
Cline & Roo-Cline CLI tools
VS Code extensions supporting MCP
Any future tools implementing the MCP standard
Attach to a Node.js process debugger for breakpoint debugging
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Debug host | localhost |
| port | Yes | Debug port (e.g., 9229 for Node.js) | |
| type | No | Runtime type | node |
| processId | No | Process ID to attach to |
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.
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.
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.
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.
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.
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.
Stream and search logs from backend applications (files, processes, Docker containers)
| Name | Required | Description | Default |
|---|---|---|---|
| follow | No | Follow log in real-time | |
| format | No | Log format | auto |
| source | Yes | Log source type | |
| target | Yes | File path, process ID, container ID, or command | |
| filters | No |
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.
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.
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.
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.
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.
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.
Connect to a specific browser tab for debugging
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Browser debugging host (default: localhost) | localhost |
| port | No | Browser debugging port (default: 9222) | |
| tabId | Yes | The ID of the tab to connect to |
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.
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.
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.
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.
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.
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.
Disconnect from a specific browser tab
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | The ID of the tab to disconnect from |
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.
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.
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.
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.
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.
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.
Launch a new browser instance with debugging enabled
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to open in the browser (e.g., http://localhost:3000) | |
| debugPort | No | Chrome DevTools debugging port (default: 9222) | |
| executablePath | No | Path to Chrome/Chromium executable (auto-detected if not provided) | |
| useDefaultBrowser | No | Open URL in system default browser instead of Chrome with debugging |
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.
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.
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.
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.
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.
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.
List all available browser tabs that can be connected to
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Browser debugging host (default: localhost) | localhost |
| port | No | Browser debugging port (default: 9222) |
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.
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.
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.
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.
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.
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.
Advanced console search with pattern matching, correlation, and statistics
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | The ID of the tab to search | |
| patterns | No | Pattern matching configuration | |
| correlate | No | Message correlation options | |
| includeStats | No | Include search statistics | |
| namedPatterns | No | Named regex patterns with capture groups |
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.
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.
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.
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.
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.
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.
Search and filter console messages from connected browser tabs
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Filter by console message levels | |
| limit | No | Maximum number of messages to return | |
| regex | No | Treat pattern as regular expression | |
| tabId | Yes | The ID of the tab to search console messages from | |
| pattern | No | Text pattern to search for in console messages |
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.
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.
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.
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.
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.
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.
Launch browser with a localhost URL and automatically connect for debugging
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional path after the port (e.g., "/admin") | / |
| port | Yes | The localhost port to debug (e.g., 3000, 8080) | |
| protocol | No | Protocol to use (default: http) | http |
| debugPort | No | Chrome DevTools debugging port (default: 9222) | |
| executablePath | No | Path to Chrome/Chromium executable (auto-detected if not provided) |
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.
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.
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.
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.
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.
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.
Automatically correlate errors between console and network, find root causes
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | The ID of the tab to analyze | |
| timeWindow | No | Time window in milliseconds for correlation (default: 5000) | |
| minSeverity | No | Minimum severity to include | low |
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.
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.
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.
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.
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.
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.
Intelligently analyze logs to find patterns, anomalies, trends, and suggestions
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | The ID of the tab to analyze | |
| includeAllInsights | No | Include all insights regardless of confidence |
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.
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.
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.
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.
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.
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.
Analyze network requests and responses from connected browser tabs
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of requests to return | |
| tabId | Yes | The ID of the tab to analyze network traffic from | |
| method | No | Filter by HTTP methods | |
| statusCode | No | Filter by specific status codes | |
| urlPattern | No | Regular expression pattern to filter URLs | |
| minDuration | No | Minimum response time in milliseconds | |
| statusRange | No | Filter by status code range |
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.
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.
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.
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.
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.
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.
Export network traffic to HAR (HTTP Archive) format
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | The ID of the tab to export network traffic from | |
| includeResponseBodies | No | Include response body content in HAR (may increase file size) |
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.
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.
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.
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.
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.
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.
Get network performance statistics for a connected browser tab
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | The ID of the tab to analyze |
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.
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.
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.
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.
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.
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.
Advanced performance profiling with bottleneck detection and recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | The ID of the tab to profile | |
| includeWaterfall | No | Include request waterfall visualization | |
| includeRecommendations | No | Include performance recommendations |
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.
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.
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.
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.
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.
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.
Scan for security vulnerabilities in console and network traffic
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | The ID of the tab to scan | |
| includeRecommendations | No | Include detailed recommendations |
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants ā DOM, console, network via MCP.
Give AI coding agents access to your Vynix visual feedback, bug reports, and AI diagnosis.
Shared debugging memory for AI coding agents
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
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
