How do I use Browseagent MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Browseagent MCP go to github.com and take a screenshot" 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.

Browseagent MCP

Official

by browseagent

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Browseagent MCP

npm version License: MIT Node.js Version

✨ Features

🌐 Full Browser Control - Navigate, click, type, and interact with any website
📸 Screenshots & Analysis - Capture and analyze web pages visually
🎯 Smart Element Detection - AI-powered element identification and interaction
🔄 Real-time Automation - Dynamic connection with Chrome extension

Related MCP server: openmcp

🚀 Quick Start

See Documentation

🔒 Security & Privacy

✅ Local Communication - All data stays on your machine
✅ No Data Collection - We don't store or transmit your browsing data
✅ Permission Based - Extension only accesses tabs when explicitly used
✅ Open Source - Full transparency in code and operations

🏗️ Development

Local Development Setup

# Clone the repository
git clone https://github.com/browseagent/mcp.git
cd mcp

# Install dependencies
npm install

# Create global symlink for development
npm link

# Test the server
npm run test

Testing with Claude Desktop (Development)

For local development and testing with Claude Desktop:

# 1. Create global link (one time setup)
npm link

# 2. Configure Claude Desktop to use your local version

Add to your Claude Desktop MCP configuration:

{
  "mcpServers": {
    "browseagent-dev": {
      "command": "npx",
      "args": ["@browseagent/mcp", "--debug"]
    }
  }
}

Development Workflow:

Make changes to your code
Test locally: npm test
Test with Claude Desktop: Restart Claude Desktop to reload the linked package
Iterate and repeat

Alternative: Direct Path Development

For more direct control during development:

{
  "mcpServers": {
    "browseagent-dev": {
      "command": "node",
      "args": ["/absolute/path/to/your/project/src/index.js", "--debug"],
      "cwd": "/absolute/path/to/your/project"
    }
  }
}

Running in Development Mode

# Run with debugging enabled
npm run dev

# Run with WebSocket mode for extension testing
npm run dev -- --websocket

# Run with watch mode for auto-restart during development
npm run dev -- --websocket --debug

🧪 Comprehensive Testing Suite

The project includes a full testing suite to validate all components:

Core Test Commands

# Run full test suite
npm test

# Run all manual tests sequentially
npm run test:all

# Watch mode - auto-run tests on file changes
npm run test:watch

Individual Test Suites

1. Connection Tests (`test:connection`)

npm run test:connection

What it tests:

✅ Server startup and initialization
✅ WebSocket server creation and binding
✅ Extension bridge protocol handshake
✅ Architecture validation (STDIO vs WebSocket separation)
✅ Port conflict resolution
✅ Error handling and timeout scenarios

Use when: Setting up development environment or diagnosing connection issues.

2. Tools Tests (`test:tools`)

npm run test:tools

What it tests:

✅ Tool registry loading and structure validation
✅ Tool argument validation (required/optional fields)
✅ Schema completeness and type checking
✅ Tool categorization (navigation, interaction, utility, inspection)
✅ Input constraint validation (min/max values, patterns)
✅ Error message accuracy for invalid inputs

Use when: Adding new tools or modifying existing tool schemas.

3. Debug Tests (`test:debug`)

npm run test:debug

What it tests:

✅ Bridge ↔ Server communication flow
✅ Extension connection event propagation
✅ Tool call request/response cycle
✅ Mock extension handshake simulation
✅ Event listener setup and cleanup
✅ Status synchronization between components

Use when: Debugging communication issues between bridge and server.

4. Interactive Tool Tests (`test:tool`)

npm run test:tool

What it provides:

🎮 Interactive CLI for manual tool testing
🔧 Real-time tool execution with live extension
📊 Connection status monitoring
🎯 Specific tool argument input and validation
📝 Step-by-step debugging of tool calls

Use when: Manually testing specific tools with real browser extension.

Test Modes

STDIO Mode Testing (Production)

# Test STDIO mode (what Claude Desktop uses)
node src/index.js --debug

# Send test MCP message
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0.0"}}}' | node src/index.js

WebSocket Mode Testing (Development)

# Test WebSocket mode (for extension testing)
node src/index.js --websocket --debug

