Essay

Playwright CLI vs Playwright MCP: Which for AI Agents?

Playwright CLI vs Playwright MCP compared for coding agents: token use, skills, sessions, snapshots, commands and when each is the right way to drive a browser.

15 February 2026 · 11 min · Irfan Ahmad

For most of 2025, the answer to “how do I give my coding agent a browser?” was the Playwright MCP server. In January 2026 the Playwright team gave a second answer. Playwright 1.58, released on 23 January, announced “a new token-efficient CLI mode of operation” with skills, published as playwright-cli.

So now there are two official ways for an agent to drive Playwright, from the same team, with overlapping features. This essay compares Playwright CLI vs Playwright MCP as of mid-February 2026: how each one works, what it costs in tokens and context, and how to decide which one your team should use. If you are new to MCP in testing, start with our earlier essay on Playwright MCP servers and agentic testing.

The short answer

The playwright-cli README answers the question itself, which is unusual and helpful:

CLI: “Modern coding agents increasingly favor CLI–based workflows exposed as SKILLs over MCP because CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context.”
MCP: “MCP remains relevant for specialized agentic loops that benefit from persistent state, rich introspection, and iterative reasoning over page structure, such as exploratory automation, self-healing tests, or long-running autonomous workflows.”

In other words, if you are using a coding agent such as Claude Code or GitHub Copilot to write and debug tests in a repository, the Playwright team is nudging you towards the CLI. If you are building an autonomous agent loop that needs to reason about the page continuously, MCP is still the tool.

What is Playwright MCP?

Playwright MCP is a Model Context Protocol server that exposes browser automation as tools an LLM can call. You add it to an MCP client, for example:

claude mcp add playwright npx @playwright/mcp@latest

The agent then sees tools such as browser_navigate, browser_click, browser_type and browser_snapshot. The defining design choice is the accessibility snapshot. After most actions, the server returns a structured text view of the page with element references, so the model can say “click e21” rather than guess at a CSS selector.

That design is why Playwright MCP worked so well in 2025. Models are good at reading structured text, and accessibility trees are close to how a user perceives a page. The cost is size. Every tool schema is loaded into the model’s context when the session starts, and every snapshot adds more text.

What is Playwright CLI?

playwright-cli is a command-line program that keeps a browser running in the background and accepts one command per invocation:

npm install -g @playwright/cli@latest
playwright-cli --help

A manual session looks like this, straight from the README:

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli type "Water flowers"
playwright-cli press Enter
playwright-cli check e21
playwright-cli check e35
playwright-cli screenshot

The element references (e21, e35) are the same idea as in MCP. The difference is that the agent asks for a snapshot only when it needs one, with playwright-cli snapshot, and can save it to a file with --filename instead of pulling it into context. The README’s key feature is one line: “Token-efficient. Does not force page data into LLM.”

Skills instead of tool schemas

The second half of the design is skills. Running this in your project root:

playwright-cli install --skills

installs skill files that Claude Code, GitHub Copilot and other agents pick up locally. A skill is a short, readable description of how to use a tool. The agent loads it when relevant, rather than carrying dozens of tool definitions in every request.

There is also a skills-less mode. The README suggests simply telling the agent to check playwright-cli --help, and it will learn the commands from the help text.

Sessions and persistent profiles

By default the CLI uses a dedicated persistent profile, so cookies and storage survive between calls. Named sessions let you run separate browsers for separate projects:

playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com
playwright-cli list

You can also start your agent with PLAYWRIGHT_CLI_SESSION=todo-app claude . so every command it runs goes to the same named browser. close-all and kill-all clean up.

Playwright CLI vs Playwright MCP: feature comparison

Question	Playwright CLI	Playwright MCP
Interface	Shell commands, one per call	MCP tools over stdio or HTTP
How the agent learns it	Skills or `--help`	Tool schemas loaded at session start
Page snapshots	On demand, can be saved to file	Returned with most actions
Token use	Lower by design	Higher, especially on large pages
Browser state	Persistent profile by default, named sessions	Per server session, configurable
Best for	Coding agents working in a repo	Autonomous loops reasoning over pages
Install	`npm install -g @playwright/cli@latest`	`npx @playwright/mcp@latest`
Requirements	Node.js 18+ and a coding agent	Node.js and an MCP client

