Enables monitoring and debugging of Google Chrome browser tabs through the Chrome DevTools Protocol, including console log capture, JavaScript execution, page navigation, and Chrome extension development support.
Uses puppeteer-core to connect to Chrome's DevTools Protocol for browser automation and console monitoring capabilities.
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., "@Simple Console MCP show me the console logs from my current browser tab"
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.
6 tools, 85% of debugging scenarios. Best signal-to-noise ratio for AI-assisted browser debugging.
A minimal MCP Server focused on browser debugging essentials. 6 tools vs 26+ (chrome-devtools-mcp), giving your AI assistant the best signal-to-noise ratio for debugging.
Comparison | chrome-devtools-mcp | simple-console-mcp |
Tools | 26+ | 6 |
Context Cost | ~5000 tokens | ~350 tokens |
Focus | Full-featured | Console + Network + Screenshot + JS |
Related MCP server: Kaboom Browser AI Devtools MCP
This project started with a simple question: "I just want to debug my web app. Why do I need 26+ tools?"
chrome-devtools-mcp is powerful, but more tools means more cognitive load for the AI — leading to slower responses and wrong tool choices. For everyday debugging, you need a high signal-to-noise ratio, not a Swiss army knife.
So I built this "Minimum Viable MCP" with the 6 tools that cover ~85% of debugging scenarios:
list_targets — List browser tabs
get_console_logs — Read Console output
get_network_logs — Monitor HTTP requests/responses
navigate — Navigate or reload
execute_js — Execute JavaScript in page context
take_screenshot — Capture page screenshot for visual debugging
The core goal is best signal-to-noise ratio — maximum debugging power with minimum tool count. Every tool earns its place by covering a capability that execute_js cannot replace.
Claude Code (one-liner):
claude mcp add simple-console -- npx -y simple-console-mcpClaude Desktop or other MCP clients (Cursor / Windsurf / Cline):
{
"mcpServers": {
"simple-console": {
"command": "npx",
"args": ["-y", "simple-console-mcp"]
}
}
}Claude Code:
claude mcp add simple-console -- npx -y github:tznthou/simple-console-mcpgit clone https://github.com/tznthou/simple-console-mcp.git
cd simple-console-mcp && npm installclaude mcp add simple-console -- node /path/to/simple-console-mcp/src/index.jsNo manual setup required! The MCP automatically detects whether Chrome has CDP enabled:
If CDP is already enabled → connects directly
If not → auto-launches a new Chrome with debug mode using isolated profile
Just install the MCP, and tell Claude "help me debug" — it handles everything automatically.
Note (v1.4.0+): If you already have a regular Chrome open, the MCP will show a clear error message asking you to close it first. This prevents conflicts between regular and debug Chrome instances.
If auto-launch fails, you can start Chrome manually:
# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
# Linux
google-chrome --remote-debugging-port=9222
# Windows
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222list_targetsList all available browser targets (pages, Service Workers, etc.).
Parameter | Type | Default | Description |
| number | 9222 | Chrome CDP port |
Available targets:
[0] page: http://localhost:3000
[1] service_worker: chrome-extension://xxx/background.js
[2] page: chrome-extension://xxx/popup.htmlget_console_logsGet Console output from a specific target. Starts monitoring on first call.
Parameter | Type | Default | Description |
| number | 0 | Target index from list_targets |
| number | 50 | Maximum lines to return |
| string | "all" | Filter type: all / error / warn / log / info / debug |
| number | 9222 | Chrome CDP port |
=== Console Logs for http://localhost:3000 ===
[12:34:56] ERROR: Uncaught TypeError: Cannot read property 'x' of undefined
[12:34:57] WARN: Deprecation warning...
(showing 2 of 50 total logs, filter: all)get_network_logs (New in v1.5.0)Get HTTP request/response logs from a specific target. Starts monitoring on first call.
Parameter | Type | Default | Description |
| number | 0 | Target index from list_targets |
| number | 50 | Maximum entries to return |
| string | "all" | Filter type: all / failed / xhr / fetch / document / stylesheet / script / image |
| number | 9222 | Chrome CDP port |
=== Network Logs for http://localhost:3000 ===
[GET] 200 http://localhost:3000/ (120ms, 4.2KB)
[GET] 200 http://localhost:3000/api/user (85ms, 1.1KB)
[POST] 500 http://localhost:3000/api/save (230ms)
[GET] FAILED http://localhost:3000/missing.js (15ms) Error: net::ERR_FILE_NOT_FOUND
(showing 4 of 4 total, filter: all)navigateNavigate to a URL or reload the page.
Parameter | Type | Default | Description |
| string | - | Target URL or "reload" |
| number | 0 | Target index |
| number | 9222 | Chrome CDP port |
Navigated to: http://localhost:3000/login
Page title: "Login"
(Console logs cleared)execute_js (New in v1.4.0)Execute JavaScript code in the page context. Useful for clicking buttons, filling forms, reading DOM, or calling page functions.
Parameter | Type | Default | Description |
| string | - | JavaScript code to execute (max 10,000 chars) |
| number | 0 | Target index |
| number | 9222 | Chrome CDP port |
Safety measures:
Code length limit: 10,000 characters
Execution timeout: 5 seconds
Result size limit: 50,000 characters
Examples:
// Click a button
document.querySelector('button#submit').click()
// Read page title
document.title
// Call page function
myApp.doSomething()
// Fill form input
document.getElementById('email').value = 'test@example.com'
// Get element count
document.querySelectorAll('.item').length=== JavaScript Executed ===
Code: document.title
Result:
"My Application"take_screenshot (New in v1.5.0)Capture a screenshot of the current page. Returns a PNG image (auto-falls back to JPEG if too large). Useful for visual debugging of layout, CSS, or UI state.
Parameter | Type | Default | Description |
| number | 0 | Target index from list_targets |
| boolean | false | Capture full scrollable page (true) or viewport only (false) |
| number | 9222 | Chrome CDP port |
Safety measures:
Viewport clamped to 1280×800 max
PNG → JPEG fallback if image exceeds 500KB
fullPage: false by default to prevent oversized captures
graph TB
subgraph Client["AI Client"]
CLAUDE["Claude Desktop<br/>or Claude Code"]
end
subgraph MCP["simple-console-mcp"]
SERVER["MCP Server<br/>StdioTransport"]
TOOLS["6 Tools<br/>list_targets | get_console_logs | get_network_logs<br/>navigate | execute_js | take_screenshot"]
CACHE["Cache<br/>Console Logs + Network Requests"]
end
subgraph Browser["Chrome Browser"]
CDP["CDP Port 9222<br/>--remote-debugging-port"]
PAGES["Browser Targets<br/>Pages | Service Workers"]
CONSOLE["Console Events<br/>log | error | warn"]
end
CLAUDE --> |"MCP Protocol"| SERVER
SERVER --> TOOLS
TOOLS --> |"puppeteer-core"| CDP
CDP --> PAGES
PAGES --> |"console event"| CACHE
CACHE --> |"formatted logs"| TOOLSClaude calls get_console_logs → MCP returns accumulated logs → Claude processes
↑ |
└──────────────── Claude must call again ────────────────┘Behavior:
On first get_console_logs call, MCP starts monitoring that target
Console events are continuously collected in memory (max 500 entries)
Claude does NOT receive automatic notifications — must call get_console_logs again to see new logs
Why Pull-based? MCP protocol is request-response based and doesn't support push notifications. The server cannot proactively tell Claude "there's a new error" — Claude must actively ask.
This MCP supports monitoring Console output from Chrome Extensions:
[0] page: http://localhost:3000 ← Regular webpage
[1] service_worker: chrome-extension://abc/background.js ← Extension background script
[2] page: chrome-extension://abc/popup.html ← Extension popupUse different targetIndex values to monitor each target separately.
Technology | Purpose |
Node.js 18+ | Runtime |
ES Modules | Module system |
@modelcontextprotocol/sdk | MCP protocol implementation |
puppeteer-core | Chrome CDP connection (no bundled Chromium) |
zod | Parameter validation |
simple-console-mcp/
├── src/
│ └── index.js # MCP Server (~770 lines, security hardened)
├── bin/
│ └── start-chrome.sh # Chrome startup helper
├── .github/
│ └── workflows/
│ └── release.yml # Tag → GitHub Release + npm publish
├── test/ # Manual test pages (HTML)
├── package.json
├── README.md # English docs (this file)
├── README_ZH.md # Chinese docs
├── CHANGELOG.md # Full changelog
└── LICENSE # Apache-2.0Item | Requirement |
Node.js | 18+ |
Chrome | Any version with |
OS | macOS / Linux / Windows |
Chrome must have CDP enabled: Chrome without --remote-debugging-port cannot be connected
One Chrome at a time: If multiple Chrome instances exist, MCP connects to the first one
Log cache limit: Each target keeps at most 500 console logs and 200 network entries, older ones are automatically removed
Navigation clears cache: Calling navigate clears both console logs and network request cache
Supply-chain security gets extra weight for an MCP server — it sits between your AI and your browser. This package's defenses:
Layer | Posture |
Publishing | OIDC trusted publishing — no long-lived |
GitHub Actions | All third-party actions pinned to full commit SHA |
Dependencies |
|
Provenance | Every release published with npm provenance |
See CHANGELOG.md for the latest hardening pass.
New Features:
✨ get_network_logs tool: Monitor HTTP requests/responses
Pull-based monitoring (same pattern as console logs)
Shows method, URL, status, duration, size
Filter by: all / failed / xhr / fetch / document / stylesheet / script / image
200 entries cache per target
✨ take_screenshot tool: Capture page screenshots
Returns PNG image via MCP image content type
Auto-fallback to JPEG if PNG exceeds 500KB
Viewport clamped to 1280×800, deviceScaleFactor: 1
Optional fullPage mode
Improvements:
🔧 Extracted getTargetPage() shared helper (reduces code duplication across tools)
🔧 Navigation now clears both console and network caches
🔧 Cleanup handler now removes network event listeners
📦 Repositioned from "97% lighter" to "6 tools vs 26+ with best signal-to-noise ratio"
New Features:
✨ execute_js tool: Execute JavaScript in page context
Click buttons, fill forms, read DOM, call page functions
Safety measures: 5s timeout, 10K code limit, 50K result limit
✨ Simplified Chrome launch logic:
Directly launches debug Chrome with isolated profile (/tmp/chrome-cdp-9222)
Clear error message when regular Chrome conflicts with debug Chrome
Improvements:
📦 Code grew from ~460 to ~550 lines (+20%)
🔧 Removed automatic Chrome kill logic (user must close regular Chrome manually)
📝 Better error messages explaining Chrome conflict resolution
Full changelog: CHANGELOG.md
This project is licensed under the Apache License 2.0.
GitHub: @tznthou
Execute JavaScript code in the page context. Returns the result of the expression. Useful for clicking buttons, filling forms, or calling page functions.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript code to execute in page context | |
| targetIndex | No | Target index from list_targets | |
| port | No | Chrome CDP port |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns the result of the expression,' which is helpful, but lacks critical details such as execution context (e.g., sandboxing, permissions), error handling, timeout behavior, or security implications. For a tool that executes arbitrary JavaScript code, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded: the first states the core functionality, the second explains the return value, and the third provides usage examples. There's no wasted text, though the examples could be more structured or prioritized.
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 of executing JavaScript code in a page context (with no annotations and no output schema), the description is incomplete. It lacks details on execution safety, error responses, or output formatting. The examples help but don't compensate for missing behavioral context, making this inadequate for a tool with such potential impact.
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%, providing clear documentation for all three parameters (code, targetIndex, port). The description doesn't add any parameter-specific information beyond what's in the schema, such as code examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute JavaScript code') and resource ('in the page context'), with a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its siblings (get_console_logs, list_targets, navigate), which all operate in the same browser automation context but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through examples ('clicking buttons, filling forms, or calling page functions'), suggesting this tool is for interacting with page elements. However, it doesn't explicitly state when to use this tool versus alternatives like navigate for page navigation or list_targets for target selection, nor does it mention 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.
Get console logs from a browser target. Starts monitoring on first call.
| Name | Required | Description | Default |
|---|---|---|---|
| targetIndex | No | Target index from list_targets | |
| maxLines | No | Maximum lines to return | |
| filter | No | Filter by log type | all |
| port | No | Chrome CDP port |
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 adds important context about 'Starts monitoring on first call' which reveals this isn't just a passive read but initiates an active monitoring session. However, it doesn't disclose other critical behaviors: whether this is read-only or has side effects, authentication needs, rate limits, or what happens on subsequent calls. For a tool with no annotations, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences) with zero wasted words. The first sentence states the core purpose, and the second adds critical behavioral context. Every sentence earns its place, and the information is front-loaded appropriately.
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 4 parameters with 100% schema coverage but no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and one behavioral aspect (monitoring initiation) but leaves significant gaps: no output format description, no error handling information, no guidance on tool sequencing with siblings, and incomplete behavioral transparency. For a tool that initiates monitoring, this is borderline sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. With complete schema coverage, the baseline is 3 even without parameter details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get console logs') and resource ('from a browser target'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like list_targets or navigate, which would require a 5. The phrase 'Starts monitoring on first call' adds useful behavioral context but doesn't address sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_targets (which might provide target indices) or execute_js (which might generate logs). There's no mention of prerequisites (e.g., needing to call list_targets first to get targetIndex) or contextual constraints. The single sentence offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available browser targets (pages, service workers, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Chrome CDP port |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('List') but lacks behavioral details such as whether this requires an active browser connection, if it's read-only (implied but not confirmed), what the output format looks like (e.g., list of objects with IDs), or any rate limits. The description is minimal and doesn't compensate for the absence of annotations.
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 front-loads the core purpose ('List all available browser targets') and adds clarifying examples ('pages, service workers, etc.') without unnecessary details. Every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 100% schema coverage, no output schema), the description is incomplete. It lacks context on behavioral aspects like connection requirements, output format, or error handling. Without annotations or an output schema, the description should provide more guidance on what to expect after invocation, but it does not, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'port' fully documented in the schema as 'Chrome CDP port' with a default. The description adds no parameter-specific information beyond what the schema provides, such as explaining why the port matters or how it relates to targets. Baseline score of 3 is appropriate since the schema handles the parameter documentation adequately.
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 ('List') and resource ('all available browser targets'), with examples of what targets include ('pages, service workers, etc.'). It distinguishes from siblings like 'execute_js' or 'navigate' by focusing on enumeration rather than interaction or navigation. However, it doesn't explicitly differentiate from 'get_console_logs', which might also involve listing logs from targets, slightly reducing specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a browser instance connected), exclusions (e.g., not for modifying targets), or suggest sibling tools like 'navigate' for interacting with listed pages. Usage is implied as a starting point for target selection but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: execute_js runs JavaScript, get_console_logs retrieves logs, list_targets enumerates browser targets, and navigate handles URL navigation. The descriptions reinforce these unique functions, making misselection unlikely.
All tools follow a consistent verb_noun pattern (execute_js, get_console_logs, list_targets, navigate), using snake_case throughout. The naming is predictable and readable, with no deviations in style or convention.
With 4 tools, this server is well-scoped for a simple console MCP, covering core browser automation tasks (execution, logging, target listing, navigation). Each tool earns its place without feeling thin or bloated, aligning with the server's focused purpose.
The toolset provides solid coverage for basic browser console operations, including execution, monitoring, target management, and navigation. A minor gap exists in lacking tools for more advanced interactions like element inspection or network request handling, but agents can work around this for common workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants — DOM, console, network via MCP.
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 approval MCP, built to return verdicts, receipts, usage logs,
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tznthou/simple-console-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