Advanced Testing Scenarios

Integration Testing

# Test with specific port
npm run test:connection -- --port 9999

# Test with timeout scenarios
npm run test:debug -- --timeout 5000

Development Tools

Linting and Code Quality

# Run ESLint
npm run lint

Debugging Tools

# Verbose logging
npm run dev -- --debug

Development Scripts

# Start in development mode
npm run start

# Start with debugging enabled
npm run dev

# Quick development test
npm run dev -- --websocket --debug

Testing Best Practices

Before Committing

# Run full validation suite
npm run test:all
npm run lint

# Test both modes
node src/index.js --debug  # STDIO mode
node src/index.js --websocket --debug  # WebSocket mode

Continuous Testing During Development

# Watch mode for automatic test runs
npm run test:watch

# Development mode with auto-restart
nodemon src/index.js -- --websocket --debug

Testing with Real Extension

Install Chrome extension
Run interactive tool tester: npm run test:tool
Connect extension via popup
Test specific tools interactively
Verify results in browser

Troubleshooting Development Issues

Common Development Problems

Issue	Test Command	Solution
Extension not connecting	`npm run test:connection`	Check WebSocket port availability
Tool validation failing	`npm run test:tools`	Review tool schema definitions
Bridge communication broken	`npm run test:debug`	Verify event listener setup
Performance issues	`node --inspect src/index.js`	Profile memory/CPU usage

Debug Logging Levels

# Minimal logging
node src/index.js

# Standard debug logging
node src/index.js --debug

# Verbose component logging
DEBUG=* node src/index.js --debug

# Specific component debugging
DEBUG=ExtensionBridge,MCPServer node src/index.js --debug

Building from Source

# Install from source
npm install -g .

# Or run directly
node src/index.js --debug

# Package for distribution
npm pack

🤝 Contributing

We welcome contributions! Here's how to get started:

Fork the repository
Create a feature branch: git checkout -b feature/amazing-feature
Set up development environment: npm install && npm link
Make your changes and test: npm test
Test with Claude Desktop using the development configuration
Commit changes: git commit -m 'Add amazing feature'
Push to branch: git push origin feature/amazing-feature
Open a Pull Request

Development Setup

# Clone your fork
git clone https://github.com/your-username/browseagent-mcp.git
cd browseagent-mcp

# Install dependencies
npm install

# Create development link
npm link

# Install the Chrome extension in development mode
npm run build:extension

# Test your changes
npm test

Development Tools

ESLint: npm run lint
Tests: npm test
Debug mode: npm run dev -- --debug
WebSocket mode: npm run dev -- --websocket

📝 API Reference

MCP Protocol

This server implements the Model Context Protocol specification:

Protocol Version: 2024-11-05
Capabilities: Tools
Transport: stdio

Tool Schemas

All tools follow the MCP tool schema format. See the API documentation for detailed schemas and examples.

🗂️ Project Structure

src/
├── index.js              # Main entry point
├── server/               # MCP server implementation
│   ├── MCPServer.js      # Core MCP protocol handler
│   └── transports/       # Communication transports
├── bridge/               # Chrome extension bridge
│   └── ExtensionBridge.js
├── tools/                # Tool definitions and registry
│   └── ToolRegistry.js
├── utils/                # Utilities and helpers
│   └── Logger.js
├── config/               # Configuration management
|    └── Config.js
└── test/                          
    ├── connection.test.js         # Test connection script
    └── tools.test.js              # Test tools script

📚 Documentation

📖 Tools Reference

🆘 Support

🐛 Bug Reports: GitHub Issues
💬 Discussions: GitHub Discussions
📧 Email: hello@browseagent.pro
🐦 Twitter: @Browseagent

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

Anthropic - For MCP protocol
Chrome Extension API - For enabling secure browser automation
Open Source Community - For tools and inspiration

🐦 Follow updates • 📖 Read docs

Made with ❤️ by the BoostGPT team

Available Tools

12 tools

browser_clickC

Perform click on a web page

ParametersJSON Schema

