Chrome DevTools MCP vs Playwright MCP vs an MCP extension

Chrome DevTools MCP vs Playwright MCP is the comparison most people search for when they first give an agent a browser. They are built for different jobs, and neither is the only option. This post compares them with three other approaches: MCP browser extensions (Browser MCP, hangwin/mcp-chrome and MCP Browser Extension, the project this site documents) and Browser Use, which is an agent rather than a set of tools. Every cell about another project comes from that project's own README or docs, checked on the date of this post. These projects change quickly, so check their READMEs before you decide.

The one question that splits them

Every browser MCP server has to decide whose browser the agent drives. There are two answers.

The first is a browser the server launches itself, through Playwright, Puppeteer or the Chrome DevTools Protocol. It is clean and reproducible, it can run headless, and it starts signed out. Chrome DevTools MCP and Playwright MCP work this way by default.

The second is the browser you already have open, reached through an extension. It has your sessions and cookies, it runs in a visible window, and it touches your real accounts. Browser MCP, hangwin/mcp-chrome and MCP Browser Extension work this way.

The line is not strict. Both Chrome DevTools MCP and Playwright MCP can now attach to a browser you run, and Browser Use can reuse a Chrome profile. The defaults still tell you what each tool was designed for. If you want the background on the two architectures, start with what an MCP browser extension is.

Comparison table

A dash means the project's README or docs do not document that point. It does not mean the feature is missing.

For a deeper look at how MCP Browser Extension compares with Playwright MCP, Puppeteer MCP and Browser Use on policy, secrets and audit, see the compare page. This post does not repeat it.

Chrome DevTools MCP

Chrome DevTools MCP, from the Chrome DevTools team, gives an agent the debugging side of Chrome. Its README lists three key features: performance insights from recorded traces, debugging through network requests, screenshots and console messages with source-mapped stack traces, and automation through Puppeteer that waits for action results.

What stands out

The tool reference goes well past clicking. It has performance trace tools, a Lighthouse audit, CSS style inspection, network, CPU and viewport emulation, and a set of memory tools for heap snapshots. A --slim mode exposes a smaller set for basic browser tasks. There is also a CLI for use without MCP.

By default it starts a new Chrome with a dedicated profile under ~/.cache/chrome-devtools-mcp/. That profile persists between runs unless you pass --isolated. To work in your own browser, --autoConnect connects to a running Chrome 144 or later after you enable remote debugging at chrome://inspect/#remote-debugging, and Chrome asks for permission.

Things to know

The README is clear that the server exposes browser content to the MCP client, and warns against sharing data you do not want the client to see. Usage statistics go to Google by default; pass --no-usage-statistics to turn that off. Performance tools may send trace URLs to the CrUX API unless you pass --no-performance-crux.

Playwright MCP

Playwright MCP, from Microsoft, drives a browser through Playwright and hands the model structured accessibility snapshots instead of screenshots. Its README stresses that no vision model is needed.

What stands out

It supports Chrome, Firefox, WebKit and Edge through --browser. It runs headed by default and headless with --headless. Extra tool groups are opt-in through --caps, including vision (coordinate-based clicks), PDF, network, storage and test assertions.

There are three profile modes. The default is a persistent profile stored per workspace. --isolated keeps the profile in memory, optionally seeded with --storage-state. --extension connects to a running Chrome or Edge through the Playwright browser extension, which lets you use your logged-in tabs.

Things to know

The README itself suggests that coding agents may do better with the Playwright CLI and skills, because CLI calls avoid loading large tool schemas and accessibility trees into context. --allowed-origins exists, but the README says it is not a security boundary and does not affect redirects.

The extension approach: Browser MCP, mcp-chrome, MCP Browser Extension

All three run inside the Chrome you already use, so the agent starts signed in.

Browser MCP is an MCP server plus a Chrome extension. Its README says it was adapted from Playwright MCP to automate your own browser instead of creating new instances, and that it uses your existing profile to stay logged in. It also notes that the published repo cannot currently be built on its own, because it depends on code in a separate monorepo.

hangwin/mcp-chrome is a Chrome extension with a bridge you install from npm. It recommends a Streamable HTTP connection, with stdio as an alternative. Its feature list includes semantic search across open tabs with a built-in vector database, network capture, and tools for browsing history and bookmarks. The README says the project is still early and under intensive development.

