Playwright MCP + Claude AI: Experimenting Without Overpromising
As you probably know, Playwright is close to my heart, and I regularly test all newly appearing integrations for it. As a Test Architect, I stay up to date with new features and enjoy exploring them. In a previous post, I highlighted Cursor which I’ve been using for approximately a year and find useful in my everyday work.
Today, I’m going to show you how to integrate Cursor with Playwright MCP and what we can achieve from this integration. MCP seems interesting and allows us to extend default LLM capabilities. Although the library appeared relatively recently, I believe it’s worth checking out. I recommend that you read the article!
So what exactly is MCP?
MCP is a protocol created by the authors of Claude, one of the most popular LLMs. It allows us to integrate the LLM’s context window with additional tools that support integration by executing commands from within the context window. For UI test automation, this means we can perform actions directly from LLM’s context window when using a compatible library. This article is about Playwright MCP.
What can we do with Playwright MCP?
Playwright MCP is the official MCP implementation for Playwright, developed mainly by Microsoft Playwright team. Apart from this integration there are alternative versions – for instance, this one created by Karthik, who is the author of a popular youtube channel ExecuteAutomation about test automation which has interesting content. Interestingly, his implementation was available earlier than official Playwright MCP so you can come across other articles which describe the integration. Personally, I recommend using the official version, because this version is likely to be supported extensively. However, I appreciate Karthik’s efforts who shared his solution.
Playwright MCP enables us perform actions in the browser directly from LLM context windows. Here’s how it works: in a prompt, we describe what we want to do, then these actions are performed by Playwright MCP and if we want, we can also generate the test code.
What options are available in Playwright MCP?
https://github.com/microsoft/playwright-mcp
Currently, we can use Playwright MCP in two ways. The default uses snapshot mode, which relies on accessibility snapshots to understand the page structure.
Another way is using the vision mode, which is based on screenshots. It’s especially useful when the default mode doesn’t work properly. In this article, I won’t show the vision mode, but I’d like to cover that in the future.
How do you install Playwright MCP?
There are a few ways to install Playwright MCP. In this article, I’ll focus on Cursor, but the offical documentation also includes instructions for Visual Studio Code and other IDEs. To install Playwright MCP in the Cursor IDE, go to Cursor Settings and select MCP Tools. Cursor displays all available MCP servers, which seemingly help with configuration.
Adding a project to Cursor from the Github homepage
One available option is to click on „Add to Cursor” button on the Github page. After that, a popup should appear allowing us to add Playwright MCP to Cursor.
After expanding the panel, we can see which actions are supported by Playwright MCP. There are operations that enable interaction with the web browser.
Available actions in Playwright MCP
We can use most of the actions we already know from working with Playwright. Here are a few examples:
- Clicking
- Browser_click – allows clicking on a specific element.
- Snapshot (Accessibility Snapshot)
- Browser_snapshot – captures the DOM tree of the current page using an accessibility snapshot.
- Navigation
- Browser_navigate – navigates to a specific URL.
- Browser_navigate_back – navigates back from the current URL.
- Browser_navigate_forward – navigates forward to the next page.
- These are basic operations, that are familiar from typical browser usage.
Vision Mode
The vision model lets us view the page as a user would see it. It uses screenshots to analyze the user interface, which is especially useful when the standard mode (snapshot) isn’t sufficient.
Working with REST API?
Working with REST APIs (or other types of APIs) is probably not supported in Playwright MCP. There are a few threads where members of the Playwright community have asked about this functionality – for instance:
https://github.com/microsoft/playwright-mcp/pull/117
It’s worth mentioning that in Playwright MCP likely won’t support direct API control – as the community noted, its main goal is to perform actions in the browser.
Is it possible to pass an authorized state?
Yes, it’s possible to pass session storage, which contains information about the current user session. This allows us to reduce the number of login actions, which is especially useful for more complex authorization flows.
How is the element identified on the page?
Currently, elements are identified based on Aria Snapshot tree to which Playwright can access. Based on that, the element is selected for performing an action e.g., clicking on it.
https://github.com/microsoft/playwright-mcp/issues/103
We’re going to create a first test via MCP
We start from scratch by creating a new project and initializations. For that we need to use a command:
npm init playwright@latestAfter executing this command, Playwright prepares a basic project setup. Next, we can remove the example tests, that are created by default during initialization – although this step isn’t necessary, since we can also perform actions directly via the LLM context window by simply prompting what to do. On the other hand, I see a value in learning everything from scratch. I’ve seen candidates during technical interviews who couldn’t perform basic actions simply because they had never done them before. From my perspective, it’s valuable to start from the fundamentals.
In this post, I would like to start with an example associated with a demo ecommerce shop, which I use to perform the demo. I use SauceLabs Demo shop – it’s a simple online demo shop which is prepared by SauceLabs team – excellent to learn test automation ourselves.
Away we go
Our test uses the demo application available at saucedemo.com. You can also find the application on Github at the following URL https://github.com/saucelabs/sample-app-web
The first test we’ll write with the help of Playwright MCP will navigate to the login form. Afterwards, it will then use demo account credentials which are displayed directly on the login page. This already shows some of MCP’s potential – it will identify the data and use It on the test automatically.
The first step
First of all, We’ll add two distinct products to the shopping cart. The next step will be proceeding to checkout and filling in the address details. After that, we’ll verify the item total and final price. Finally, we we’ll complete the order and assert that the final order status is displayed.
After sending the prompt, I can see that MCP completed the request.
MCP without any problems could find this credentials which we need for the test.
On the application
After logging in, we see a screen that displays all available products. Playwright MCP has successfully logged us into the shop. The next step is product selection. In this prompt, I didn’t specify which products to choose, so Playwright MCP will select them randomly. In the context of automated tests, it’s generally better to base tests on specific products. However, adding a separate test case that select products at random can also be useful – especially for detecting unexpected edge cases.
At this point, MCP identifies the number of available items and selects a few, which are then added to the shopping cart.
After adding these products, MCP proceeds to add another product – ”the Sauce Labs Bike Light”. Then, it checks whether the cart icon displays the number „2”.
After these actions, Playwright MCP click on Checkout button, which moves us to a page for entering test adress data.
The next step is to move to the screen where we enter test address data for the order.
On the checkout form, Playwright MCP fills in the test data and clicks on Continue button. Then, we’re taken to a page contains information about the order.
At this step, Playwright MCP checks whether the items were added correctly and then navigates to the order overview screen.
At the end of the flow, we verify that the „Back Home” button is displayed correctly.
How does the generated code look ?
The generated code, as we can see, covers the entire e2e proccess within the test application. It starts with login and navigates through several stages of the checkout flow. Obviously, the code is far from the production ready. However, with a few follow-up prompts, the quality of the test can be significantly improved. Of course, It’s important to highlight that we still need to learn analyze and develop our technical skills.
The test ends on verifying of displaying the ”Back Home” button and there is an assertion that checks whether the element is visible.
The test completion
Generating the test code
What it’s important to know that if we want to save the generated code that we need to add it to the prompt. In our case I added to the prompt „Based on the previous actions generate the code”.
Is MCP a risk for test automation engineers?
From my perspective, it can paradoxically be a positive change. Over the past 10 years, I’ve worked on various test automation projects, and have been actively involved in the testing community. Over the years, I’ve seen many test automation projects fall short of expectations. I still see many projects that don’t use parallelism and run all tests on a single thread, which leads to slow execution. Others lack useful design patterns like the factory pattern, dependency injection, or test data preparation before UI tests.
Of course, some companies have excellent test automation setups. However, there’s always room for improvement—not because we’re bored, but because better tools and approaches are constantly emerging. Keeping up with everything isn’t easy.
Tools like MCP can help us work effectively. Currently, it’s still an early stage its value may seem limited, but it’s worth following these trends and seeing how they work for you. Try implementing it in one of your projects. Of course, in all my posts and presentations, I always try to emphasize the importance of improving our technical skills because LLMs & MCPs can be useful if we know how to use them and can verify whether the code they generated is at least of acceptable quality.
What are some other interesting test automation-related projects that use MCP?
ReportPortal MCPis one such project. As you probably know, I am a big fan and evangelist of ReportPortal, which is currently the best tool for displaying test automation results in a clear and intutive dashboard. It supports the majority of technologies such as Playwright, Selenium, Cucumber, SpecFlow, JUnit and many others. It also provides a REST API, so even if there’s no existing integration, you can easily build your own.
Additionally, ReportPortal includes machine learning mechanisms that simplify test analysis. Recently, the ReportPortal team shared their own MCP, which allows us to integrate with ReportPortal instance directly from the IDE and analyze tests results there.
https://github.com/reportportal/reportportal-mcp-server
What if we want to test more advanced pages?
In this case for exercise, we can use different apps, which we can set them up locally or on a remote server. A tremendous example is WordPress. It’s better known from being a CMS (content management system) for blogging but also we can easily set up a demo shop for learning more complex automated test cases.
What type of limitation do we have now?
- One of the biggest limitations is the size of context – when a test case is more advanced than it can provide to a situation when Playwright can’t generate the code or manage all of methods because context is too large. Also, it provides getting hallucinations.
- Playwright MCP can be recognized as a bot by some pages. Obviously, in a context of our own applications we can turn off these types of security checks.
- Next challenge can be related to more complex UI controls on the page. I tried to do some tests for a page which had shadow dom and I didn’t have a problem, but I think we can find somewhere the problem.
So, what other problems can you find?
For example, instead of adding two products, Playwright MCP ended up adding six.
To be fair, the prompt was misleading – it tried to set the quantity of each product to 2, even though the app only supports adding products with a fixed quantity of 1.
That might explain the actions didn’t behave as expected.
Still, the test completed successfully – even though the number of products was different from the initial expectation. The total price for all six products was calculated correctly, which shows robustness of the final step.
In this case, I didn’t include a command in the prompt to save the test, so the actions were only executed but not saved.
Lack of predictability
This point highlights a potential risk: even when using the same prompt, the result may vary. On the one hand, this flexibility can be useful – as long as the test performs the expected actions. On the other hand, the lack of determinism can cause the test to fail to generate or produce an incorrect result. To sum up, it’s crucial to review the prompt carefully and ensure it’s written correctly.
Summary
In today’s post, I show what MCP is and how we can integrate with LLM (in this case with Claude). I encourage you to experiment and personally, I follow all ideas and updates for this technology. In future posts I’m going to show other examples what we can achieve by Playwright MCP and other MCPs.