Name	Required	Description
`ref`	Yes	Exact target element reference from the page snapshot
`tabId`	No	Tab ID (optional, uses active tab if not provided)
`element`	Yes	Human-readable element description used to obtain permission to interact with the element

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only states 'Perform click' without covering potential side effects (e.g., navigation), permission requirements, or how the element reference is resolved. This is a minimal disclosure for an action that can have significant page effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no wasted words, but it is under-specified and essentially restates the tool name. It is concise in length but does not provide useful contextual information, so it does not fully earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description should compensate with operational context. It fails to explain prerequisites (like requiring a snapshot), behavior (clicking may trigger navigation), or how it relates to sibling tools. The schema covers parameter definitions but not usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (ref, tabId, element) are already documented. The description itself adds no extra semantic meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Perform click') and resource ('a web page'), which states the tool's function. However, it does not differentiate from sibling tools like browser_hover or browser_press_key, so it lacks explicit sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description does not mention prerequisites such as obtaining a page snapshot or element reference, nor does it contrast with other interaction tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_drag_dropB

Perform drag and drop between two elements

ParametersJSON Schema

Name	Required	Description
`tabId`	No	Tab ID (optional, uses active tab if not provided)
`sourceRef`	Yes	Source element reference from the page snapshot
`targetRef`	Yes	Target element reference from the page snapshot
`sourceElement`	Yes	Human-readable description of the source element
`targetElement`	Yes	Human-readable description of the target element

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the full burden, but it only states the action without disclosing behavioral traits. It does not mention that drag-drop mutates the page, triggers events, or requires an interactive page state, leaving the agent without critical safety information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler, front-loading the core action. It is appropriately sized for the tool's simplicity and wastes no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and a minimal description, the tool lacks context about behavioral expectations, when to use it, or what the result might be. For a 5-parameter state-changing browser tool, this is insufficient for an agent to safely and confidently invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides complete descriptions for all 5 parameters (100% coverage), including 'from the page snapshot' for sourceRef/targetRef. The description adds no additional parameter semantics beyond implying source and target, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific verb 'drag and drop' and the resource 'two elements', distinguishing it from sibling tools like browser_click and browser_hover. It is unambiguous and immediately conveys the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage from the operation name but provides no explicit guidance about when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent is left to infer context 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.

browser_get_console_logsB

Get the console logs from the browser

ParametersJSON Schema

Name	Required	Description	Default
`tabId`	No	Tab ID (optional, uses active tab if not provided)

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It simply says 'Get the console logs' without revealing whether logs are cleared after retrieval, whether they reflect the active tab or a supplied tab, or what the response format looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no redundant content. It is front-loaded and easy to scan, though it is so brief that it might borderline on under-specification, but this is better captured in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and no annotations, the description should provide more context about return values and behavior. It does not explain what the console logs contain, how they are returned, or whether all logs are preserved. The single sentence is minimally sufficient for a simple getter but leaves significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the tabId parameter including its optionality and default behavior. The description adds no additional meaning about parameters, but since schema coverage is 100%, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (Get), resource (console logs), and context (from the browser). This distinguishes it from sibling tools like browser_navigate or browser_click, which perform different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention common use cases like debugging or checking for errors after a page interaction, nor does it note any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_go_backB

Go back to the previous page

ParametersJSON Schema

Name	Required	Description	Default
`tabId`	No	Tab ID (optional, uses active tab if not provided)

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without mentioning side effects like history consumption, tab-specific behavior, or failure modes when there is no previous page. This is a meaningful gap for a mutation-like navigation action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that immediately conveys the action without any filler. It is front-loaded and wastes zero words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description lacks mention of return values, error conditions, or the relationship to browser history. Given no output schema and no annotations, some additional context—such as what happens if there is no history—would make it complete enough for an agent to use safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the optional tabId parameter, and the description adds no additional semantic meaning beyond the schema. Baseline 3 applies since schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Go back' and resource 'previous page' clearly indicate the action, and the context of browser history distinguishes it from sibling tools like browser_navigate. However, it does not explicitly mention that it uses the browser's history stack, leaving slight ambiguity about what 'previous page' means.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool instead of browser_navigate or browser_go_forward. The description gives no context about prerequisites (e.g., having a history entry) or alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_go_forwardC

Go forward to the next page

ParametersJSON Schema

