
Chrome DevTools MCP
OfficialLets coding agents drive a real Chrome: automate input, read console and network, record performance traces.
Add to your client
Copy the config for your MCP client and paste it into its config file.
npx -y chrome-devtools-mcp@latestPaste into ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"chrome-devtools-mcp": {
"command": "npx",
"args": [
"-y",
"chrome-devtools-mcp@latest"
]
}
}
}Step-by-step guides: Add to Claude Desktop · Add to Cursor · Add to Windsurf
Before you start
- Node.js LTS version
- Current stable Google Chrome (or Chrome for Testing) installed
- npm/npx available on PATH
About Chrome DevTools MCP
chrome-devtools-mcp runs as a local Node process over stdio and starts a stable-channel Chrome using a persistent profile under ~/.cache/chrome-devtools-mcp/ (pass --isolated for a throwaway profile). Automation goes through Puppeteer, which waits for action results automatically — noticeably fewer flaky interactions than raw CDP scripting. The browser only starts when the first tool that needs it is called, not on connect.
Performance work is the differentiator. The agent can record a DevTools trace, pull the same insights the Performance panel computes (LCP breakdown, render blocking, etc.), run Lighthouse audits, and optionally enrich results with real-user CrUX field data. For debugging there are source-mapped console stack traces, request-level network inspection, and an 11-tool heap-snapshot suite for memory-leak hunting.
The configuration surface is large but practical: --headless, --viewport, --channel, proxy settings, URL allow/block lists (--allowedUrlPattern / --blockedUrlPattern) to fence in network access, and screenshot format/size caps to keep context small. --experimentalPageIdRouting adds page IDs so concurrent subagents can share one server without stepping on each other's tabs.
Trade-offs: it officially supports Google Chrome and Chrome for Testing only. Usage statistics and CrUX lookups are on by default (both can be turned off), browser state persists between runs unless isolated, and some sites block sign-in for WebDriver-launched browsers — attach to a normally-started Chrome via --browser-url when that bites.
Tools & capabilities (51)
clickClick an element on the page
dragDrag an element to another element
fillFill a single input field
fill_formFill multiple form fields in one call
handle_dialogAccept or dismiss browser dialogs
hoverHover over an element
press_keyPress a keyboard key
type_textType text into the page
upload_fileUpload a file through a file input
click_atClick at x/y coordinates (requires --experimentalVision)
close_pageClose a browser tab
list_pagesList open pages/tabs
navigate_pageNavigate the current page to a URL
new_pageOpen a new page
select_pageSwitch the active page
wait_forWait for text or a condition before continuing
emulateEmulate device, network or CPU conditions
resize_pageResize the viewport
performance_start_traceStart recording a performance trace
performance_stop_traceStop the trace and summarize results
performance_analyze_insightDrill into a specific insight from a recorded trace
get_network_requestInspect one network request in detail
list_network_requestsList network requests made by the page
evaluate_scriptRun JavaScript in the page context
get_console_messageRead a specific console message
list_console_messagesList console output with source-mapped stack traces
lighthouse_auditRun a Lighthouse audit on the current page
take_screenshotCapture a screenshot (png/jpeg/webp)
take_snapshotTake a text snapshot of the page with element UIDs
screencast_startStart recording a screencast (requires ffmpeg)
screencast_stopStop the screencast recording
take_heapsnapshotCapture a V8 heap snapshot
close_heapsnapshotRelease a loaded heap snapshot
compare_heapsnapshots_summaryDiff two heap snapshots at summary level
compare_heapsnapshots_class_nodesDiff two heap snapshots per class
get_heapsnapshot_summarySummarize a heap snapshot
get_heapsnapshot_class_nodesList nodes of a class in a heap snapshot
get_heapsnapshot_detailsInspect a heap snapshot node in detail
get_heapsnapshot_dominatorsGet dominator information for nodes
get_heapsnapshot_edgesList edges of a heap snapshot node
get_heapsnapshot_retainersList retainers of a node
get_heapsnapshot_retaining_pathsTrace retaining paths for a node
install_extensionInstall a Chrome extension (pipe connection only)
list_extensionsList installed extensions
reload_extensionReload an extension
trigger_extension_actionTrigger an extension's action button
uninstall_extensionRemove an extension
list_3p_developer_toolsList third-party developer tools exposed by the page
execute_3p_developer_toolInvoke a third-party developer tool
list_webmcp_toolsList WebMCP tools published by the page (Chrome 149+)
execute_webmcp_toolInvoke a WebMCP tool from the page
What this server can do
Chrome DevTools MCP provides tools for these capabilities — tap one to see every MCP server that does the same:
When to use it
- Have an agent verify its own frontend changes: click through the UI, read the console, and confirm no errors before committing
- Record a performance trace and get concrete LCP/CLS insights, optionally backed by CrUX field data
- Debug failing requests: list network activity, inspect headers and bodies, and correlate with console errors
- Hunt memory leaks by taking and diffing heap snapshots between interactions
Quick setup
- 1Install Node.js LTS and current Chrome
- 2Add the npx config to your MCP client, or run `claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest` for Claude Code
- 3Restart the client — Chrome launches automatically on the first tool call
- 4Smoke-test with the prompt "Check the performance of https://developers.chrome.com"
- 5Optional: add flags like `--headless`, `--isolated`, or `--browser-url=http://127.0.0.1:9222` to attach to an existing Chrome
Security notes
Everything in the controlled browser is exposed to the MCP client — pages, logged-in sessions, network traffic — so don't browse sensitive accounts in the automated profile. Google collects usage statistics by default (disable with --no-usage-statistics), and an open remote-debugging port lets any local process control that browser.
Chrome DevTools MCP FAQ
Is chrome-devtools-mcp safe to run?
It's official Google tooling and safe to install, but treat the controlled browser as fully visible to your agent: it can read and modify any page, session, or request in that profile. Keep the default separate profile, avoid logging into sensitive accounts there, and note usage statistics are collected by default (--no-usage-statistics disables).
Can it attach to my already-running Chrome with my logins?
Yes. On Chrome 144+ enable chrome://inspect/#remote-debugging and start the server with --autoConnect. On older versions, launch Chrome with --remote-debugging-port=9222 and a non-default --user-data-dir, then pass --browser-url=http://127.0.0.1:9222 — but remember the debug port gives any local process browser control.
How is this different from Playwright MCP?
chrome-devtools-mcp is Chrome-only but goes deeper into DevTools: performance traces with insights, Lighthouse audits, heap-snapshot diffing, and source-mapped console traces. Pick Playwright MCP for cross-browser automation; pick this for debugging and performance work in Chrome.
Alternatives to Chrome DevTools MCP
Compare all alternatives →Automate your existing browser with AI using your real profile, logged-in sessions, and stealth fingerprint.
All-in-one web access MCP — Web Unlocker, SERP, Scraper API, and a cloud Scraping Browser.
macOS screen capture, AI visual analysis, and full GUI automation for AI agents.
Compare Chrome DevTools MCP with: