Chrome's Native MCP Server Slashes E2E Token Costs Compared to Playwright

Hi~ This is Sanjin.

Lately, AI-driven efficiency has been driving me crazy. The workload has suddenly doubled compared to before, and some earlier ideas have hit a wall — it's been a bit painful 😖.

Taking advantage of some free time this weekend, I pushed things forward a bit more.

Last time, we tried Playwright MCP for E2E automation. After testing, I found that while it could operate as expected, it consumed a huge amount of tokens. So this time, Sanjin found a derivative MCP of the Chrome browser — chrome-devtools MCP — to give it a try.

The test process this time is consistent with the Playwright MCP test, ensuring that under the same scenario, we can compare which tool is smoother and more cost-effective.

Introduction to Chrome-devtools

In September 2025, Chrome officially launched chrome-devtools MCP, which allows AI to directly operate the Chrome browser and debug web pages. This includes but is not limited to:

Using Chrome DevTools to analyze network requests, record performance traces for performance analysis, and inspect console logs
Simulating user behavior, such as navigation, filling out forms, and clicking buttons (isn't this exactly what E2E needs!)
When encountering difficult layout and style issues, AI can automatically adjust styles and layouts by inspecting the DOM and CSS (backend engineers no longer need to fear adjusting styles)
And more

Installation

We'll still use Claude Code as an example. There are two installation methods:

# claude command installation
claude mcp add chrome-devtools npx chrome-devtools-mcp@latest

Another way is to manually paste the corresponding JSON content into the MCP configuration file:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest"]
    }
  }
}

After configuration, open Claude and enter /mcp to check:

Usage

Explicitly tell the AI to use the chrome-devtools MCP to open a specified website and perform operations:

Use chrome-devtools mcp to open the browser:
1. Visit https://google.com
2. Enter "chrome-devtools mcp" in the search box and click search
3. On the search results page, click the first search result

Like Playwright, chrome-devtools also opens a separate browser instance for operations:

The whole process was very smooth! As expected from the same family~

Directly Accessing an Already Open Browser Instance

Returning to the scenario closest to development testing, what if you need to maintain a login state?

Chrome's official blog mentions that starting from Chrome 144+, you can directly access an already open browser instance by following these two steps:

In the Chrome browser, start the remote debugging server via chrome://inspect/#remote-debugging
Add --autoConnect or --auto-connect to the MCP configuration

{
  "command": "npx",
  "args": [
      "chrome-devtools-mcp@latest",
      "--autoConnect"
   ]
}

This mainly leverages Chrome's Remote Debugging Protocol:

When we enable remote debugging, Chrome starts a WebSocket server locally on port 9222, specifically for listening to debug connection requests
Exposes debugging interfaces: All open tabs, extensions, etc., expose operable interfaces via CDP

Chrome Process → Starts WebSocket Service → Listens on localhost:9222
                                                ↓
                                  Exposes debugging endpoints for all tabs

After adding --autoConnect to the MCP, it automatically discovers the already running Chrome instance.

Let's test it again:

Use chrome-devtools mcp to open the browser:
1. Visit https://cs.console.aliyun.com/
2. Click "Create Cluster"
3. Click "Use Existing" on the VPC network

Again, with an existing instance, the browser operations were performed smoothly step by step.

Advantages

chrome-devtools is part of the official Chrome ecosystem, so it naturally has an advantage over other similar MCP products.

No need to install additional browser extensions
Besides browser automation, it can also do performance analysis, style adjustments, mocking, etc.
Token consumption is reduced by multiple times compared to Playwright. For the same operations, Playwright consumes several times more tokens than chrome-devtools

Drawbacks

Because the Chrome browser needs to keep the debugging service on port 9222 open, and it exposes debugging endpoints for all tabs, if your computer's specs aren't great, it will get slower and slower 😂

Also, if the test case content is too long, the LLM context will be consumed faster. However, this can be solved by using a slicing approach.

Do you guys have any other tools or mature E2E Skills/Harnesses to recommend? Feel free to share in the comments section for discussion~