AI-Driven E2E Testing with MCP Servers: The Steps

AI-driven E2E testing with MCP servers means giving a coding agent live browser tools, then having it walk a flow in a real browser and write the end-to-end test from what it observed. The MCP server is the connection between the model and the browser. It is not the part that decides what to test, and that distinction is where most of these setups succeed or fall apart.

End-to-end suites are the most expensive tests a team owns. Every case needs a selector strategy, a login, seeded data, and a wait strategy that holds up under a slow CI runner. An agent with browser access removes the typing. It does not remove the deciding, and the teams getting value out of this are the ones that kept the deciding step explicit instead of hoping the model would infer it.

The pipeline, step by step

1. Write the test cases before the agent runs. The scope has to exist as text: a title, preconditions, steps, and the expected result for each case. Handing an agent "test the checkout page" produces the same failure mode as handing any generator a vague prompt, which is fifty well-formed cases covering whatever the model happened to notice. This is the step Casely covers: upload the spec or the screens, get structured cases with steps and expected results back, export them as Markdown, CSV, or XLSX.
2. Review the cases while they are still cheap to change. A wrong expected result at this stage costs one edit. The same wrong expected result after the agent has written twenty specs costs a rewrite of all twenty.
3. Pick the server for the job. Playwright MCP when the output is a spec file you keep. Chrome DevTools MCP when the output is a diagnosis: a performance trace, a heap comparison, a network-level answer about why the flow fails.
4. Give the agent the cases and a specific instruction. Something closer to: "Using these test cases, write E2E tests with Playwright MCP. For each case, walk the flow in the browser first, confirm every expected result with a verify tool before writing the assertion, and use browser_generate_locator for each element instead of inventing a selector." The two constraints that matter are walk before writing and generate locators rather than guess them.
5. Capture authentication once. Log in through the agent, save the session with the storage tools, and start every later run from that state with --storage-state. Without this, a third of every session is spent back on the login form and a third of the token budget with it.
6. Review the generated spec as code, then run it in the real runner. The agent's session proves the flow worked once, under its own hand. Playwright Test is what proves the spec is stable: retries, sharding, a trace per retry, a CI exit code.
7. Commit the spec and drop the session. What ships is a file in the repository. Everything else was scaffolding.

Free and open sourceCasely writes these cases for youAttach a spec and one file of your team's existing test cases in Claude. Casely copies your columns, names the gaps it found in the spec, and exports a single Excel file your tracker imports in one pass.Read the install docs→

What each server contributes

A common pairing is both at once. Playwright MCP writes and maintains the suite; Chrome DevTools MCP gets attached when a case fails for a reason the spec cannot explain, such as a timeout that turns out to be a third-party script blocking the main thread.

Where it fails

The agent asserts what it saw, not what was required. This is the failure that survives every other fix. An agent that walks a broken checkout writes a test asserting the broken behavior, and the suite goes green forever after. The expected results in the test cases are the only thing standing between you and a suite that certifies the bug. Skip step one and the pipeline is a very expensive screenshot of today's behavior.

Locators drift when the page has no test ids. With no data-testid attributes, generated locators fall back to roles and accessible names, and a copy change on a button breaks a test that was never about that button. Adding test ids before the first agent run is the highest-leverage thirty minutes in this whole workflow.

Waits get invented. Playwright's auto-waiting handles most of it, but an agent that hit a race once tends to paper over it with a fixed timeout. Grep the generated specs for hard waits before committing; they are the seed of every flaky suite.

Each case costs a full browser session. Snapshots of a heavy DOM are expensive in tokens, and a suite of two hundred cases is not something to regenerate every sprint. Generate once, then maintain the specs as code the way you would any other test file.

Two runs produce two different specs. The agent picks its own route through the page, so authoring is not reproducible. That is tolerable because the artifact is reviewed and committed. It would not be tolerable if the agent were the thing running in CI.

Neither server is a security boundary. The Playwright MCP project states that outright, and Chrome DevTools MCP warns that it exposes the browser's content to the client. Point either one at a staging environment with seeded data, never at production with a real admin session.

The app has to be running and seeded. An agent cannot conjure an order that the backend will accept. Test data setup stays a fixture problem, and it is usually the reason a promising first session stalls on case four.

What is worth automating

The mechanical half is a genuine handoff: exploring screens, finding locators that hold, converting a written case into a first-draft spec, and capturing auth once instead of on every run. That is hours of work per feature, and it is work nobody enjoys.

What stays human is the pair at each end. Deciding which scenarios matter and what each one should assert, before the agent starts. Reading the generated spec as code, after. An agent with a browser is a fast pair of hands on a suite you designed. It is a poor substitute for having designed one.