Lesson 4 — The Bridge: chrome-devtools-mcp

You've built CDP from the bottom up: connect, domains & events, targets & sessions. This capstone connects it to your other course. chrome-devtools-mcp — Chrome's official server for AI agents — is an MCP server on top and CDP on the bottom. If you know both protocols, you can see straight through it.

The one-sentence mental model

chrome-devtools-mcp speaks MCP upward and CDP downward. Agents talk to it with tools/list / tools/call (your MCP track); it turns each tool call into CDP commands — via Puppeteer — against a real Chrome (this track).^repo

1 · It really is just an MCP server

We ran chrome-devtools-mcp and drove it by hand over MCP stdio — the same handshake you decoded in the MCP course. This is the real exchange:

# → initialize (MCP), ← the server identifies itself { "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-06-18", "capabilities": {}, "clientInfo": {…} } } { "id": 1, "result": { "serverInfo": { "name": "chrome_devtools", "title": "Chrome DevTools MCP server", "version": "1.7.0" } } } # → tools/list, ← 29 tools { "id": 2, "method": "tools/list" } { "id": 2, "result": { "tools": [ {"name":"navigate_page",…}, {"name":"take_screenshot",…}, … ] } }

The full tool set (29 in v1.7.0) is exactly the vocabulary of this track, one level up:^{tool reference}

click · close_page · drag · emulate · evaluate_script · fill · fill_form · get_console_message get_network_request · handle_dialog · hover · lighthouse_audit · list_console_messages list_network_requests · list_pages · navigate_page · new_page · performance_analyze_insight performance_start_trace · performance_stop_trace · press_key · resize_page · select_page take_heapsnapshot · take_screenshot · take_snapshot · type_text · upload_file · wait_for

2 · Every tool is CDP you already know

Read that list again through CDP eyes. Each high-level tool is one or more of the domains and commands from Lessons 2–3:

MCP tool	CDP underneath (Lesson)
`navigate_page`	`Page.navigate` + lifecycle events (L2)
`evaluate_script`	`Runtime.evaluate` (L2)
`take_screenshot`	`Page.captureScreenshot` (L2 ref)
`list_network_requests`, `get_network_request`	`Network.*` events + `getResponseBody` (L2)
`list_console_messages`	`Runtime.consoleAPICalled` (L2)
`click`, `hover`, `type_text`, `press_key`, `drag`	`Input.dispatchMouseEvent` / `dispatchKeyEvent`
`new_page`, `list_pages`, `select_page`, `close_page`	`Target.*` + sessions (L3)
`emulate`, `resize_page`	`Emulation.*`

It doesn't send CDP by hand — it uses Puppeteer, which speaks CDP for it. But every effect bottoms out in the commands you've been sending yourself.

3 · Proof on the wire — one MCP call, one CDP effect

Here's the demonstration that ties both courses together. We pointed chrome-devtools-mcp at the very Chrome we control — the one on --remote-debugging-port=9222 — using its --browser-url flag. Then we made one MCP tool call, and checked our tab over raw CDP:

# our tab beforehand, read over raw CDP (Lesson 1): $ bash assets/cdp-ws.sh eval 'location.href' → "about:blank" # one MCP call to chrome-devtools-mcp (connected via --browser-url http://127.0.0.1:9222): { "id": 3, "method": "tools/call", "params": { "name": "navigate_page", "arguments": { "url": "https://example.com/" } } } { "id": 3, "result": { "isError": false, "content": [ { "type": "text", "text": "Successfully navigated to https://example.com/.\n## Pages\n1: Example Domain …" } ] } } # our tab afterward, again over raw CDP — it MOVED: $ bash assets/cdp-ws.sh eval 'location.href' → "https://example.com/"

What just happened, in one breath

An agent's tools/call (MCP) crossed into chrome-devtools-mcp, which told Puppeteer to run Page.navigate (CDP) against our debugging port — and we saw the result with our own raw Runtime.evaluate. Two protocols, one continuous path, both of which you can now read on the wire.

4 · Using it for real (and safely)

To wire it into an MCP client you add one server entry — the same shape you saw in the MCP course:^repo

By default it launches its own Chrome. The flags worth knowing map onto everything you've learned:

The same debug-port warning, one level up

On startup the server itself prints: "chrome-devtools-mcp exposes content of the browser instance to the MCP clients allowing them to inspect, debug, and modify any data in the browser … Avoid sharing sensitive or personal information."^repo That's the Lesson 1 warning restated: whatever holds the CDP connection holds the whole browser. Point it at a throwaway profile, never your logged-in one.

🔧 Try it yourself (≈ 6 minutes)

Run the whole bridge end-to-end. A driver verb spawns chrome-devtools-mcp, connects it to your Chrome via --browser-url, and makes the call — then you confirm over raw CDP. From the cdp/ directory:

# start our controlled Chrome bash assets/cdp-ws.sh up # reset the tab so the change is visible bash assets/cdp-ws.sh navigate about:blank # MCP handshake + tools/list + tools/call navigate_page, all against OUR Chrome bash assets/cdp-ws.sh bridge https://example.com/ # prove the MCP call drove CDP on our tab: bash assets/cdp-ws.sh eval 'location.href' bash assets/cdp-ws.sh down

The first run downloads the server via npx (give it a moment). Watch the tools/list names go by — you now know what each one does underneath. Ask me to map any tool you're unsure of.

Check yourself

Primary source — read this next

The chrome-devtools-mcp repository (README for install & flags) and its tool reference. Read the tool list and, for each, name the CDP domain behind it — you now have the vocabulary to do exactly that.