MCP.Market

Chrome Debugger MCP server

by BitePro·io.github.BitePro/chrome-debugger-mcp·v1.0.4·1 stars
No reviews yet

Chrome breakpoint debugging MCP server for inspecting runtime values and stepping through code

B72/100grade B
Write a reviewInstall
What users say
No reviews yet
Be the first
Safety scan
B72/100

full report

Adoption
New

1 stars46 downloads/wk

Reviews

Write one

Nobody has reviewed Chrome Debugger MCP yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

Chrome Debugger MCP tools (18, 1 write)

write = sends, deletes, buys or posts

Read from the package source without running it. The installed server may list more.

  • connect

    [STEP 3] Connect the debugger to a specific Chrome tab. MANDATORY: call listTargets first, show the list to the user, wait for their explicit URL confirmation, then call this. NEVER guess the URL. NEVER skip user confirmation — even if only one tab is visible. targetUrl must be a unique substring of the tab URL the user confirmed (e.g. "localhost:5173"). Relay the "_ui" field from the response to

  • disconnect

    Disconnect the current Chrome debugging session and clear in-memory pause state. Use this to explicitly end a debug session before connecting again.

  • evaluate

    [STEP 6b] Evaluate any JavaScript expression in the context of the currently paused call frame. Use this to inspect nested objects, call methods, compute derived values, or verify conditions at runtime. Complements getScopeVariables for values not directly visible in scope (e.g. this.state, JSON.stringify(obj)).

  • forcePause

    Force the debugger to pause at the very next JavaScript statement. Useful when you cannot modify source code to add debugger; and setBreakpoint is not feasible.

  • getScopeVariables

    [STEP 6a] Read all scope variables (local, closure, module) at the currently paused call frame. Call this immediately after waitForSpecificPause or waitForPause returns. Results are grouped by scope type; global scope is skipped. Use frameIndex=1, 2, ... to inspect variables in parent call frames up the stack.

  • getStatus

    Non-blocking: return current connection and pause state immediately without waiting. Use this to poll for pause instead of waitForPause when the MCP client has a short request timeout (e.g. MCP Inspector ~10s). Returns: connected, paused, targetUrl, pauseReason, hitBreakpoints, callStack.

  • launchChrome

    [STEP 1] Launch a dedicated Chrome instance with remote debugging enabled (default port 9222). Uses --user-data-dir=~/.chrome-debug-profile so your normal Chrome keeps running (dual-instance). Auto-detects if the debug port is already active and skips launch (alreadyRunning=true). Use dryRun=true to preview the command — show it to the user and ask for confirmation before executing. Set openDevToo

  • listTargets

    [STEP 2] List all open Chrome tabs available for debugging. MANDATORY: show the full list to the user and ask "Which URL do you want to debug?" NEVER skip this step, NEVER guess — even if only one tab is open. Wait for the user's explicit reply before proceeding to connect(). Relay the "_ui" field from the response to the user.

  • reloadPage

    [STEP 5a] Reload the connected page via Chrome DevTools Protocol. More reliable than manual browser refresh — maintains the CDP connection and ensures debugger; statements and setBreakpoint() calls resolve correctly when scripts reload. Always call this after inserting debugger; in source code or after setBreakpoint(), before waitForSpecificPause/waitForPause. ⚠️ CRITICAL TURN RULE: After this too

  • removeBreakpointwrite action

    Remove a previously set CDP breakpoint by its ID (returned by setBreakpoint).

  • resume

    [STEP 8] Resume script execution after collecting all needed variable data — ends the current pause. After calling resume, remove all temporary debugger; statements added to source code during this session. Relay the "_ui" field from the response to the user.

  • setBreakpoint

    Set a breakpoint at a specific script URL and line number via CDP — no source code modification needed. Use a full URL (https://...) for exact match, or a partial filename/keyword for regex match. Alternative to inserting debugger; when you cannot modify the source file. After setting, call reloadPage() to ensure the breakpoint resolves correctly.

  • startDebuggingSession

    CALL THIS FIRST whenever browser-side debugging is needed — before any other tool. Auto-trigger when user mentions any of: debug, breakpoint, debugger, inspect, trace, step through, runtime value, variable value, why is this, implement based on API response, bug, error, unexpected behavior, not working, check this, confirm this. Returns the complete debugging workflow and critical rules. The respo

  • stepInto

    [STEP 7] BLOCKING: step into the next function call, then wait until the debugger pauses again. Follow with getScopeVariables() to observe inner-function state.

  • stepOut

    [STEP 7] BLOCKING: step out of the current function and wait until the debugger pauses again in the caller. Use to observe the return value and the state of the calling context.

  • stepOver

    [STEP 7] BLOCKING: step over the current statement without entering function calls, then wait until the debugger pauses again. Follow with getScopeVariables() to observe how local variables change.

  • waitForPause

    [STEP 5b — FALLBACK] BLOCKING call — waits until ANY debugger pause occurs (breakpoint, debugger; statement, or exception). Before blocking, sends a notification to the user to trigger the page action. Must be called IMMEDIATELY after reloadPage() in the SAME AI turn — do NOT end your turn before calling this. Prefer waitForSpecificPause when you know the exact file and line — it uses smarter two-

  • waitForSpecificPause

    [STEP 5b — PREFERRED] BLOCKING call — waits for the next debugger pause, then checks if it matches the target location. ⚠️ NO AUTO-RESUME: execution stays paused after this returns, regardless of matched value. You decide what to do based on the "matched" field in the response: matched=true → call getScopeVariables() immediately to read variables matched=false → the wrong breakpoint fired; call re

Public scan report

scanner v0.1.10 · 2026-09-27 · same rubric, same numbers if you re-run it

no findings
  • Code scan5 source files scanned25/25
  • –Live reliabilityno gateway calls yet and no remote to proben/a
  • –Tool poisoningtools not inspected (local package is not executed); not countedn/a
  • Auth qualitylocal package, no credentials required12/15
  • Maintenancelast push 196 days ago4/15
  • Maintainer identityregistry namespace matches repository owner6/10
Overall 72/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

How Chrome Debugger MCP compares

Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.

Safety score
72/100
higher than 38% of 48,255 servers
Tools
18
the typical server has 7
Tools that change things
6%
typical: 0%. Fewer write tools means less an agent can break
GitHub stars
1
more than 65% of 28,688 servers
Downloads a week
46
more than 38% of 12,191 servers with a package

What its tools let an agent do: 14 read · 1 change · 1 delete · 2 run or deploy

Install Chrome Debugger MCP in Claude Code, Cursor or VS Code

Runs npx -y chrome-debugger-mcp on your machine. Read the scan report first; the gateway never runs local packages.

claude mcp add chrome-debugger-mcp -- npx -y chrome-debugger-mcp
Add to Cursor

What the publisher says

From the Chrome Debugger MCP repository's README, as published. We do not edit it. Read it on GitHub

chrome-debugger-mcp

English | 中文

English

An MCP server for breakpoint-driven Chrome debugging.

chrome-debugger-mcp exposes Chrome DevTools Protocol primitives as MCP tools so an AI agent can attach to a real Chrome tab, pause execution, inspect scope values, evaluate expressions inside the current call frame, and step through code with runtime facts instead of guessing from static source.

It is not a general browser automation server. The focus is runtime debugging.

Core Capabilities

  • Attach to a real Chrome tab over CDP after explicit user confirmation
  • Pause at breakpoints or debugger; statements and wait for the exact pause you expect
  • Read local, closure, and module scope values from the paused frame
  • Evaluate JavaScript in the current call frame and step execution forward
  • Resume cleanly so the agent can continue with actual runtime values

Demo

Demo: the agent launches Chrome, waits for a breakpoint, inspects real scope variables, and resumes with runtime facts instead of guessing.

MCP Client Configuration

Use the published package

{
  "mcpServers": {
    "chrome-debugger": {
      "command": "npx",
      "args": ["-y", "chrome-debugger-mcp"]
    }
  }
}

Installation

From npm

npx -y chrome-debugger-mcp

Or install it globally:

npm install -g chrome-debugger-mcp

From source

pnpm install
pnpm build
node dist/index.js

Other Highlights

  • Launch a dedicated Chrome instance with remote debugging enabled
  • Set and remove DevTools breakpoints without editing source code
  • Reload the page through CDP so breakpoints reliably bind after navigation
  • Poll debugger state when the MCP client has short request timeouts
  • Emit _ui payloads and logging messages that clients can surface to the user

Why It Helps

Many browser-focused MCP tools are strong at DOM interaction and network inspection, but weak at runtime debugging. This server gives an MCP client the missing loop you would normally use in Chrome DevTools: attach to the right tab, pause at the right time, inspect real values, step if needed, and resume cleanly.

It also adds guardrails that prevent common agent mistakes:

  • guessing which tab to attach to
  • concluding behavior without inspecting runtime values
  • ending the turn between reloadPage() and waitForSpecificPause()

Requirements

  • Google Chrome installed locally
  • An MCP client that supports stdio servers and tool calling
  • Access to the application you want to debug
  • Local source access if you plan to insert temporary debugger; statements

Tooling Model

The server runs over stdio and exposes MCP tools. The most important tools are:

  • startDebuggingSession: returns the recommended debugging workflow and critical rules for agent behavior
  • launchChrome: launches a dedicated Chrome instance with remote debugging enabled
  • listTargets: lists available Chrome tabs and requires the user to pick one
  • connect: attaches to the confirmed tab
  • setBreakpoint: creates a CDP breakpoint without modifying source files
  • removeBreakpoint: removes a breakpoint created by setBreakpoint
  • reloadPage: reloads the current page through CDP
  • waitForSpecificPause: waits for the next pause and checks whether it matches a target file and line
  • waitForPause: waits for any pause without location matching
  • getScopeVariables: reads local, closure, and module scope values from the paused frame
  • evaluate: executes JavaScript in the paused call frame
  • stepInto, stepOver, stepOut: standard execution control

Recommended Workflow

Shortened. The full README is on GitHub.

Nothing above is checked by us. What we check is on the safety report.

Chrome Debugger MCP: common questions

Is Chrome Debugger MCP server safe?
Mostly: it is graded B (72/100). Read the Chrome Debugger MCP safety report
How do I install Chrome Debugger MCP?
It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.
Does Chrome Debugger MCP need an API key?
Not as far as the registry entry and our scan can tell: no credentials are declared or required.
Is Chrome Debugger MCP maintained?
The last commit was 234 days ago (2026-03-15). The latest release is v1.0.4.
How does Chrome Debugger MCP compare with other MCP servers?
safety score 72/100 (higher than 38% of 48,255 servers); tools 18 (the typical server has 7); tools that change things 6% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.