Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@browser-mcp-server navigate to https://example.com and capture console output"
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 provides browser automation capabilities, specifically for capturing console output from web pages.
browser-console: Navigate to a URL and capture console output from the browser
browser-server-console: Spawn a local Express static server for a directory and capture console output from the served content
Built with Puppeteer for reliable browser automation
Supports custom timeouts and wait conditions
Static file serving for local development and testing
Automatic port detection (finds next available port if requested port is busy)
Related MCP server: MCP Browser Logger
npm installThis server is designed to be used with MCP-compatible clients. Add it to your MCP client configuration:
{
"mcpServers": {
"browser-mcp-server": {
"command": "npx",
"args": ["browser-mcp-server"]
}
}
}You can also run the server directly:
npm startOr in development mode with auto-reload:
npm run devNavigate to a URL and capture console output from the browser.
Parameters:
url (required): The URL to navigate to
timeout (optional): Timeout in milliseconds (default: 30000)
waitFor (optional): CSS selector to wait for before capturing console
commands (optional): Browser commands to execute (e.g., "click .button wait 2s")
stream (optional): Whether to stream output in real-time (default: true)
Commands syntax:
wait <time>: Wait for specified time (e.g., "5s", "1000ms")
click <selector>: Click on element matching CSS selector
Example:
{
"name": "browser-console",
"arguments": {
"url": "https://example.com",
"timeout": 10000,
"waitFor": "#main-content",
"commands": "click .load-more-btn wait 2s click .submit",
"stream": true
}
}Spawn an Express static server for a directory and capture console output from the served content.
Parameters:
directory (required): The directory to serve statically
port (optional): Preferred port to run the server on (will automatically find next available if busy, default: 3000)
path (optional): Path to navigate to after starting server (default: "/")
timeout (optional): Timeout in milliseconds (default: 30000)
waitFor (optional): CSS selector to wait for before capturing console
commands (optional): Browser commands to execute (e.g., "click .button wait 2s")
stream (optional): Whether to stream output in real-time (default: true)
Commands syntax:
wait <time>: Wait for specified time (e.g., "5s", "1000ms")
click <selector>: Click on element matching CSS selector
Example:
{
"name": "browser-server-console",
"arguments": {
"directory": "./public",
"port": 3001,
"path": "/index.html",
"timeout": 10000,
"waitFor": "#app",
"commands": "click #start-btn wait 3s",
"stream": false
}
}Basic MCP server structure
Tool schema definition
Browser navigation with Puppeteer
Console output capture
Real-time console message streaming
Browser command execution (click, wait)
Error handling for browser issues
Support for custom timeouts and wait conditions
True streaming output (currently batched)
Support for different browser types
The main server implementation is in src/index.js. The current implementation includes:
MCP server setup with proper tool registration
Input validation for the browser-console tool
Error handling and graceful shutdown
Placeholder implementation for browser functionality
@modelcontextprotocol/sdk: MCP SDK for server implementation
puppeteer: Browser automation library for console capture
express: Web framework for static file serving
@types/node: TypeScript definitions for Node.js
MIT
Navigate to a URL and capture console output from the browser with streaming support
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to navigate to | |
| stream | No | Whether to stream console output in real-time (default: true) | |
| timeout | No | Timeout in milliseconds (default: 30000) | |
| waitFor | No | CSS selector or text to wait for before capturing console (optional) | |
| commands | No | Browser commands to execute (e.g., "click .button wait 2s") (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions 'streaming support', which is a useful detail, but it omits any side effects (e.g., opening a browser, executing scripts, potential resource usage), prerequisites, or what happens to the browser session. It also does not describe the return format or how streaming terminates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and a key feature. It contains no filler or redundant information, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is too minimal. It does not explain the waitFor or commands parameters, which represent significant behaviors, nor does it clarify what the captured console output looks like. The schema covers parameters but the description fails to provide a complete mental model of the tool's capabilities.
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 all parameters (url, stream, timeout, waitFor, commands) have descriptive schema definitions. The tool description adds nothing beyond the schema—'streaming support' repeats the stream parameter's purpose. Therefore, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool navigates to a URL and captures console output from the browser, with streaming support. This specific verb+resource combination ('navigate' + 'capture console output') and the qualifier 'from the browser' distinguishes it from the sibling tool 'browser-server-console', which likely targets a server-side console.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing browser console output after navigation, but it does not explicitly state when to use this tool versus alternatives, mention exclusions, or provide use-case context (e.g., debugging front-end errors). The presence of a sibling tool suggests a potential distinction but it is not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Spawn an Express static server for a directory and capture console output from the served content
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to navigate to after starting server (default: "/") | / |
| port | No | Preferred port to run the server on (will find next available if busy, default: 3000) | |
| stream | No | Whether to stream console output in real-time (default: true) | |
| timeout | No | Timeout in milliseconds (default: 30000) | |
| waitFor | No | CSS selector or text to wait for before capturing console (optional) | |
| commands | No | Browser commands to execute (e.g., "click .button wait 2s") (optional) | |
| directory | Yes | The directory to serve statically |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It states what the tool does (spawns a server, captures console) but does not disclose side effects such as server lifecycle/cleanup, blocking behavior, rate limits, or what happens to existing servers. This is a significant gap for a tool that starts a server.
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, efficient sentence that immediately conveys the core purpose and actions. It contains no fluff or redundant phrasing, and every word contributes meaning.
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 seven parameters and the absence of annotations and an output schema, the description is relatively minimal. It does not explain what the tool returns, how console output is delivered, or whether the server is automatically stopped. The parameter schema covers the 'how' but the overall usage context remains 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?
Schema description coverage is 100%, so the schema fully documents all seven parameters including defaults and semantics. The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Spawn') and resource ('Express static server') and clearly states the second function ('capture console output'). This distinguishes it from the sibling tool 'browser-console', which likely focuses only on console capture without serving a directory.
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 does not explicitly state when to use this tool versus the sibling tool 'browser-console'. It implies usage for serving static content and capturing console output, but there are no exclusions or alternative recommendations, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools share a common goal of capturing console output but are clearly differentiated by their input: one navigates to an existing URL, the other serves a directory first. The descriptions make this distinction obvious, though the similar 'browser-console' phrasing could cause slight hesitation.
Both tools follow the 'browser-<noun>' pattern with hyphens and end in 'console'. The second tool inserts 'server' to indicate the serving step, which is a minor deviation but still predictable and consistent in style.
With only two tools, the server feels minimal but appropriately scoped for its narrow focus on console capture. This is borderline, as two tools may be thin for a general-purpose browser server, but the purpose is specific enough to warrant a small set.
The tool set covers the two primary ways to obtain browser console output: from an arbitrary URL and from locally served content. Minor gaps exist, such as no way to interact with the page or manage a long-running server, but the core workflows are well covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server to assist with JxBrowser development.
Live browser debugging for AI assistants — DOM, console, network via MCP.
A paid remote MCP for AI agent browser DevTools MCP, built to return verdicts, receipts, usage logs,
A paid remote MCP for AI agent browser MCP session, built to return verdicts, receipts, usage logs,
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/stagas/browser-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
