Playwright MCP vs Chrome DevTools MCP

Short answer

• Both servers filled every field, uploaded the file and worked inside a same-origin and a cross-site iframe when they started their own Chrome, in five of five runs each.
• Attached to a Chrome a person had already opened, Playwright MCP filled the open form straight away. Chrome DevTools MCP 1.10.1 could click there but could only fill fields after it reloaded the page once, in every run.
• Chrome DevTools MCP’s own Chrome reported navigator.webdriver = true; Playwright MCP’s reported false. In a Chrome you start yourself, both reported false.
• Pick Playwright MCP for clean, repeatable runs and a smaller tool list. Pick Chrome DevTools MCP when you debug your own web app (traces, Lighthouse, network) or want to share your everyday Chrome with the agent.

Test results

Each cell counts passing runs out of 5. Test date September 30, 2026, Google Chrome 154.0.8037.92, @playwright/mcp 0.0.83, chrome-devtools-mcp 1.10.1, agent-browser 0.38.1 as a third column.

Mode 1: the tool starts its own Chrome

Each tool launched a headless Chrome with a fresh profile folder, opened the test page, signed in to the page, filled the form and pressed submit without ticking the human step.

Mode 2: the tool attaches to a Chrome a person already uses

We started Chrome ourselves with its own profile and a local debugging port. A stand-in for the person opened the page, signed in and typed the product name. Then the tool connected, filled the rest and stopped; the stand-in ticked the human step and submitted; the tool read the result.

Screenshots from the runs

How we tested

• Date September 30, 2026 on macOS with Google Chrome 154.0.8037.92. Versions were pinned: @playwright/mcp 0.0.83, chrome-devtools-mcp 1.10.1, agent-browser 0.38.1.
• The form is a local test page on 127.0.0.1; the cross-site iframe comes from localhost on a second port. No real website, account, personal browser profile or payment was involved.
• A small script talked to each server over MCP, exactly like an agent’s client: snapshot, fill form, upload, click, read console and network. It took element references from each tool’s own snapshot. No language model made decisions, so every run followed the same steps.
• Every scenario ran 5 times per tool. The tables count the runs that passed.
• The person in mode 2 is a script that sends plain DevTools Protocol commands to the tab. It is a stand-in, not a real person. To rule it out as the cause of the Chrome DevTools MCP fill failure, we also started Chrome directly with the test URL and no script at all: same result.
• agent-browser was driven through its command line, its main interface, not through its MCP mode.

What this test does not cover

• Real CAPTCHAs, bot checks and real sign-ins on third-party sites.
• Firefox and WebKit, the browser extensions of both projects and Chrome’s auto-connect dialog.
• Performance traces, Lighthouse and memory tools.
• A language model choosing the steps: how many tokens and turns a real agent needs depends on the model.
• Windows and Linux.

What stood out

Documented, not tested

These differences come from each project’s README and docs on the reading date. We did not measure them.

How much the tool list weighs

Before any page was opened, Playwright MCP announced 25 tools with 20.3 KB of tool descriptions, Chrome DevTools MCP 30 tools with 25.7 KB (default settings, measured through tools/list). An agent carries that text in its context for the whole session. Chrome DevTools MCP offers --slim with three tools; Playwright MCP adds tool groups with --caps.

Which one to pick

And agent-browser?

agent-browser is a command-line browser tool for agents with an optional MCP mode. It filled the same form when it started its own browser, but missed the cross-site iframe when attached to a running Chrome. Worth a look if your agent works better with short shell commands than with MCP tools.

Claude in Chrome vs Chrome DevTools MCP →

Run the test yourself

The test page is one Node.js file without dependencies. It only listens on your own machine.

1. Download the file and run it with Node.js 18 or newer.
2. Open http://127.0.0.1:4461/ once to see the page; the cross-site iframe loads from http://localhost:4462/.
3. Add one of the MCP entries below to your agent and ask it to fill the form, upload any small PNG, fill both iframes and stop before the human step.
4. Tick the human step yourself, submit, and ask the agent what the page shows now.

Download browser-mcp-test.mjs

The file serves the form, the iframe and a local echo endpoint. Nothing is sent anywhere else.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@0.0.83"
      ]
    }
  }
}

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@1.10.1",
        "--no-usage-statistics"
      ]
    }
  }
}

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@0.0.83",
        "--cdp-endpoint",
        "http://127.0.0.1:9222"
      ]
    }
  }
}

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@1.10.1",
        "--browser-url=http://127.0.0.1:9222",
        "--no-usage-statistics"
      ]
    }
  }
}

What LaunchRepo uses

• LaunchRepo’s playbooks are written and tested for Chrome DevTools MCP connected to your own Chrome, because directory submissions need your real logins and you should see every step.
• With a Chrome you start yourself, navigator.webdriver stayed false for every tool in this test, and the handoff worked: you finish a step in the same tab, the agent reads the result.
• If a directory form is already open when the agent connects, let it reload the page before you type anything, so nothing you entered is lost.

• Connect your coding agent to your Chrome →
• Launch your SaaS on directories with Claude Code →
• Chrome DevTools Protocol →
• MCP server →

Sources

Official pages and repositories, read on September 30, 2026. Quotes are copied word for word; our test results are our own measurements.

FAQ

Is Playwright MCP or Chrome DevTools MCP better for coding agents?

Neither wins everywhere. In our test both passed every form check when they started their own Chrome. Playwright MCP also filled a page a person had already opened and announced a shorter tool list; Chrome DevTools MCP brings performance traces, Lighthouse and deeper network and console tools for debugging your own app.

Can Chrome DevTools MCP use the Chrome I am signed in to?

Yes. With --autoConnect it connects to your running Chrome 144 or newer after you allow remote debugging and confirm a dialog. Or start Chrome with a remote debugging port and a separate profile folder and point --browser-url at it; since Chrome 136 the port is ignored for the default profile.

Do both handle iframes?

Yes, in our runs both reached a same-origin and a cross-site iframe in both modes, five of five times, and could type and click inside them.

Why did the file upload fail?

Both servers only read files from allowed folders by default: Playwright MCP from the workspace roots or its working directory, Chrome DevTools MCP from the system temp folder when your client names no roots. Move the file there or use the documented flag to widen the limit.

Can these tools solve CAPTCHAs?

Neither documents a CAPTCHA feature, and we did not test real CAPTCHAs. Plan a handoff instead: the agent stops, you solve the step in the same visible window, the agent continues. In our attach test that handoff worked for both servers.

Does navigator.webdriver give the agent away?

In our test it was true only when Chrome DevTools MCP launched Chrome itself. Playwright MCP’s own Chrome and any Chrome we started ourselves reported false. Whether a site reacts to it is up to that site; we did not test real bot checks.