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., "@SmartBrowserMCP Open example.com and show me the page content."
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 web automation capabilities through browser control tools.
SmartBrowserMCP is a TypeScript/Node.js server that implements the Model Context Protocol to expose browser automation functionality. It uses Playwright for browser management and provides tools for web testing, monitoring, and automation tasks.
Related MCP server: Puppeteer MCP Server
Browser Automation: Control web browsers programmatically
Element Interaction: Click elements by CSS selector, text content, or link text
Content Extraction: Extract text and HTML content from pages or specific elements
Page Navigation: Scroll pages and navigate web content
Console Monitoring: Check browser console logs and errors
Network Monitoring: Monitor network requests and responses
Screenshot Capture: Take screenshots of web pages
Task Execution: Execute custom automation tasks
Report Generation: Generate detailed reports of browser sessions
Session Management: Clear and manage browser sessions
npm installNode.js (v18 or higher)
npm or yarn
Clone the repository
Install dependencies:
npm installCreate a .env file (optional):
MCP_SERVER_PORT=3000
MCP_SERVER_HOST=0.0.0.0
MCP_TRANSPORT=stdio
BROWSER_HEADLESS=true
BROWSER_SLOW_MO=0
BROWSER_TIMEOUT=30000
LOG_LEVEL=infonpm run buildDevelopment mode:
npm run devProduction mode:
npm run build
npm startThe server supports two transport modes controlled by the MCP_TRANSPORT environment variable:
For MCP clients like Claude Desktop, Cursor, and other MCP-compatible applications.
Run in STDIO mode:
# Default mode (no env var needed)
npm run build
npm start
# Explicit STDIO mode
MCP_TRANSPORT=stdioFor direct API usage and web-based integration.
Run in HTTP mode:
MCP_TRANSPORT=httpUsing npm link (global command):
npm link
smartbrowser-mcpMCP Client Configuration:
For Claude Desktop, add to your MCP config:
{
"mcpServers": {
"smartbrowser": {
"command": "npx",
"args": [
"smartbrowsermcp@latest"
],
"env": {
"MCP_TRANSPORT": "stdio",
"BROWSER_HEADLESS": "true"
}
}
}
}Visible Browser Mode:
To see the browser automation in real-time, set BROWSER_HEADLESS to false:
{
"mcpServers": {
"smartbrowser": {
"command": "npx",
"args": [
"smartbrowsermcp@latest"
],
"env": {
"MCP_TRANSPORT": "stdio",
"BROWSER_HEADLESS": "false"
}
}
}
}Or using local path:
{
"mcpServers": {
"smartbrowser": {
"command": "node",
"args": ["/var/www/html/LMStudio/WebPilotMCP/dist/index.js"],
"env": {
"MCP_TRANSPORT": "stdio",
"BROWSER_HEADLESS": "false"
}
}
}
}Mode Differences:
HTTP Mode: For direct API usage and testing. Server runs on configured port (default: 3000)
STDIO Mode: For MCP clients. Communicates via stdin/stdout using JSON-RPC protocol
Headless Mode (default): Browser runs in background, not visible to user
Visible Mode (BROWSER_HEADLESS=false): Browser window opens, users can watch automation
The server provides the following MCP tools:
executeTask: Execute custom automation tasks
checkConsole: Monitor browser console for logs and errors
checkNetwork: Monitor network activity
takeScreenshot: Capture screenshots of web pages
generateReport: Generate detailed session reports
clearSession: Clear browser session data
click_element: Click elements by CSS selector, text content, or link text
get_page_content: Extract text and HTML content from pages or specific elements
scrollPage: Scroll pages up/down or to specific positions
GET /api/mcp: MCP server endpoint (SSE transport)
POST /api/mcp: MCP message handling endpoint
GET /: Server information endpoint
GET /health: Health check endpoint
The server can be configured via environment variables:
MCP_SERVER_PORT: Server port (default: 3000)
MCP_SERVER_HOST: Server host (default: 0.0.0.0)
MCP_TRANSPORT: Transport mode - stdio or http (default: stdio)
BROWSER_HEADLESS: Run browser in headless mode (default: true)
BROWSER_SLOW_MO: Slow down operations by specified milliseconds (default: 0)
BROWSER_TIMEOUT: Browser operation timeout in milliseconds (default: 30000)
LOG_LEVEL: Logging level (default: info)
PLAYWRIGHT_BROWSERS_PATH: Custom path to Playwright browsers
src/
├── config/
│ └── server.ts # Server configuration
├── services/
│ ├── browserManager.ts # Browser instance management
│ └── inputSanitizer.ts # Input sanitization utilities
├── tools/
│ ├── checkConsole.ts # Console monitoring tool
│ ├── checkNetwork.ts # Network monitoring tool
│ ├── clearSession.ts # Session management tool
│ ├── clickElement.ts # Element interaction tool
│ ├── executeTask.ts # Custom task execution
│ ├── generateReport.ts # Report generation tool
│ ├── getPageContent.ts # Content extraction tool
│ ├── scrollPage.ts # Page scrolling tool
│ └── takeScreenshot.ts # Screenshot capture tool
├── types/
│ ├── index.ts # Type definitions
│ └── schemas.ts # Zod schemas for validation
└── index.ts # Main server entry point@modelcontextprotocol/sdk: MCP SDK for server implementation
@modelcontextprotocol/server: MCP server utilities
playwright: Browser automation
express: Web server framework
zod: Schema validation
dotenv: Environment variable management
sanitize-html: HTML sanitization for security
ISC
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
For issues and questions, please use the project's issue tracker.
Get filtered console messages by level
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It implies a read operation ('Get'), but does not explicitly state read-only nature, or any potential side effects, permissions, or rate limits. Adequate for a simple retrieval but could be more explicit.
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. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description is minimal. It explains what the tool does but does not describe the return value shape. Could mention that it returns filtered console messages.
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%, so baseline is 3. The description adds meaning for the 'level' parameter by mentioning filtering, but does not describe the 'limit' parameter. The schema itself documents the parameters sufficiently.
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 'Get', the resource 'console messages', and the filtering criterion 'by level'. It distinguishes itself from sibling tools like check_network or clear_session, which deal with different functionalities.
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. There is no mention of prerequisites, context, or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor filtered network requests
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. Only states 'monitor', which implies read-only but does not confirm side effects, permissions, or what happens when monitoring starts/stops.
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 efficient and front-loaded with the core action. However, it could include brief context without becoming verbose.
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?
Description lacks context on return format, expected behavior, or practical usage. For a tool with 3 parameters and no output schema, more detail is needed for correct agent invocation.
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%, meaning parameters are defined in schema. Description adds no additional meaning to parameters; it only hints at filtering but doesn't explain urlPattern, method, or limit beyond schema.
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 monitors filtered network requests. It is specific enough to distinguish from sibling tools like check_console, which monitors console messages.
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. Does not mention prerequisites, limitations, or context where it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean up all browser data securely
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions 'securely' but doesn't elaborate on destructive nature or side effects like logging out user. No annotations to compensate.
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 fluff, but could be enriched with context without being verbose.
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?
Sufficient for a simple cleanup tool with two boolean parameters, but lacks details on return value or confirmation of action.
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 parameters are already well-defined. Description adds no extra meaning beyond the schema.
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 it cleans up all browser data, which distinguishes it from sibling tools that check, execute, or capture information. The verb-resource pair is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives, but implied context of clearing session data vs. checking or extracting. Lack of when-not or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute any task on a website using natural language instructions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It fails to disclose whether the tool modifies website state, requires user interaction, has destructive potential, or any other behavioral traits. 'Execute any task' implies action but gives no safety or side-effect information.
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 (one sentence), which is concise, but it lacks structure and essential details. Every word is used, but the information density is low, making it less helpful than a slightly longer, more organized description.
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 complexity (multiple optional parameters, no output schema, and several sibling tools), the description is insufficient. It does not explain how the tool processes instructions, what it returns, or how timeout and url interact. Agent guidance is minimal.
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?
Although schema coverage is 100%, the schema provides only types and constraints without descriptions. The tool description adds no parameter explanations, leaving ambiguity between the two string parameters ('instructions' and 'instruction'). The url and timeout parameters are not clarified at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: executing tasks on a website using natural language. The verb 'execute' is specific, and 'any task' indicates broad capability. However, it doesn't distinguish from sibling tools like get_page_content or take_screenshot, which are more specialized.
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 its siblings. The description only says 'execute any task', leaving it unclear whether specific actions like checking console or network are better handled by other tools. There are no prerequisites or examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create execution summary with metrics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavior. It only says 'create summary' but does not explain side effects, output format, or whether it modifies state. Missing crucial information for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, but it is too brief. Could benefit from a second sentence describing output or parameters.
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?
No output schema, so description should hint at return value. It does not. With 3 parameters and no parameter descriptions, the tool is underspecified for correct invocation.
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 has 3 boolean parameters with defaults, but no descriptions in schema. Description does not mention parameters at all. Agent cannot learn what includeScreenshot, includeConsole, includeNetwork control from description alone.
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 states 'Create execution summary with metrics,' which is a clear verb+resource. It distinguishes from sibling tools like check_console and take_screenshot by implying aggregation, but does not explicitly differentiate.
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 or not use this tool vs alternatives. The description does not mention prerequisites or context. Implied usage is after execution, but no explicit criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract text content from the page or a specific element. Returns readable text content for verification and analysis.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'Returns readable text content for verification and analysis.' Does not disclose details like handling of hidden content, dynamic elements, or error conditions.
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 purpose, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of return value format, behavior when selector not found, or impact of includeHtml. Adequate for simple use but incomplete for ambiguous cases.
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%; description adds context for 'selector' (specific element) but does not explain 'includeHtml'. Baseline 3 with marginal added value.
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 verb (extract), resource (text content), and distinguishes between full page and specific element via selector. Siblings like take_screenshot differ markedly.
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?
Implies use for verification and analysis but provides no explicit when-to-use or when-not-to-use guidance, nor references to alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture screenshot with viewport options
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavioral traits. It mentions 'viewport options' but doesn't explain that it captures the current browser viewport, or how parameters like fullPage affect behavior. Minimal disclosure beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single short phrase, very concise. Could be considered too minimal, but it serves the purpose without extra fluff. Front-loading is good. No wasted 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?
Despite high schema coverage, the tool has 4 parameters and no output schema. The description does not explain return value or file handling (e.g., where screenshots are saved). Given lack of annotations, more context is needed for completeness.
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 baseline is 3. The description adds 'with viewport options', but the schema already documents each parameter. The description does not provide additional meaning beyond the schema, so it remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Capture screenshot' which clearly identifies the action and resource. Mentions 'viewport options', providing some scope, but doesn't distinguish from sibling tools like get_page_content that captures page content. Still, purpose is clear.
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_page_content or check_console. No mention of prerequisites or when not to use. This leaves the agent without context for selection.
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. Dates show when Glama detected each change.
v1.0.3check_consolecheck_networkclear_sessionexecute_taskgenerate_reportget_page_contenttake_screenshotEach tool targets a distinct browser function: console messages, network requests, session cleanup, task execution, report generation, page content extraction, and screenshots. No overlap in purpose.
All tool names follow a consistent verb_noun pattern with underscores (check_console, clear_session, execute_task, etc.). No mixing of styles.
7 tools is well-scoped for a browser automation server. Each tool provides a distinct capability without redundancy or excess.
Covers core browser automation needs: monitoring, content extraction, screenshots, session management, and reporting. Minor gaps like explicit navigation controls, but execute_task likely handles them via natural language.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Automate cloud browsers to navigate websites, interact with elements, and extract structured data.…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jenish3601/SmartBrowserMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
