Click on "Deploy 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., "@unified-browser-mcp Go to example.com and show me the network logs"
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 combines Playwright browser automation with DevTools-style monitoring capabilities in a single browser instance.
Browser Automation: Navigate, fill forms, click elements, take screenshots
Network Monitoring: Capture all network requests with full headers and response bodies
Console Logging: Monitor all console messages (log, warning, error, info)
Performance Metrics: Extract Navigation Timing API data
Single Browser Instance: All operations work on the same browser/page for consistency
Related MCP server: Playwright MCP Server
The Model Context Protocol (MCP) allows AI assistants like Claude to interact with external tools and services. This MCP server acts as a bridge between Claude and browser automation capabilities, running automatically in the background whenever you use Claude Desktop or Cursor.
Key Points:
🔄 Automatic Startup: The server launches automatically when you open Cursor/Claude Desktop
🔌 No Manual Running: You never need to manually start the server
🛠️ Tool Provider: Makes browser automation tools available to Claude
💬 Communication: Uses JSON-RPC over stdio to talk to Claude
Before installing, ensure you have:
Node.js (v18 or higher) - Download here
Cursor or Claude Desktop - Download Cursor
This is the simplest method - no cloning, no building, just one config update!
Simply add this to your MCP configuration file and restart Cursor:
{
"mcpServers": {
"unified-browser": {
"command": "npx",
"args": ["-y", "unified-browser-mcp"]
}
}
}That's it! The server will be automatically downloaded and run when Cursor starts.
Note: You'll still need to install Playwright browsers once:
npx playwright install chromiumIf you prefer to build from source or want to modify the code:
Step 1: Get the Code
Choose one of these methods:
Option A: Clone from GitHub
git clone https://github.com/msawayda/unified-browser-mcp.git
cd unified-browser-mcpOption B: Download ZIP
Click "Code" → "Download ZIP"
Extract to your preferred location
Open terminal/command prompt in that folder
Step 2: Install Dependencies
npm installThis will install:
@modelcontextprotocol/sdk - MCP communication layer
playwright - Browser automation library
TypeScript and build tools
Expected output:
added 19 packages, and audited 20 packages in 25s
found 0 vulnerabilitiesStep 3: Build the Server
npm run buildThis compiles the TypeScript code to JavaScript in the build/ directory.
Expected output:
> unified-browser-mcp@1.0.0 build
> tscYou should now see a build/ folder with index.js inside.
Step 4: Install Playwright Browsers
npx playwright install chromiumThis downloads the Chromium browser (~150 MB) that Playwright will use.
Expected output:
Downloading Chromium 141.0.7390.37...
Chromium downloaded to C:\Users\[username]\AppData\Local\ms-playwright\chromium-1194Note: This only needs to be done once per machine.
The MCP configuration file location depends on your operating system:
OS | Configuration File Path |
Windows |
|
macOS |
|
Linux |
|
For Claude Desktop (instead of Cursor):
Windows: C:\Users\[username]\AppData\Roaming\Claude\mcp.json
macOS: ~/Library/Application Support/Claude/mcp.json
Linux: ~/.config/Claude/mcp.json
Open the config file in a text editor (create it if it doesn't exist)
Add your server to the mcpServers object:
All Operating Systems:
{
"mcpServers": {
"unified-browser": {
"command": "npx",
"args": ["-y", "unified-browser-mcp"]
}
}
}Simple! Same config works on Windows, macOS, and Linux.
Windows Example:
{
"mcpServers": {
"unified-browser": {
"command": "node",
"args": [
"C:\\Users\\YourUsername\\unified-browser-mcp\\build\\index.js"
]
}
}
}macOS/Linux Example:
{
"mcpServers": {
"unified-browser": {
"command": "node",
"args": [
"/Users/yourusername/unified-browser-mcp/build/index.js"
]
}
}
}Important Notes:
✅ Use absolute paths (full path from root)
✅ On Windows, use double backslashes (\\) or forward slashes (/)
✅ Replace YourUsername with your actual username
✅ Match the path to where you installed the server
If you already have other MCP servers, add a comma after the previous entry:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
},
"unified-browser": {
"command": "npx",
"args": ["-y", "unified-browser-mcp"]
}
}
}Important: You must completely restart the application for MCP servers to load.
Close Cursor/Claude Desktop completely (not just the window)
Reopen the application
The MCP server will now start automatically in the background
When you start Cursor/Claude Desktop:
Cursor reads your mcp.json configuration
Launches the server by running: node path/to/build/index.js
Establishes communication via stdio (standard input/output)
Keeps it running in the background throughout your session
Shuts it down automatically when you close Cursor
You'll see this in the server logs (stderr):
Unified Browser MCP server running on stdioOnce configured and Cursor is restarted:
Start a conversation with Claude in Cursor
The tools are automatically available - Claude can now use browser automation commands
Request browser actions like:
"Launch a browser and navigate to example.com"
"Fill out this form and monitor the network requests"
"Take a screenshot of the current page"
Claude will execute using the MCP tools behind the scenes
You never need to manually start or stop the server!
After restarting Cursor, you can verify the server is working:
Start a new chat with Claude
Ask: "What MCP tools do you have available?"
Look for: Tools like launch_browser, navigate, start_monitoring, etc.
If you see these tools, the server is running correctly! ✅
Problem: Dependencies not installed
Solution:
cd unified-browser-mcp
npm installProblem: TypeScript not compiled
Solution:
npm run buildProblem: Chromium not downloaded
Solution:
npx playwright install chromiumPossible causes:
Wrong path in mcp.json - Double-check the absolute path
Didn't restart Cursor - Must fully restart, not just reload window
JSON syntax error - Validate your JSON at https://jsonlint.com/
Wrong file location - Config must be in the correct OS-specific location
Debug steps:
Check Cursor's developer console (Help → Toggle Developer Tools)
Look for MCP-related errors
Verify the path exists: node C:\path\to\build\index.js should output the server message
To update the server after pulling new changes:
cd unified-browser-mcp
git pull origin main # If using git
npm install # Install any new dependencies
npm run build # RebuildThen restart Cursor/Claude Desktop.
launch_browserLaunch a new Chromium browser instance.
Parameters:
headless (boolean, optional): Run in headless mode (default: false)
viewport (object, optional): Set viewport size
width (number): Viewport width (default: 1280)
height (number): Viewport height (default: 720)
close_browserClose the browser and cleanup all resources.
navigateNavigate to a URL.
Parameters:
url (string, required): URL to navigate to
waitUntil (string, optional): When to consider navigation complete
Options: load, domcontentloaded, networkidle
Default: load
fill_form_fieldFill a form field with a value.
Parameters:
selector (string, required): CSS selector for the form field
value (string, required): Value to fill
click_elementClick an element on the page.
Parameters:
selector (string, required): CSS selector for the element
waitForNavigation (boolean, optional): Wait for navigation after click (default: false)
submit_formSubmit a form by clicking a submit button or form element.
Parameters:
selector (string, required): CSS selector for the submit button or form
screenshotTake a screenshot of the page or a specific element.
Parameters:
fullPage (boolean, optional): Capture full scrollable page (default: false)
selector (string, optional): CSS selector to screenshot specific element
evaluate_scriptExecute JavaScript code in the page context.
Parameters:
script (string, required): JavaScript code to execute
start_monitoringStart capturing network requests and console messages.
Parameters:
clearPrevious (boolean, optional): Clear previously captured data (default: true)
get_network_requestsGet all captured network requests with full details.
Parameters:
filter (string, optional): Filter requests by URL pattern
Returns: Array of network requests with:
URL, method, timestamp
Request headers and POST data
Response status, headers, and body (text/JSON only)
get_console_messagesGet all captured console messages.
Parameters:
type (string, optional): Filter by message type
Options: log, warning, error, info, all
Default: all
get_performance_metricsGet page performance metrics from the Navigation Timing API.
Returns: Performance timing data including:
DOM content loaded time
Load complete time
DOM interactive time
DNS, TCP, request, and response times
stop_monitoringStop monitoring and return a summary of captured data.
Returns: Summary with total counts and breakdowns by status/type
Here's a typical workflow for automating a form submission while monitoring network activity:
1. launch_browser
- headless: false
2. navigate
- url: "https://example.com/contact"
3. start_monitoring
- clearPrevious: true
4. fill_form_field
- selector: "#name"
- value: "John Doe"
5. fill_form_field
- selector: "#email"
- value: "john@example.com"
6. submit_form
- selector: "#submit"
7. get_network_requests
- filter: "api"
8. get_console_messages
- type: "error"
9. get_performance_metrics
10. close_browserAutomate form submissions while capturing all API calls, XHR requests, and responses.
Navigate to pages and collect detailed performance metrics including timing data.
Monitor console errors and network failures during automated interactions.
Verify that forms trigger the correct API calls with proper payloads and responses.
Browser Engine: Chromium (via Playwright)
Communication: JSON-RPC over stdio (MCP standard)
Network Capture: Full request/response cycle with headers and bodies
Console Capture: All message types with timestamps and locations
Single Instance: One browser/context/page shared across all operations
Ensure Playwright browsers are installed: npx playwright install chromium
Check that Node.js is in your PATH
Always call launch_browser before other operations
If browser crashes, call launch_browser again
Call start_monitoring before navigation/interactions
Network capture begins after start_monitoring is called
Only text and JSON responses are captured (binary data is skipped)
Some responses may not be available if the request hasn't completed
To rebuild after making changes:
npm run buildThe TypeScript compiler will output to the build/ directory.
MIT
Click an element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the element | |
| waitForNavigation | No | Wait for navigation after click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the click triggers navigation, waits for elements, or has side effects. The waitForNavigation parameter in the schema hints at navigation behavior, but the description does not mention it.
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 very short and to the point, but sacrifices useful context for brevity. It is front-loaded but not sufficiently informative for an agent.
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 sibling tools and no output schema, the description is too minimal. It does not explain how this tool relates to other browser interaction tools, nor does it cover return values or side effects.
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 baseline is 3. The description adds no meaning beyond the schema; it simply states 'Click an element' without elaborating on parameters.
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 'Click an element' is clear and specific about the action, but does not distinguish from sibling tools like submit_form which also involves clicking. The verb-resource pairing is direct.
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 on when to use this tool versus alternatives like submit_form or fill_form_field. The description lacks any usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the browser and cleanup
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The term 'cleanup' is vague and lacks detail on what exactly is cleaned up (e.g., cookies, cache, processes). With no annotations, the description should disclose side effects or confirmation requirements, which it fails to do.
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 with no extraneous information. It is front-loaded and to the point, but lacks structure that might improve readability.
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 output schema, the description should explain what happens upon execution (e.g., return value, state changes). It does not mention whether the browser closes silently or prompts, nor does it address error handling.
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?
Tool has zero parameters, so schema coverage is 100%. The description adds no information about parameters, but none is needed. 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 explicitly states 'Close the browser and cleanup', clearly indicating the tool's purpose of terminating the browser session. It distinguishes from sibling tools like launch_browser and navigate.
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. There is no mention of prerequisites, such as needing a browser to be open, or when cleanup is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the page context
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks disclosure of execution behavior: synchronous vs. async, return value handling, side effects, or sandbox restrictions. With no annotations, the description carries full burden but falls short.
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?
Single sentence, front-loaded with key verb and context, no extraneous words.
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 one-parameter tool with no output schema, the description is minimally adequate but misses behavioral context that would help an agent anticipate effects and return values.
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 coverage is 100%, and the description adds no additional meaning beyond the schema's 'JavaScript code to execute'. 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 action 'Execute JavaScript' and the context 'in the page context', distinguishing it from sibling tools like click_element or navigate.
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 on when to use this tool versus alternatives (e.g., for DOM manipulation vs. click_element), nor any prerequisites like page load.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill a form field with a value
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Value to fill | |
| selector | Yes | CSS selector for the form field |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose side effects and behavior. It only says 'fill', omitting details such as whether it triggers events, overwrites existing values, or handles disabled fields. An agent cannot predict the tool's full impact.
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 with no wasted words. However, it could be restructured to front-load more critical information or be expanded slightly without losing 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 simplicity and lack of output schema/annotations, the description should cover return behavior and constraints. It does not mention return status, error conditions, or support for different input types, leaving the agent with significant unknowns.
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 both parameters (selector and value). The description adds no additional meaning beyond what is in the schema. Baseline of 3 is appropriate as it does not detract but does not enhance 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 verb (fill) and resource (form field), and implies the tool is for entering values into form inputs. It distinguishes from siblings like click_element and submit_form by specifying a different action. However, it could be more specific about the mechanism (e.g., typing vs setting value via JavaScript).
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. It does not mention prerequisites (e.g., element must be visible) or when not to use it (e.g., for non-input elements). Sibling tools like click_element are not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all captured console messages
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'Get all captured console messages' but does not reveal whether messages are cleared after retrieval, if filtering is applied, or any side effects. 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 sentence, which is concise, but it omits critical information such as parameter details, behavior, and usage context. The brevity comes at the cost of completeness.
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 presence of one enumerative parameter, lack of output schema, and no annotations, the description fails to provide essential context about what console messages are, when they are captured, or the expected return format. It is highly incomplete.
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 lone parameter 'type' is not mentioned in the description. Schema description coverage is 0%, so the description should compensate but does not explain the parameter's purpose, usage, or impact.
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 the verb 'Get' and resource 'console messages', clarifying the action. However, it lacks specificity about what 'captured' means and does not differentiate from sibling retrieval tools like 'get_network_requests' or 'get_performance_metrics'.
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. There is no discussion of prerequisites, context, or exclusions, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all captured network requests with full headers and bodies
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Filter requests by URL pattern (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description does not disclose behavioral traits like read-only nature, reliance on prior monitoring, or limits (e.g., data retention). It only states what is retrieved.
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?
Single sentence, no extraneous words, immediately conveys 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?
With no output schema, the description gives some idea of return (full headers and bodies) but lacks details on structure, pagination, or behavior when no requests captured. Adequate for a simple tool but not fully spec-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?
Description does not add value beyond the input schema; the schema already defines 'filter' with its description. Baseline 3 is appropriate since schema coverage is 100%.
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 ('Get') and resource ('captured network requests with full headers and bodies'), clearly distinguishing it from sibling tools like get_console_messages or get_performance_metrics.
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 vs. alternatives, such as prerequisites like prior start_monitoring or that results are snapshots of captured data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get page performance metrics from Navigation Timing API
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states it gets metrics from the Navigation Timing API but does not disclose whether it is read-only, side effects, or if metrics are cleared after retrieval. Minimal 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?
Single sentence with no wasted words. Adequately concise for a simple tool, though it could be slightly more descriptive.
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 parameters, no output schema, and no annotations, the description is minimally complete. It could mention that the tool returns performance data or requires a page to be loaded, but overall sufficient for its simplicity.
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?
No parameters exist, and schema coverage is 100%. The description does not need to add parameter details. Baseline 4 for zero parameters.
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 retrieves page performance metrics from the Navigation Timing API. The verb 'Get' and specific resource 'page performance metrics' are precise. No sibling tool has a similar purpose.
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 on when to use this tool vs alternatives, such as after page load or before taking screenshots. The description does not mention prerequisites or typical use cases.
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 DevTools monitoring enabled
| Name | Required | Description | Default |
|---|---|---|---|
| headless | No | Run browser in headless mode | |
| viewport | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions DevTools monitoring but ambiguously implies it's enabled automatically, conflicting with separate start_monitoring tool. No disclosure about state changes, cleanup requirements, or potential 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, front-loaded sentence with no wasted words. It is concise but under-specified, lacking necessary detail for effective use.
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 (nested parameters, no output schema, multiple siblings) and lack of annotations, the description is incomplete. It does not address prerequisites, return values, or sequencing with other tools.
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 50% (only headless has a description). The tool description adds no details about parameters, failing to compensate for the undocumented viewport parameter. It does not explain how parameters affect behavior.
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 new browser instance with DevTools monitoring enabled, using a specific verb and resource. It distinguishes from sibling tools like navigate and close_browser.
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 on when to use this tool versus alternatives. For example, it does not mention whether it must be called before other browser operations or how it relates to monitoring tools like start_monitoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page
| Name | Required | Description | Default |
|---|---|---|---|
| fullPage | No | Capture full page | |
| selector | No | CSS selector to screenshot specific element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the basic action but omits details such as whether the tool waits for page load, its read-only nature, or return format. This lack of behavioral context is a significant gap.
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 extremely concise at one sentence, but it may be too brief given the missing context. Still, it earns a 4 for efficiency.
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 and lack of output schema, the description still fails to mention the return value or clarify what 'current page' means if the page is not fully loaded. More context is needed for complete understanding.
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 parameters are already described in the input schema. The tool description adds no additional meaning beyond what the schema 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 verb 'Take a screenshot' and the resource 'current page', making the tool's purpose obvious. It is distinct from sibling tools which involve other browser actions.
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 the tool (when a visual capture is needed), but provides no explicit guidance on when not to use it or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start capturing network requests, console messages, and other DevTools data
| Name | Required | Description | Default |
|---|---|---|---|
| clearPrevious | No | Clear previously captured data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not mention that starting monitoring may overwrite previous data (despite a clearPrevious parameter), impact performance, or require a browser to be open. The description is too vague.
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 with no unnecessary words. It is concise and front-loaded with the main action.
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 that initiates a monitoring session, the description lacks important context: it does not mention that get_console_messages, get_network_requests, etc., can be used after starting, nor that stop_monitoring is the counterpart. Without an output schema, more behavioral detail is needed.
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 with a clear description for the clearPrevious parameter. The tool description adds no additional meaning beyond the schema, so 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 starts capturing network requests, console messages, and other DevTools data, distinguishing it from retrieval tools like get_console_messages and get_network_requests. However, it could be more explicit about initiating a monitoring session.
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 on when to use this tool versus alternatives. It is implied that monitoring must be started before using get_* tools and stopped with stop_monitoring, but the description does not provide this context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop monitoring and return summary
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'return summary' but provides no detail on what the summary contains, whether monitoring data is cleared, or if the tool modifies state. This is particularly insufficient for a tool that stops an ongoing process.
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 extremely concise at 5 words, with no unnecessary text. It immediately conveys the core action and output, making it efficient for quick parsing.
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 output schema or annotations, the description is too minimal. It does not explain what the summary consists of, how it is structured, or whether the tool is destructive. Agents need more context to use this tool effectively in a sequence.
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?
There are no parameters, so the schema coverage is 100%. The description adds value by clarifying that the tool returns a summary, which is not evident from the empty schema. This is a meaningful semantic addition.
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 action ('stop monitoring') and the output ('return summary'). It effectively distinguishes from siblings like 'start_monitoring' by using the opposite verb.
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 on when to use this tool versus alternatives like 'get_performance_metrics' or 'get_console_messages'. It does not specify prerequisites (e.g., that monitoring must be active) or post-conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a form
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the form or submit button |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lacks details on whether the tool waits for navigation, what happens on invalid selectors, or if it returns a confirmation.
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?
Single sentence is concise but overly minimal. While not verbose, it misses opportunities to add value without becoming long.
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 and no output schema, the description is insufficient. For a tool that likely triggers navigation or state changes, more behavioral details are needed.
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 coverage is 100% (one parameter with description). The tool description adds no extra meaning beyond the schema, so 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?
Description clearly states the tool submits a form, distinguishing it from sibling tools like click_element and fill_form_field. However, it lacks specificity about the submission method (e.g., clicking a button vs programmatic submit).
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 on when to use this tool vs alternatives. For example, it doesn't mention prerequisites like filling form fields or handling redirects, which would help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0click_elementclose_browserevaluate_scriptfill_form_fieldget_console_messagesget_network_requestsget_performance_metricslaunch_browsernavigatescreenshotstart_monitoringstop_monitoringsubmit_formScored across 13 tools
Each tool targets a distinct action or data source: browser lifecycle (launch/close), navigation, interaction (click/fill/submit/script), monitoring (console/network/performance), and screenshot. No overlapping purposes.
All tool names follow a consistent snake_case verb_noun pattern (e.g., click_element, get_console_messages, launch_browser), making the set predictable and easy to understand.
13 tools cover the essential operations for browser automation without being excessive. Each tool serves a clear role, and the count feels well-scoped for the domain.
Core workflows (navigate, interact, monitor, screenshot) are covered. Minor gaps exist, such as no direct tool for getting page source or managing cookies, but evaluate_script can compensate.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Live browser debugging for AI assistants — DOM, console, network via MCP.
A Model Context Protocol server for Wix AI tools
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