MCP Browser Extension (@mehmoodqureshi/chrome-mcp) is an MCP server over stdio plus an MV3 extension that connects through a localhost WebSocket. It starts deny-all: no domains, no mutations, no eval, no downloads until you allow them. It adds a batch tool for driving many tabs in one call, auth_check for expired sessions, a per-call history.jsonl audit log, and opt-in redaction of secrets in page reads. It does not run headless and supports Chrome only. Setup is in the quickstart, and the full tool list is in the tools reference.

Browser Use

Browser Use is different in kind. It is a browser agent: you give it a task and it runs its own loop with a model you choose. It comes as a Python library under the MIT licence, a CLI, and a hosted cloud with stealth browsers and an agent API.

It can also run as a local MCP server over stdio, started with uvx --from 'browser-use[cli]' browser-use --mcp. Its docs say this option needs your own LLM API keys. To reuse a local login, the README points to Browser.from_system_chrome().

Playwright MCP vs Browser Use

This is the real split: tools for your agent, or a second agent. Playwright MCP gives Claude, Cursor or another host a set of browser tools, and your host's model decides every step. Browser Use runs its own agent, so you hand off a task and get a result. Pick Playwright MCP when you want your existing agent in control and want to see each step. Pick Browser Use when you want a self-contained browser agent in your own Python code, or a hosted one.

Connecting Playwright MCP or Chrome DevTools MCP to your existing browser

Both servers start their own browser by default, and both can now reach one you already run. Neither does it unless you ask.

• Chrome DevTools MCP: --autoConnect attaches to your running Chrome 144 or later once you enable remote debugging at chrome://inspect/#remote-debugging, and Chrome asks for permission. --browserUrl points it at a browser you started with a debugging port. Sources: README, advanced usage.
• Playwright MCP: --extension connects to a running Chrome or Edge through the Playwright browser extension, which lets you use your logged-in tabs. Without it, a persistent profile or --storage-state is how you carry a login between runs. Source: microsoft/playwright-mcp README.

Either route gives the agent your sessions. Neither is built around limiting what the agent may read there: Playwright MCP's README says its --allowed-origins flag is not a security boundary. A deny-all domain allowlist that gates reads as well as clicks is what MCP Browser Extension adds on top of the session.

Which one should you pick?

There is no single best. Pick by job. For a wider field of ten servers sorted by job, see the best browser MCP servers.

Pick Chrome DevTools MCP when

• You are debugging a web app: console errors, failing network requests, layout.
• You need performance traces, Lighthouse audits or memory analysis.
• You want Chrome specifically, and the Chrome team's own tooling.

Pick Playwright MCP when

• You are writing or fixing end-to-end tests and want the same engine your test suite uses.
• You need Firefox or WebKit, or headless runs in CI.
• The target is public, or you are happy to script the login.

Pick an MCP browser extension when

• The page is behind a login you have already done in Chrome: a dashboard, an admin panel, a CRM, Gmail or GitHub.
• You do not want credentials, cookies or tokens in any config file.
• You want the agent working in your real session without starting a second browser.

Among the extensions, pick MCP Browser Extension when you want a deny-all allowlist, reads gated as well as writes, multi-tab batch and an audit trail. The security page has the details, and the logged-in Chrome page shows the common setup. Pick hangwin/mcp-chrome if semantic search across tabs or history and bookmark tools matter more to you.

Pick Browser Use when

• You want an autonomous agent to finish a whole task, not tools for the agent you already use.
• You want hosted cloud browsers.

Host-specific setup for the extension route is in the guides for Claude Code, Cursor, VS Code Copilot and Codex.

FAQ

What is the difference between Chrome DevTools MCP and Playwright MCP?

Chrome DevTools MCP is built on Puppeteer and focuses on debugging and performance in Chrome, with traces, Lighthouse and memory tools. Playwright MCP is built on Playwright and focuses on automation through accessibility snapshots, across Chrome, Firefox, WebKit and Edge.

Can Chrome DevTools MCP or Playwright MCP use my logged-in Chrome?

Yes, both can now. Chrome DevTools MCP has --autoConnect for Chrome 144 and later, and Playwright MCP has an --extension mode with its own browser extension. Neither does it by default.

Is Browser Use an MCP server?

It can run as one, over stdio, but it is mainly a browser agent library with its own loop. Its docs say the local MCP server needs your own LLM API keys.

Which browser MCP is best for pages behind a login?

An extension-based one, because it uses the session you already have. MCP Browser Extension, Browser MCP and hangwin/mcp-chrome all do this; they differ in defaults, such as MCP Browser Extension's deny-all domain allowlist.

Which one should I use in CI?

Playwright MCP or Chrome DevTools MCP, both of which support --headless. MCP Browser Extension does not run headless, so it is the wrong choice for CI.