Name	Required	Description	Default
`tabId`	No	Tab ID (optional, uses active tab if not provided)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states the basic action and does not explain what happens when there is no forward history, whether the navigation waits for page load, or any side effects. This leaves significant behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that immediately communicates the core action. Every word earns its place, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is too sparse to be contextually complete. It does not mention failure modes, preconditions, or behavior when tabId is omitted, even though the schema documents the optional parameter. The tool is simple, but the description lacks needed behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage for the single parameter tabId, including its optionality and default behavior. The description adds no additional semantic meaning beyond the schema, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('go forward') and the resource ('next page'), making the purpose obvious. It distinguishes from browser_go_back by direction, but does not explicitly mention navigation history or contrast with browser_navigate, so it lacks explicit sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like browser_go_back or browser_navigate. The usage is implied solely by the name and description, with no mention of prerequisites, such as requiring a previous backward navigation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_hoverC

Hover over element on page

ParametersJSON Schema

Name	Required	Description
`ref`	Yes	Exact target element reference from the page snapshot
`tabId`	No	Tab ID (optional, uses active tab if not provided)
`element`	Yes	Human-readable element description used to obtain permission to interact with the element

TDQS

C2.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations to contextualize behavior, and the description merely restates the action in near-identical terms to the tool name. It adds no insight into side effects, prerequisites, or what happens during/after the hover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero filler. It is efficient and to the point, though it lacks any additional structure or elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple action with a full schema, the description is minimally sufficient but does not provide any usage context, such as element reference requirements or optional tabId behavior. The lack of annotations and output schema further limits completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides complete descriptions for all three parameters (ref, tabId, element), giving a coverage of 100%. The description adds no extra parameter meaning beyond what the schema already conveys, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'hover' and identifies the target resource ('element'), making it clear what the tool does. This distinguishes it from sibling actions like browser_click, browser_type, and browser_drag_drop.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description only states the action, with no context about typical use cases (e.g., triggering hover menus or preparing for a click) or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_navigateA

Navigate to a URL in a new or existing tab

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to navigate to
`tabId`	No	Existing tab ID (optional)

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the new/existing tab behavior but omits other important details such as whether page load is awaited, what happens if tabId is invalid, or whether the current page is replaced. This is a significant transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that conveys the essential information with zero waste. It is concise and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple navigation tool with fully described parameters, the description is adequate but lacks deeper behavioral context such as load timing or error handling. Without an output schema or annotations, the description is minimally sufficient but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for both parameters (url and tabId), so the description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Navigate') and the resource ('a URL'), and it distinguishes itself from sibling tools like browser_go_back/forward by specifying new or existing tab. It is specific and action-oriented.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for navigating to a URL but does not explicitly state when to use this tool over alternatives, nor does it provide any exclusions or prerequisites. Guidance is inferred rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_press_keyB

Press a key on the keyboard

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Name of the key to press or a character to generate, such as `ArrowLeft` or `a`
`tabId`	No	Tab ID (optional, uses active tab if not provided)

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action without mentioning key release behavior, whether the key press is synthesized or physical, or how it interacts with the browser's event system. This adds minimal value beyond the tool name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no extraneous words. It is front-loaded and immediately clear, making it easy for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the schema covers parameters, the description omits broader context such as when a key press is preferable to typing, potential limitations (e.g., modifier keys), and whether the page must be focused. It leaves important behavioral questions unanswered for a browser automation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: 'key' explains its role (key name or character) and 'tabId' is described as optional. The tool description itself adds no parameter information, but the schema is sufficiently detailed, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Press a key on the keyboard' with a specific verb and resource. It effectively distinguishes from sibling tools like browser_click (mouse action) and browser_type (text entry). The schema further clarifies it handles both special keys and characters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like browser_type. The description does not mention that this is for discrete key presses rather than text input, nor does it specify any prerequisites such as page focus or element state.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_screenshotC

Take a screenshot of the current page

ParametersJSON Schema

