Playwright CLI vs MCP - what to choose for your agent

Playwright CLI vs Playwright MCP - what to choose for your coding agent?

Before we start discussing Playwright CLI and Playwright MCP, we must go back a bit in history lane. Several years ago the concept of an AI coding agent that can communicate with you, work with you and create and edit your code was considered almost pure science fiction. Not to mention the ability to test the code like a Senior software automation QA engineer. We knew there were efforts in that direction but we did not expect them. And yet today this is totally normal and part of the everyday life for all involved in IT development or testing.

And the ability to check the outcome of a web application with Playwright with the help of your AI coding agent is an important part of the SDLC. But which Playwright? There are two options to choose from and shockingly - they both achieve the same! Yet there is an important difference between Playwright CLI and Playwright MCP. So in this post I will give my two cents on the topic and will try to help you understand which one of these (or both of them) to use, when and how. Let's dive in!

Playwright CLI vs Playwright MCP - what to expect from both of them for your coding agent?

Before we check the difference, we must elaborate more on the similarities. And long story short - both of them will allow your AI coding agent to check the outcome, analyze it, compare against acceptance criteria, define what is expected and what is the actual outcome and then to take action on fixing and/or documenting the changes. Both will allow the senior software QA automation engineer agent to interact with the content and functionality as well. And the final outcome of both will definitely be the same. However, everything common stops here!

Playwright CLI vs Playwright MCP - what are the differences and which to choose, when and how?

Now to the important part of this post - we will start with the core difference between both: where does the browser state live?

With the CLI everything is happening on your local disk. Files, YAML snapshots and the state itself live there and are available for analysis. In the MCP variant all is in the current context and the snapshots stream directly into the model memory.

Then comes interactive latency. The MCP option is better for instant step-by-step reasoning and checking. CLI has a slightly higher latency but is better for batching or code generation.

Next is what is your AI coding agent. Here is one important clarification - sandboxed does not always mean MCP! What actually decides is whether your agent can run shell commands or not. If it is a chat-based agent without terminal access then you might have no other option but to choose Playwright MCP. If your agent is placed in a sandbox (a container, a remote machine) but still has shell access there, the CLI works just fine - as long as Node.js and the Playwright browsers are available in that environment (or you add them to the image yourself). But if it is terminal-based coding - for almost all cases you will be better off with the CLI option.

As you know, tokens are the price we pay for AI generation. When we are speaking of coding agents, tokens are again extremely important. Therefore you need to aim to constantly reduce token cost. That is again in favor of the CLI variant. The reason is simple - with the MCP variant the tool schemas and an accessibility tree snapshot of the page go straight into the model context on every step, and for a big single-page application that snapshot alone can eat a serious part of your context window. The CLI keeps it lean - short console output, skills loaded on demand and the state on your disk.

Use cases for CLI and MCP?

Now let me present some use cases for each variant, and when to have both installed. Obviously we will be focused on a non-sandboxed AI coding agent (non-desktop, non-CI, non-container or otherwise not sandbox-isolated). This means that for most of the use cases we will be covering Playwright CLI. However this is the place to mention one specific case for the MCP. Imagine you are developing an app or you are working on an automation test. The best way to explain an issue to the agent while debugging is to share a common browser where you (as the human in the middle) will perform some action at some point, then you will tell the agent to inspect the browser and analyze the situation. This is possible with Playwright MCP exactly because it will open a headed Chrome browser where you and the agent can interact together (the MCP variant runs headed by default - the CLI runs headless). You do the human-only part yourself - a CAPTCHA, a complex OAuth login, whatever the automation cannot pass - then you tell the agent to inspect the current state and resume the work. MCP can also provide a persistent browser interaction. It also provides capabilities for storage, network, testing, tracing, PDF, DevTools, etc. More on that you can read on the official Playwright site.

For the CLI versions you might want to:

  1. Ask the AI coding agent to perform a task.
  2. Ask the AI agent to store the automation tests it creates for your own usage later - they will be created on disk anyway but now they could be preserved for you.
  3. Use it directly to create tests for your UI automation framework (but of course the final version of these tests will be as per your framework structure and syntax - not the agent's temporary quick script to execute).
  4. Also quite useful for test automation debugging (as we do know that automation tests are code and code can always have a bug somewhere).
  5. Regression testing for known workflows/test cases.

These do not exhaust all the Playwright CLI possibilities - just mention most of them.

To wrap it up here is a quick summary:

Feature/AspectMCPCLI
Sandboxed AI coding agentYesNo - unless the sandbox gives it shell access
Terminal based AI coding agentYes for detailed debugging, devtools/network analysis or interaction together with the user.Yes for almost all other tasks.
Token costHighLow
State storageIn contextOn disk

How to install both options?

One prerequisite first - Playwright needs its browsers on your machine. If something complains about a missing browser, run npx playwright install (the CLI's playwright-cli install downloads the browser and prepares the workspace for you) and you are good to go.

Here is a Windows PowerShell example but it should be the same for other OS types.

For Playwright CLI:

npm install -g @playwright/cli@latest

Then verify with

playwright-cli --help

And if you go with Claude Code you could also add the skill for that:

playwright-cli install --skills -g

For MCP (for Claude Code) you can:

claude mcp add playwright npx @playwright/mcp@latest

Then start a new Claude Code session and type "/mcp" and verify it is among your MCPs and is working.

And just for your information - for the rebuilding and redesign of Optibg.com from WordPress to Astro, I was primarily using the CLI option for detailed testing of features and regression with several parallel sub-agents that were checking desktop, mobile landscape and mobile vertical modes.

So the final verdict is - know your AI coding agent and if it is terminal based and non-sandboxed go with Playwright CLI, but bear in mind the MCP variant. For other types of AI coding agents - MCP variant is your best friend.

Featured image is AI generated!

Daniel Angelov

Daniel Angelov

About the author: Senior Automation QA Engineer with over 10 years of experience. A certified SEO and digital marketing specialist with extensive experience in building and optimizing WordPress sites, as well as copywriting. Author and owner of Optibg.com. Interests: Python, Selenium, Playwright, WebdriverIO, Appium, REST API Testing, JavaScript, open-source software, marketing, Photoshop, and more. Enjoys: reading books, computer games, and fishing. For more information, visit the "About the Blog" page and view his portfolio.