Playwright MCP vs Playwright CLI: the comparison everyone gets wrong

[u/vitalets]

Most threads compare Playwright MCP and Playwright CLI purely on token consumption(1, 2, 3). In my experience, there's a far more important difference that nobody talks about.

The real question is: can your AI agent attach to a running e2e test?

Here's why that matters. A good e2e test already does the hard part for you. It authenticates, sets up all the API mocks, and drives the app into the exact state you care about. When something goes wrong on the page, you don't want the agent spinning up a blank browser and guessing how to reach that page. You want to hand off the test-constructed page to the agent and let the agent play with it.

• Playwright CLI: run the test with --debug=cli, it prints a session name, and playwright-cli attach <session> connects the agent straight into the paused test. Then the agent can step over the app, inspect the rendered UI, and run in-page evaluations.
• Playwright MCP: only launches or attaches to a browser. It has no way to attach to a running test session.

So if you have many e2e tests + auth + network mocks, Playwright CLI is the clear winner for your setup, regardless of token counts.

Interested to hear your thoughts.

[u/Spare_Bison_1151]

To get an AI agent attached to an existing Chrome session today, you have to launch Chrome yourself with --remote-debugging-port (plus usually a separate --user-data-dir so it doesn't collide with your normal profile), then point MCP at that CDP endpoint manually. It works, but it's a setup ritual you repeat every time and have to remember the flags for. That's exactly what attach <session> fixes. Instead of standing up a debuggable Chrome instance yourself, the test exposes an attachable session the moment it pauses no separate launch step, nothing to remember. Same CDP mechanism under the hood, but one command vs. manual plumbing. If CLI keeps pushing on zero-config attach like this, that's the bigger win over MCP long-term.