Name	Required	Description
`ref`	No	Element reference to screenshot (optional)
`tabId`	No	Tab ID (optional, uses active tab if not provided)
`element`	No	Human-readable element description (optional)
`fullPage`	No	Whether to capture the full page

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It does not state what the screenshot output looks like (e.g., file path, base64), whether it captures only the visible viewport, or any side effects. This leaves agent expectations unexplained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words, making it structurally sound. It is concise but achieves the minimum for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 optional parameters and no output schema, yet the description does not mention return values, what fullPage does, or how element/ref affect the screenshot. It is adequate for a trivial tool but incomplete for one with several options.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds the context of 'the current page' but does not enrich parameter meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Take a screenshot') and the target ('the current page'). However, it does not differentiate this from the sibling tool 'browser_snapshot', which could be confused for the same function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus browser_snapshot or other sibling tools. There is no mention of optional parameters like fullPage or element, nor any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_snapshotA

Capture accessibility snapshot of the current page. Use this for getting references to elements to interact with.

ParametersJSON Schema

Name	Required	Description	Default
`tabId`	No	Tab ID (optional, uses active tab if not provided)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It implies a read-only operation through 'snapshot' and hints at the return value with 'references to elements,' but it does not explicitly state that the page is unmodified, whether references can become stale after navigation, or any prerequisites. This is a minimal but non-misleading disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences with no redundant words. The key action and use case are front-loaded, making it immediately scannable and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description adequately communicates the purpose and how to use the returned references. It does not detail the return format or caveats (e.g., staleness), but these are not critical for an agent to invoke the tool correctly. It is reasonably complete for the tool's low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage for the only parameter (tabId), including its optionality and default behavior. The description adds no additional semantic value about the parameter, so the baseline of 3 is appropriate given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('capture') and resource ('accessibility snapshot of the current page'), and further clarifies its purpose with 'getting references to elements to interact with.' This clearly distinguishes it from sibling tools like browser_screenshot (visual snapshot) and browser_get_console_logs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use it: when you need element references for future interaction. It does not explicitly mention exclusions or alternatives, but the context is strong enough that an agent would understand this is the tool to call before clicking/typing on elements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_typeB

Type text into editable element

ParametersJSON Schema

Name	Required	Description
`ref`	Yes	Exact target element reference from the page snapshot
`text`	Yes	Text to type into the element
`tabId`	No	Tab ID (optional, uses active tab if not provided)
`submit`	No	Whether to submit entered text (press Enter after)
`element`	Yes	Human-readable element description used to obtain permission to interact with the element

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the basic action without mentioning whether text replaces or appends, whether it submits (Enter) or not, whether it requires focus, or any side effects. This leaves the agent with significant unknowns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded, and efficient sentence. It states the core action without unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters and no output schema, and the description is minimal. While the schema covers parameters, the description lacks behavioral context, usage guidance, and any mention of what happens after typing. Given moderate complexity, the description is just adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage, so all parameters (ref, text, element, tabId, submit) are already documented. The description adds no semantics beyond the schema, but since schema coverage is complete, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool's function with a specific verb ('Type') and resource ('text into editable element'). It distinguishes from sibling tools like browser_click and browser_press_key by specifying text input into an editable element.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. The description does not mention exclusions, prerequisites, or alternative tools for different scenarios, leaving usage entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_waitA

Wait for a specified time in seconds

ParametersJSON Schema

Name	Required	Description	Default
`time`	Yes	The time to wait in seconds

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It accurately describes the action but does not disclose any additional behavioral details, such as whether the wait is blocking, whether it can be interrupted, or if it interacts with the browser's internal wait mechanisms. The simplicity of the tool makes this acceptable but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that conveys the essential information without any wasted words. It is concise and perfectly readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter utility with a full schema description and no output, the description is nearly sufficient. It lacks only a brief note on when to use the wait (e.g., after navigation or before snapshot), but overall it provides enough context for basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already contains a complete parameter description ('The time to wait in seconds') with 100% coverage. The tool description adds no extra semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Wait') and the target ('specified time in seconds'). It distinguishes itself from sibling browser tools, which all focus on navigation, interaction, or inspection, making the purpose immediately obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. There is no mention of typical scenarios (e.g., waiting for page loads, network requests, or animations) or any exclusion criteria, leaving the agent to infer usage solely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv1.0.1Aug 9, 2026
- First observedbrowser_click
- First observedbrowser_drag_drop
- First observedbrowser_get_console_logs
- First observedbrowser_go_back
- First observedbrowser_go_forward
- First observedbrowser_hover
- First observedbrowser_navigate
- First observedbrowser_press_key
- First observedbrowser_screenshot
- First observedbrowser_snapshot
- First observedbrowser_type
- First observedbrowser_wait

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-08-09 17:10 across 12 tools

