What is Chrome DevTools MCP?
Chrome DevTools MCP exposes browser inspection and control to coding agents through an MCP server. It is useful for connecting an investigation to a real browser: inspect a page, examine its behavior, and return evidence to the agent. Remote Browser supplies the separate runtime that the server would attach to.
The official repository supports Google Chrome and Chrome for Testing; it explicitly does not guarantee other Chromium-based browsers. Check the actual runtime build before assuming that a hosted Chromium session has the same support status.
Why use an existing remote browser?
An existing browser is useful when the problem depends on a particular account, navigation history, or runtime environment. Recreating the page in a newly launched local browser can lose the state needed to reproduce the issue.
Decide what evidence you need before starting: the failing URL, visible result, relevant network behavior, and a reproducible sequence. A performance trace and a screenshot answer different questions, so collect only the artifacts that help evaluate the issue.
Quick start
Create a dedicated browser allocation and put its authenticated WebSocket endpoint in REMOTE_BROWSER_CDP_URL. In a Node.js project with a pinned chrome-devtools-mcp dependency, the upstream WebSocket configuration can be supplied as:
npx chrome-devtools-mcp --ws-endpoint "$REMOTE_BROWSER_CDP_URL"Configure your MCP client to launch that server process. Start with read-only navigation and confirm the browser identity. Do not assume that starting a default server attaches to the intended remote session.
Connection methods and compatibility
The configuration guide distinguishes an HTTP discovery address through --browser-url from a browser WebSocket URL through --ws-endpoint. Custom WebSocket headers have their own configuration. Match the option to the endpoint supplied by your provider.
Local browser launch settings do not replace settings on an already allocated browser. Choose the remote profile, network route, and browser build through the runtime's supported configuration. If an inspection feature depends on a Chrome capability, test it on that exact build and server version.
Use cases to validate
- Reproduce a page defect inside an authorized test account.
- Investigate a navigation or request problem in a known browser environment.
- Return screenshots and a concise issue report to a coding agent.
- Compare a repeatable page workflow before and after an application change.
The server and browser can have separate filesystems. Confirm where traces and screenshots are stored and whether your report can retrieve them. Also review the upstream data-collection settings before collecting traces of internal applications.
FAQ
Is Chrome DevTools MCP interchangeable with Playwright MCP?
Both expose browser tools through MCP, but their tool interfaces and requirements differ. Choose according to the task and test the exact server and runtime combination rather than relying on the shared protocol label.
Does a CDP URL prove that every inspection tool works?
No. Verify the browser build, supported Chrome features, gateway behavior, and artifact handling. This collection documents configuration, not a compatibility certification.
How should I measure this workflow?
Record tool latency, page behavior, result verification, and failures separately. The shared CDP timing script is only a connection-path baseline; it does not measure all inspection tools.