Transcripted Summary
Welcome to station four. Up to this point, we have focused on the Playwright MCP and Playwright Test MCP. But as an SDET, you are about to hit a wall that many people do not talk about until they get the bill: the token crisis.
In our industry, it is no longer about learning how to use AI, but also about learning how to orchestrate AI effectively and cost efficiently.
# Why CLI Over MCP
Let's look at the documentation from the Playwright team at Microsoft. They do a good job of breaking down the difference between a Playwright CLI approach and a Playwright MCP approach.
Let's look at the first bullet about CLI. It says modern coding agents increasingly favor CLI-based workflows exposed as SKILLs over MCP, because CLI invocations are more token efficient. However, MCP remains relevant for specialized agentic loops.
By using the CLI, we avoid loading large tool schemas and accessibility trees into the model context.
# Getting Started in Two Steps
So how do we get started? We get started with the Playwright CLI with two steps.
Step one: install the CLI globally. You only do this once per machine, with the command npm install -g @playwright/cli@latest. This gives you the playwright-cli command anywhere on the system. Think of it as the bridge between your AI agent and the browser.
Step two: from inside your project directory, install the skills — playwright-cli install --skills. What this does is drop a set of skill files into your project. The skill files are markdown instructions that teach AI how to use the CLI.
Let's go over to VS Code and remove the X from the last station and save it. Now go to the terminal and run the first command. I'm going to copy and paste the command npm install -g @playwright/cli@latest. And it shows it changed three packages in three seconds.
To give our agent the capability to drive the browser, we run the second command: playwright-cli install --skills. And it mentioned too many arguments, expected zero and received one. It did that because I copied and pasted it — let me put two hyphens. It's a problem because I'm copying and pasting from another document when I need to just go and copy from GitHub. You see how it looks like one hyphen, and this is two? But let me just check and see anyway, and run again.
Bingo. Now we see workspace initialized and it shows where it was initialized. The skills installed: two, and it found Chrome. So at this point, we should see it in Claude. Yes — skills, Playwright CLI. That's where it is located.
These markdown instructions teach what commands exist, what the syntax looks like, how to read snapshots, and how to interact with elements by reference.
Let's open one of these files — how about we go to test generation. And we see it shows plan, generate, here at the top section. The CLI includes the same agentic strategy as the Playwright Test MCP, but it uses local snapshots.
# My Production Workflow
I was on the fence about using the Planner for Playwright CLI. I see it here, but I was on the fence because I was only using generate — when it first released, I wasn't sure. Therefore, on my projects, I used the Planner agent from Playwright Test MCP.
Earlier in the course, I mentioned my current daily workflow for our test scenarios relies on the Playwright Test MCP Planner agent to strategize, combined with the Playwright CLI to generate the automation scenarios. That setup delivered great results in our previous release. However, I am fully confident in stepping away from the Playwright Test Planner agent after some proofs of concept with the Playwright CLI on a few requirements on my job. Therefore, starting our next release, I am completely moving to Playwright CLI for both test planning and execution.
# Targeting a Negative Validation Test Case
In this demonstration, I am going to request AI to pull a test case from Inflectra SpiraPlan. Let's look at the test case real quick.
In our previous station, we used the Playwright Test MCP to process a happy-path student enrollment form, but a framework must protect data integrity at the gates. That's why for this demonstration, we are targeting a negative validation test case.
Test case 291 already failed. It has incidents. If I open up the incident within this test case, we will see how step five shows the failure, because it has an incorrect format for the email that was saved.
Now, going back to the test case that we're going to do for our agentic workflow — that's test case 290. It has detailed steps, and the detailed steps are for validating the first name and the last name, because we want to see how our agents build this validation to process required fields before anything hits our database.
So watch my screen as I enter the request into the chat window. Let me copy the request — it's pretty long. Go back to VS Code, pull up another Claude Code, and I'm going to paste the request.
Since this request is pretty long, let me just give you an overview of what it's talking about. This request connects Inflectra SpiraPlan to retrieve the steps for test case 290. Using the Playwright CLI skill engine, it executes a two-phase workflow that plans a document to highlight the workflow and identify gap scenarios. Finally, it converts the test case into a Playwright automation test.
Now, let's run.
# Reading the Output
Let me drag this to this screen so you can see what it's doing in the background.
Okay. So in the tree, we see the test registration form. We've got a test for 290. Line one is the // Created By AI accountability tag. If I scroll, we see every action and assertion routes into our existing login page and registration page objects. No raw selectors, no CSS, no XPath. The agent did not invent a page object file — it found the two page objects we already had and used them.
Now, here is the part I want to slow down on. Before writing the test, the agent drove the live application with Playwright CLI and saved the YAML snapshots instead of pasting the raw DOM into the conversation. That's what kept this run fast and cheap on tokens.
But the value is not the YAML file sitting on disk. It's what the agent found while producing it. Look at the test plan, which should be located under the test artifacts folder directory. Test case 290. We see the name. We see the live DOM verification, the primary core workflow, the steps. There it is — the identified gaps and negative scenarios.
So that's the framework. And with the framework, we have a plan for the application, a test that interacts with page objects, and a paper trail showing what was verified and what was flagged for later. This is how you build a framework that saves your organization token overhead while maintaining integrity.
Now that you have mastered Playwright MCP, Playwright Test MCP with three agents, and Playwright CLI, it is time to zoom out and look at this from a high-level leadership scale. In our final session, we are stepping into station five, where we will explore advanced strategy, the 80/20 automation split, and look at how to build dedicated code review sub-agents to automatically govern our repository.
