Playwright MCP: how AI works with a real application
You ask a language model to write a login test and receive readable code. Without current context, however, the model may not know the field names, button labels or actual behaviour of the page. Playwright MCP allows it to work with a browser and prepare a draft based on the real application.
MCP stands for Model Context Protocol—a way for a language model to use an external tool. In this case, that tool is a browser controlled through Playwright.
What is the problem?
A model given only a written description of a scenario cannot see the current page. It may therefore propose selectors—the rules used to find a particular element—based on common patterns.
The result is predictable. The selectors do not exist and the test fails at the first step. Or, worse, the selectors do exist but point to the wrong element: the first button with similar text, for example, or a field in a different form on the same page.
A screenshot may add visual context, but on its own it may not reveal an element’s programmatic name, role or state. Structured information from the browser is useful for reliable interaction.
Unsuitable selectors are a common source of instability. Tests then fail after small interface changes, and the team loses time distinguishing an application defect from a test defect.
What Playwright MCP does about it
Playwright MCP gives the model tools for opening a page, clicking, completing a form and reading a structured snapshot of the page. The snapshot includes information such as element roles and accessible names, allowing the model to refer to elements it actually found in that state of the page.
In practical terms, the model can use the permitted tools to walk through a scenario. It opens the login page, reads the roles and labels of fields, moves to the basket and records the state after an order is submitted. The resulting code draft is then based on this acquired context.
This approach reduces the amount of guesswork. You still need to check whether the proposed selector uniquely identifies the correct element and whether it will remain suitable after a small interface change. User-meaningful roles and names, or agreed test attributes, are generally preferable to a brittle path through the HTML.
What is the output?
If we use MCP only during creation and maintenance, the output is standard Playwright code in your repository. Running the completed tests then requires neither the language model nor MCP.
This means that the tests:
- can run without AI, for example in CI/CD according to the project’s rules,
- can be read and modified by any developer familiar with Playwright,
- remain stored in your repository and, subject to the agreed handover, can be used without the AI tool.
This applies to the proposed way of using it. Other implementations may also use MCP or the model at runtime, so the solution architecture needs to be made explicit in advance.
Where AI is still not enough
Browser access helps with selectors, but it does not determine the business significance of a test. The model does not know your priorities unless they are included in the instructions, and it may propose a test without a useful assertion.
Playwright MCP is not a security boundary either. Access to pages, accounts, files and data must be restricted to what is necessary, and page content must be treated as untrusted input. The test draft therefore undergoes both expert and security review.
What you gain
- Less guesswork in the first test draft.
- Better context for selecting elements and reproducing the user scenario.
- A standard Playwright project that the team can read and continue to maintain.
Next step
Start with one scenario in an isolated test environment and compare the draft with a manually prepared test. If you would like to assess how Playwright MCP can be incorporated into your process appropriately and safely, use a no-obligation consultation.