· 6 min read ·

CDP Meets MCP: Why Your Coding Agent Should Debug Your Real Browser Session

Source: hackernews

Browser automation has been a solved problem for years. Selenium showed up in 2004, Puppeteer in 2017, Playwright in 2020. Each generation produced a cleaner API, better reliability, and tighter cross-browser support. All three share a foundational assumption: you hand the tool a browser it controls from the start, and you get a reproducible blank slate.

The reproducibility is valuable for CI and test suites. It becomes a liability when you are debugging something that only manifests in your live session, with your cookies, your specific account state, and the exact sequence of interactions you already went through.

Chrome’s new DevTools MCP server takes a different approach. It does not start a fresh browser. It attaches to the one you are already running, with your session intact. That is a qualitatively different tool from Playwright MCP, even though the surface-level API looks similar.

The Protocol Underneath

Everything here is built on Chrome DevTools Protocol (CDP), which has been part of Chrome since version 32 in 2014. CDP is a JSON-RPC protocol exposed over WebSocket when Chrome launches with --remote-debugging-port=9222. The DevTools panel you open in your browser communicates over CDP. Remote debuggers, profilers, and headless browser libraries all use it.

CDP is organized into domains, each covering a different browser subsystem. The Runtime domain handles JavaScript execution and evaluation. DOM exposes tree inspection and mutation. Network covers request and response monitoring with interception. Page handles navigation, screenshots, and lifecycle events. Debugger gives you breakpoints, call stacks, and step-through execution. There are roughly 40 domains total, each with methods you can call and events the browser emits.

When you call Runtime.evaluate, the browser executes an expression in the page’s JavaScript context and returns the result. Network.requestWillBeSent fires for every outgoing request, including headers, post body, and initiator stack trace. Page.captureScreenshot returns a base64-encoded PNG of the current viewport.

Libraries like Puppeteer and Playwright wrap CDP at a higher level of abstraction, but they do so from the outside, having launched the browser process themselves and owning its full lifecycle. The Chrome DevTools MCP server takes a different stance: you launch Chrome with remote debugging enabled, and the MCP server connects to the already-running instance.

The MCP Layer

Model Context Protocol (MCP) is Anthropic’s open standard for how AI agents connect to external tools and data sources, released in November 2024. It uses JSON-RPC 2.0 over stdio or HTTP transports. An MCP server declares a list of named tools, each with a description and a JSON Schema for its input parameters. The AI model can call those tools mid-conversation and reason about the returned values.

The Chrome DevTools MCP server is an MCP server that proxies CDP commands. The tool named screenshot calls Page.captureScreenshot. The evaluate tool maps to Runtime.evaluate. getConsoleMessages reads the accumulated console log. The agent calls structured MCP tools; the server translates them into CDP wire calls against your running browser.

Setup requires two things: Chrome launched with debugging enabled, and the MCP server process running locally.

# Launch Chrome with the remote debugging port open
google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/debug-session

# Run the MCP server
npx @chrome-devtools/mcp --port 9222

In your MCP client configuration, for example Claude Code’s .claude/mcp.json:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["@chrome-devtools/mcp", "--port", "9222"]
    }
  }
}

The agent now has CDP-backed tools pointing at your actual running session.

What the Live Session Changes

The capabilities on paper overlap significantly with Playwright MCP. Both give agents a screenshot tool, navigation, click simulation, and JavaScript evaluation. The difference is state.

Playwright MCP (@playwright/mcp) is well-suited for automation workflows: navigate to a page, fill a form, submit it, verify the response. The fresh context is a feature there, because you want reproducibility across runs and you do not want prior session state contaminating your tests.

The Chrome DevTools MCP slot is narrower: the agent helps you debug the browser session you are currently in. Consider an authentication edge case that only reproduces with your specific account configuration. With Playwright in a fresh context, you would need to script the entire login flow, navigate to the affected page, reproduce the exact sequence of user actions, and hope the reproduction is faithful. With Chrome DevTools MCP, you are already at the failing state. You point the agent at the tab, it calls Runtime.evaluate to inspect window.__store or document.cookie, reads the console errors already present, grabs a screenshot, and reports back. The feedback loop, where the agent observes what you are observing, is closer to collaborative debugging than to test automation.

CDP Depth for Network Debugging

One place where attaching to a live session shows its depth is network debugging. The Network domain in CDP captures request headers, response headers, response bodies, WebSocket frames, and detailed timing breakdowns including DNS resolution time, TCP connection time, TLS handshake, time-to-first-byte, and content transfer duration. It also records the initiator, meaning the JavaScript call stack or HTML parser reference that triggered the request.

For an intermittent 403 on an API call, an agent with CDP access can compare the headers of a successful request against the failing one, call Network.getResponseBody on the failed response to read the error payload, and check the request initiator to trace where in the code the call originated. You do not need to add console instrumentation and reload. The information is already recorded in the CDP timeline.

For WebSocket-heavy applications, like anything using socket.io or a custom signaling layer, Network.webSocketFrameReceived and Network.webSocketFrameSent expose the full frame stream. This is the kind of debugging information that is tedious to extract manually and genuinely useful to hand to an agent.

Playwright MCP is the closest analog. It is mature, supports Chromium, Firefox, and WebKit, and is actively maintained by Microsoft. The tradeoff is always a fresh browser context; for automation workflows this is a strength, for debugging existing state it is a constraint.

browser-use is a Python library that gives LLMs control of a browser instance, also through a managed context rather than an existing session. The focus is task automation rather than debugging assistance.

Stagehand (from Browserbase) combines Playwright with LLM-generated selectors, so you can describe elements in natural language rather than CSS selectors. Still a managed fresh context, but interesting at the interaction layer for agents that need to navigate unfamiliar UIs.

Remote desktop approaches, which feed agents screenshots without any DOM access, cannot introspect JavaScript state or network activity. They see pixels; they cannot tell you what a variable contains or what a failed request returned.

The Chrome DevTools MCP fills a position none of these tools occupy: a coding agent attached to the session you are already debugging, with full CDP depth available.

Security

When Chrome runs with --remote-debugging-port=9222, any local process that connects to that WebSocket endpoint has unrestricted access to your browser. It can read cookies and local storage for any domain, execute JavaScript in any open tab, intercept or replay network requests, and capture screenshots of whatever is on screen.

The default binding is localhost, which means the exposure is to your local machine only. That boundary is what matters. Do not forward port 9222 through SSH tunnels, do not expose it through any reverse proxy, and do not leave remote debugging running when you are not actively using it. On a personal development machine with controlled physical access, the risk is manageable. On shared machines or cloud development environments, it warrants more care.

For scoped use, the --user-data-dir flag lets you point Chrome at a separate profile directory, keeping your debugging session isolated from your main browser profile. You get a fresh cookie jar for the debug session without running a second browser installation.

Where This Belongs in the Workflow

The practical home for this tool is the debugging phase of frontend development, not the testing phase. You have a broken UI in front of you. You want another perspective on what the DOM looks like, what the console is saying, what state the JavaScript runtime is in, what the network log shows. You ask the agent to look, it looks, you get structured information back.

For developers already running Claude Code or similar MCP-enabled agents, adding Chrome DevTools MCP to the local setup is low friction. One extra Chrome flag, one extra background process, and the agent gains direct access to the browser you already have open.

CDP is twelve years old. MCP is sixteen months old. Connecting them to give coding agents a window into live browser sessions was the logical next step; it is useful to see the Chrome team ship it as a supported tool rather than leave it as an exercise for the community.

Was this interesting?