The command set

In the 1.58 release notes, the Playwright team said the first CLI snapshot already had an “essential command set (which is already larger than the original MCP!)”. In February 2026 the CLI groups its commands roughly like this:

Group	Examples
Core	`open`, `goto`, `click`, `fill`, `type`, `select`, `upload`, `check`, `snapshot`, `eval`
Navigation and input	`go-back`, `reload`, `press`, `mousemove`, `mousewheel`
Evidence	`screenshot`, `pdf`, `tracing-start`, `tracing-stop`, `video-start`, `video-stop`
Tabs	`tab-list`, `tab-new`, `tab-select`, `tab-close`
Storage	`state-save`, `state-load`, `cookie-`, `localstorage-`, `sessionstorage-*`
Network	`route`, `route-list`, `unroute`, `network`
DevTools	`console`, `run-code`

That list matters for testers. Storage commands make it easy to set up and inspect logged-in state. route lets an agent mock a failing API to test an error state. Tracing and video commands give you evidence that a human can review later.

Why token efficiency matters for testing

It is tempting to treat token cost as a billing issue. For testing work, it is more about quality.

Context is finite. Every large snapshot pushes earlier context out or crowds it. An agent that has forgotten the test plan or the code it is supposed to fix makes worse decisions.
Long sessions degrade. Debugging a flaky test can take dozens of steps. If each step carries a full page tree, the session becomes slow and expensive long before the bug is found.
Coding agents already have a shell. Claude Code, Copilot and similar tools are built around running commands and reading files. A CLI fits that loop without another protocol.

The CLI’s approach is to keep page data out of the model until it is needed. The agent can save a snapshot to a file, grep it, and read only the part it needs, just as it would with a large log.

When Playwright MCP is still the better choice

None of this makes MCP obsolete. The README itself lists the cases where it still wins, and I agree with them.

Exploratory automation

When an agent is exploring an app with a goal rather than a script, it needs to see the page after almost every action. MCP’s “snapshot with every step” design is what you want here, even if it costs more.

Self-healing and live repair loops

Agents that repair locators or adapt to UI changes need rich, current introspection. We discussed the limits of this pattern in Playwright Test Agents and the truth about self-healing tests. If you do it, MCP gives the agent better situational awareness.

Non-coding agents

Not every agent has a shell. Desktop assistants, chat-based agents and some hosted platforms speak MCP but cannot run commands. For them, MCP is the only option.

Long-running autonomous workflows

If an agent runs for a long time with no human in the loop, persistent state and structured tool results are easier to monitor and log through MCP.

When Playwright CLI is the better choice

Writing and fixing tests in a repo

This is the core case. The agent reads your test file, opens the app with playwright-cli, reproduces the failure, inspects a snapshot, then edits the test. The output is a normal Playwright Test spec that your team reviews.

Reproducing bugs from tickets

Give the agent a bug report and ask it to reproduce the issue with the CLI, save a screenshot and a trace, and write a failing test. Saved files make the result easy to attach to the ticket.

Working with authenticated state

state-save and state-load make it simple to log in once and reuse the session, which avoids the agent repeating login flows and burning context.

CI-adjacent tasks

Because the CLI is just a program, you can script it. That makes it easier to combine with other command-line tools in the same job. I would still not use an agent-driven CLI session as a gating check in CI, for reasons we covered in AI coding agents writing tests.

Configuring Playwright CLI for a project

The CLI reads playwright-cli.json from the working directory by default, or a file you pass with --config. The schema covers the browser to use (chromium, firefox or webkit), whether to keep the profile in memory with isolated, and where to store a persistent user data directory. A minimal project config might look like this:

{
  "browser": {
    "browserName": "chromium",
    "isolated": true
  }
}

Two practical tips. First, commit the config alongside the skill files so every developer and every agent session starts from the same settings. Second, prefer isolated for bug reproduction tasks, so leftover cookies from yesterday’s session do not hide a login bug today. Use the persistent profile only when the task really depends on an existing logged-in state, and use state-save to make that state explicit.