Disambiguation5/5

Each tool targets a distinct browser action: navigation, history, waiting, keyboard, snapshot, mouse actions, typing, console logs, and screenshot. No overlaps between tools.

Naming Consistency5/5

All tools use the 'browser_' prefix followed by snake_case verb-noun patterns (e.g., browser_go_back, browser_press_key, browser_get_console_logs). Consistent and predictable.

Tool Count5/5

12 tools is a well-scoped set for browser automation, covering all essential interactions without unnecessary bloat.

Completeness5/5

Core browser workflows are fully covered: navigation, history, waiting, input, clicks, drag-and-drop, hover, typing, console inspection, and screenshots. No obvious dead ends.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

agent-web-actions
com.trycloudflare.plates-spread-materials-optimum
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Agent Orchestration
2
agent-web-actions
com.trycloudflare.clients-involving-billion-headers
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Web Scraping
2
sncro A
io.github.scottconfusedgorilla
Live browser debugging for AI assistants — DOM, console, network via MCP.
Browser Automation Developer Tools Monitoring
2
scrapeless-mcp-server
io.github.scrapeless-ai
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Browser Automation Web Scraping Search
1169

Related MCP Servers

Rod MCP Server
Browser Automation Web Scraping
aliwatters
A
license
Not graded
quality
B
maintenance
Browser automation for AI agents via the Model Context Protocol, enabling web navigation, form filling, screenshots, and more using Chromium.
Updated 13 days ago (2026-09-10 02:23 UTC)
MIT
openmcp
openmcp-pro
A
license
Not graded
quality
D
maintenance
Enables AI agents to automate web tasks such as browsing, clicking, typing, and taking screenshots via the Model Context Protocol.
Updated 10 months ago (2025-11-13 00:16 UTC)
1
MIT
selenium-mcp
Browser Automation Web Scraping Testing & QA Tools
gaforov
A
license
A
quality
A
maintenance
Enables browser automation through the Model Context Protocol, allowing AI agents to control Chrome, Firefox, or Edge for tasks like navigation, clicking, typing, and screenshots.
Updated 10 days ago (2026-09-13 02:00 UTC)
41
267 npm
MIT
stealthy-auto-browse MCP
Browser Automation Web Scraping
psyb0t
A
license
Not graded
quality
A
maintenance
Enables AI agents to control a stealthy browser via the Model Context Protocol, supporting navigation, screenshots, clicking, typing, and more.
Updated 9 days ago (2026-09-13 04:37 UTC)
78
Do What The F*ck You Want To Public

Browseagent MCP

✨ Features

🚀 Quick Start

🔒 Security & Privacy

🏗️ Development

Local Development Setup

Testing with Claude Desktop (Development)

Alternative: Direct Path Development

Running in Development Mode

🧪 Comprehensive Testing Suite

Core Test Commands

Individual Test Suites

1. Connection Tests (test:connection)

2. Tools Tests (test:tools)

3. Debug Tests (test:debug)

4. Interactive Tool Tests (test:tool)

Test Modes

STDIO Mode Testing (Production)

WebSocket Mode Testing (Development)

Advanced Testing Scenarios

Integration Testing

Development Tools

Linting and Code Quality

Debugging Tools

Development Scripts

Testing Best Practices

Before Committing

Continuous Testing During Development

Testing with Real Extension

Troubleshooting Development Issues

Common Development Problems

Debug Logging Levels

Building from Source

🤝 Contributing

Development Setup

Development Tools

📝 API Reference

MCP Protocol

Tool Schemas

🗂️ Project Structure

📚 Documentation

🆘 Support

📄 License

🙏 Acknowledgments

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. Connection Tests (`test:connection`)

2. Tools Tests (`test:tools`)

3. Debug Tests (`test:debug`)

4. Interactive Tool Tests (`test:tool`)