Playwright CLI is the better choice over Playwright MCP for AI driven browser automation because it consumes far fewer tokens, delivers higher accuracy, and exposes about three times more features.
It issues shell commands, saves a compact summary of each page to disk, reads full details only when needed, runs headless, captures screenshots at every step, and generates a clear report showing status, reproduction steps, evidence, and recommendations.
This makes it ideal for automated QA, like verifying Jira tickets locally before you push changes, and for handing complete reports to a sub agent to fix issues.
To create and run the Playwright CLI skill, I fed the official Microsoft Playwright CLI docs and CLI patterns into my skill creator, added best practices, and installed the Playwright CLI globally as a dependency.
The skill follows a six phase flow to set up the database, start the server, provision, log in, test, clean up, and assemble a report. Side by side, MCP pushes full page data into the model’s context at every step which inflates tokens and reduces reasoning space, while CLI only posts a short summary and a file path to the full page map, then loads details on demand.
What Playwright does
Playwright gives your AI agent hands and eyes in the browser. It can navigate, click, fill forms, and take screenshots. I use it to let Claude or any AI agent operate the app reliably.
There are three ways to use it. The standard way is writing test files, which developers have done for years. The newer MCP server works, but Microsoft now recommends the CLI because it is more capable and more efficient.
Why CLI beats MCP on tokens and accuracy
Think of Claude’s context window like a desk. Everything you add to the desk takes space away from code and reasoning. If you stuff the desk with raw page data on every step, accuracy falls as tokens rise.
How MCP behaves
MCP loads the full tool instruction menus, then dumps the entire page state into the context every time the agent navigates or clicks. After each step, the whole accessibility tree goes back into the context again. After a ten step flow, the context is crammed with instructions plus every page snapshot, which drives up tokens and degrades decisions.
How CLI behaves
CLI writes a sticky note to the desk, not the whole binder. It posts a short summary and a path to a saved YAML file that contains the full page map, and the agent reads the file only if it needs details.
This dramatically cuts token use and leaves more headroom for code understanding and planning. The agent often needs to read only a fraction of pages in full, so it spends less on tokens while thinking better. For prompt design and tool usage that complements this approach, see our notes on the best way to use Claude Code.
Accuracy trade offs to know
MCP is like autopilot that always looks at the full page, so it never misses visible signals forced into the context. That is helpful on unknown pages or bug hunts where any subtle visual change matters. CLI can miss a subtle on page error if the summary looks fine and the agent does not open the full YAML, so you pick CLI when the agent already knows what to expect, and MCP when it needs to watch every detail.
Skills overview and setup
I built two skills, one for Playwright MCP and one for the Playwright CLI. Both run headless and both are called by the agent, but the MCP skill calls MCP tools while the CLI skill issues shell commands. Install the Playwright CLI globally so the skill can call it anywhere.
Both skills share the same viewport. The flow is six phases that set up the database, start the server, provision the environment, log in, test, and then clean up and create a report. I will show the exact flow I run against Jira tickets and local apps.
Read More: How To Install Claude Code In Antigravity
End to end Jira verification
I grab a Jira ticket from the scrum board and pass it to Claude through the QA Playwright CLI skill to verify locally. The agent fetches the ticket title and description using the Jira MCP, understands the context, and plans what to test. It then ensures the Supabase test user exists, and if not, creates it.
From there it runs Playwright CLI commands to open the app, set the viewport, and log in using the email, password, and the sign in element references from the page map. Login succeeds and it navigates to the dashboard. It uploads a file from a test assets folder, verifies the upload, and continues.
At the end, the skill assembles a detailed report. In my run, time was not fetched from the receipt which means the AI failed to extract it, there was no option to add a receipt time, and one part was not reproducible. The report marks the outcome as partially complete, lists the issues found, and attaches the exact reproduction steps with screenshots.
The screenshots show the dashboard, the receipt page after upload, the edit receipt dialog, the time field, and the final saved state. Because the CLI saves a YAML map of the page instead of dumping raw HTML, the file is compact and readable. Each element includes a stable reference so the agent knows exactly where to click without parsing the full DOM.
Logs are saved along with screenshots and YAML maps, so you can trace every step. I run the same scenario with the MCP skill as a comparison. Both produce a report, but you can clearly see the CLI consumes fewer tokens than the MCP approach.
Practical skill creation notes
I built the CLI skill with my skill creator. I passed in the official Playwright CLI docs plus CLI usage patterns, and the creator embedded best practices into the tool calls.
Dependencies matter. Install the Playwright CLI globally and keep your test assets organized for uploads and fixtures. Both skills share the same viewport so comparisons are apples to apples.
Step by step flow to run the CLI skill
Set mode to testing locally and switch the run mode to verify for a specific Jira ticket ID. The agent calls the Jira MCP to fetch the ticket summary and description, then plans the test from the acceptance details. It checks or creates the Supabase user required to log in.
The agent issues CLI commands to open the login page, read the page summary, open the YAML if needed, and fill form fields. It clicks the submit button, takes a screenshot, and saves it. It navigates to the next page, repeats the pattern, uploads files, and captures evidence on each action.
It reads only the pages it must read in full which is why token use stays low and reasoning stays high. At the end, it generates a verification report that you can pass to a sub agent to implement a fix. You can rerun the same skill after the fix to confirm resolution.
Read More: Claude Code Vs Antigravity
When to pick CLI vs MCP
Pick CLI when the agent already knows the app’s structure, flows are predictable, or you want to keep token use tiny while boosting reasoning on code and plans. Pick MCP when you need to inspect unknown pages or track subtle on page errors at every step.
Use CLI for login flows, CRUD checks, and regression verification, and use MCP for exploratory scenarios and error driven flows. That balanced approach gives you speed, lower cost, and fewer blind spots.
Sponsor note on TestSprite
TestSprite is an AI agent built for software testing that reads your code base, understands your documentation, validates agent produced results, and generates a full report. I tested a budgeting app and it flagged a risk around in memory storage resetting on server restart because data lived in an array, which I then fixed. Many coding agents average around 42 percent accuracy, and teams report TestSprite MCP helps push feature delivery accuracy up to 93 percent.
Embed QA in a larger workflow
I embed this QA step into a bigger workflow that reads a ticket, researches, plans, implements, and reviews. I run the CLI verification first to confirm the bug exists, then run it again after implementation to confirm the fix. You can orchestrate the whole loop with Claude Code and a bundle of MCP tools and skills for consistent delivery.
Final thoughts
Playwright CLI wins on tokens, accuracy, and features by summarizing pages to disk, reading details only when needed, and keeping the model’s context clear for reasoning. MCP still shines for exploratory accuracy across unknown flows. I keep both skills ready, but I default to the CLI skill for fast, headless, low token QA that produces clear, sharable reports.