Moving an existing MCP setup to the CLI

If your team already uses Playwright MCP with a coding agent, you do not need a big migration. A gradual switch works well:

Keep the MCP server configured while you trial the CLI, so nobody is blocked.
Install the CLI and skills in one repository and ask the agent to prefer playwright-cli for browser work.
Compare a few real tasks. Pick recent bug reproductions or test fixes and run them both ways. Note how often the agent finished, how long it took and whether it needed help.
Remove MCP from coding-agent configs once the CLI handles your common tasks. Keep it for any exploratory or non-coding agents.

Measure on your own repository rather than trusting anyone’s benchmark, including the Playwright team’s. Page size, app complexity and the model you use all change the results.

A practical workflow for teams

Here is the workflow I recommend for a team adopting coding agents in February 2026.

Install the CLI and skills in the repo. Run playwright-cli install --skills so the agent finds them automatically. Commit the skill files so everyone gets the same behaviour.
Use named sessions per task. PLAYWRIGHT_CLI_SESSION=bug-1234 claude . keeps browsers separate and makes cleanup easy.
Ask for evidence. Every agent session should end with a screenshot or trace and a short summary of what it did.
Require a real test as output. The agent’s browser session is a means to an end. The deliverable is a reviewed spec in Playwright Test.
Keep MCP for exploration. If you run exploratory agents, give them Playwright MCP in a separate, sandboxed environment with test accounts.
Review assertions like any code. Agents are good at making tests pass. Make sure the test checks the right thing.

Pros and cons

Playwright CLI

Pros

Lower token use and less context pressure
Fits naturally into coding agents that already run shell commands
Persistent profiles and named sessions
Large command set from day one, including storage, network routing, tracing and video

Cons

Very new, with frequent releases and likely changes
Requires an agent that can run shell commands
Less useful for agents that need to see the page after every action

Playwright MCP

Pros

Mature and widely supported by MCP clients
Rich, structured snapshots after actions
Works for agents without a shell

Cons

Higher token use, especially on large pages
Tool schemas occupy context in every session
Easier for long sessions to drift as context fills

Security notes for both

Both tools give an AI agent a real browser, so the same guardrails apply.

Run against staging or ephemeral environments with test data.
Do not expose production credentials to the agent. Use dedicated test accounts.
Treat page content as untrusted. Prompt injection through page text is a real risk, as we covered in MCP and the OWASP LLM Top 10.
Clean up persistent profiles. The CLI’s persistent profile is convenient, but it also stores cookies. Use delete-data when a task is done.

What this means for your team

The Playwright team now ships two agent interfaces because there are two kinds of agent work. Coding agents that live in your repo should use the CLI. Autonomous agents that explore live pages can keep using MCP.

The bigger lesson is about context discipline. The best agent setups give the model exactly the information it needs at each step and nothing more. Playwright CLI is a good example of a tool designed around that principle. Whatever you choose, keep humans responsible for what gets tested and what counts as a pass.

Frequently asked questions

What is the difference between Playwright CLI and Playwright MCP?

Playwright CLI is a command-line tool that coding agents call one command at a time, loading page snapshots only on demand. Playwright MCP is an MCP server that exposes browser tools and returns accessibility snapshots with most actions. The CLI uses fewer tokens; MCP gives richer continuous context.

When was Playwright CLI released?

It was announced in the Playwright 1.58 release on 23 January 2026, with the code in the microsoft/playwright-cli repository. Version 0.1.0 followed on 7 February 2026.

Do I need skills to use Playwright CLI?

No. playwright-cli install --skills installs skill files for agents like Claude Code and GitHub Copilot, but the README also describes a skills-less mode where the agent reads playwright-cli --help.

Is Playwright MCP deprecated?

No. The Playwright team says MCP remains relevant for exploratory automation, self-healing tests and long-running autonomous workflows that benefit from persistent state and rich introspection.

Can Playwright CLI replace Playwright Test?

No. The CLI drives a browser interactively. Your regression suite should still be written in Playwright Test, with the CLI used by agents to explore, reproduce and author those tests.