Browser & mobile automation

Why a tester should care

Traditional agent-driven browser automation took a screenshot and asked a vision model where to click. That is slow, expensive, and non-deterministic. Playwright MCP instead hands the model an accessibility snapshot: a structured tree of roles, names, and stable element references. The model then says "click the button with ref e17", which is exact.

The QA consequence is significant. Because the agent is reasoning over roles and accessible names, the specs it writes naturally reach for getByRole('button', { name: 'Submit claim' }) rather than div.css-1x7k9 > span:nth-child(3). You get accessible-by-construction locators for free, and a spec that survives a CSS refactor.

Second-order benefit: if the agent can't find an element in the accessibility tree, that is itself a finding. An unlabelled icon button that the agent cannot address is an unlabelled icon button your screen-reader users cannot address either.

Tool surface

Wire it up

Claude Code, one line:

claude mcp add playwright -- npx -y @playwright/mcp@latest --isolated --browser chromium

Or as JSON config, for clients that use an mcpServers block:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y", "@playwright/mcp@latest",
        "--browser", "chromium",
        "--viewport-size", "1440,900",
        "--isolated",
        "--allowed-origins", "https://staging.example.com;https://api.staging.example.com",
        "--save-trace",
        "--output-dir", "./artifacts/playwright-mcp"
      ]
    }
  }
}

--isolated

Fresh in-memory profile per session. Use it: a shared profile leaks login state between runs and produces phantom passes.

--storage-state

The deliberate opposite — load a saved auth state so the agent starts logged in. Point it at a JSON file your normal auth setup already produces.

--allowed-origins

Origin allowlist. The strongest single guardrail here: the agent physically cannot navigate to production or to an attacker-controlled link found on a page.

--device

Device emulation, e.g. "iPhone 15". Cheap responsive checks without a device lab.

--save-trace

Writes a Playwright trace per session. This is your evidence artifact — attach it to the defect.

--headless

For CI. Keep it headed locally: watching the agent drive is how you catch it "succeeding" on the wrong element.

Workflows that actually pay off

1 · Explore-then-codify

The highest-value pattern, and the one most teams skip. Don't ask for a spec first — ask for exploration first.

The second prompt matters more than the first. "Run it, and iterate until green" is what separates an agent from a code generator: it closes the loop itself, and you review a spec that has already passed rather than one that merely looks plausible.

2 · Reproducing a bug report into a regression test

You end up with three artifacts from one prompt: a confirmed repro, a network/console trace that tells the developer why, and the regression test that stops it coming back.

3 · Accessibility sweep as a side effect

4 · Cross-device regression

Gotchas

• Snapshot size on heavy pages. A dense data grid produces a very large accessibility tree and can eat the context window in one call. Navigate to a narrower view, or ask the agent to snapshot after applying a filter.
• Generated specs drift toward the happy path. Agents write the flow they just walked. Negative cases, boundary values, and error states still need you to ask for them explicitly — and they are where the bugs live.
• browser_evaluate is a hole in your guardrails. Arbitrary JS in page context can set localStorage, call internal APIs, or bypass the UI entirely. Convenient for setup, but a test that reaches state via evaluate is not testing the UI. Watch for it in generated code.
• Non-determinism between runs. The same prompt won't produce the same click sequence twice. Conversational driving is for exploration; the committed spec is the regression asset. Never wire "ask the agent to test checkout" into CI.
• Page content is untrusted input. If the agent reads a product review, a support ticket, or a PDF rendered in the browser, that text is data — not instructions. Prompt-injection through user-generated content is a live risk for any browser-driving agent, and it matters more when the same agent also has write access to Jira or the database.
• First run downloads browsers. Budget for it in CI images, or pre-bake with npx playwright install --with-deps chromium.

Why a tester should care

Playwright tells you the test failed. Chrome DevTools MCP tells you the page fired a request that 404'd, blocked the main thread for 1.8 seconds, and shifted layout twice after first paint. It converts "the page feels slow" — the least actionable bug report in existence — into a trace with named insights and a number attached.

For a QA-to-AI engineer this is also the most useful server for root-causing your own flakes. A test that intermittently fails on a click is very often a test racing a slow XHR. The network panel shows you that in one call.

Tool surface

Wire it up

claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y", "chrome-devtools-mcp@latest",
        "--headless=false",
        "--isolated=true"
      ]
    }
  }
}

It can also attach to an existing Chrome instance started with a remote debugging port, which is how you point it at a session you've already logged into by hand — useful for SSO-gated apps where scripting the login is more trouble than it's worth.

Workflows

1 · Performance budget as an acceptance criterion

The comparison is the part that makes it a test rather than a measurement. A single LCP number is trivia; LCP versus the previous release is a pass/fail.

2 · The "nothing happened" bug

3 · Flake root-cause

4 · Third-party weight audit

Gotchas

• Traces are big. Ask for analysed insights, not raw trace dumps, or you'll fill the context window with JSON.
• Numbers move. Local performance measurements vary with whatever else your machine is doing. Treat single runs as directional; only trust deltas measured back to back under the same emulation settings.
• Chromium only. No Safari or Firefox story here. Pair with BrowserStack for real cross-browser performance.
• Overlaps with Playwright. Both can click and navigate. If you run both, tell the agent explicitly which one owns driving ("use Playwright to reach the state, DevTools only to measure") or it will thrash between them.

Why a tester should care

Be honest about the situation this solves. If you have 4,000 Selenium tests in Java, a Grid in your own data centre, and a compliance process that signed off on that stack, "just migrate to Playwright" is not advice — it's a two-year project. Selenium MCP lets an agent work inside that world: prototype a flow, confirm locator behaviour on a real WebDriver session, and hand you something that fits the existing page objects.

There's a second, less obvious use: the agent as a locator archaeologist. Point it at a page and ask which of your existing XPaths still resolve. Legacy suites accumulate dead selectors, and finding them by hand is miserable work.

Tool surface

Deliberately WebDriver-shaped, which is the point — the vocabulary matches what your existing suite already speaks: start_browser, navigate, find_element, click_element, send_keys, get_element_text, hover, double_click, right_click, drag_and_drop, press_key, upload_file, take_screenshot, close_session.

Locator strategies are the familiar set: id, css, xpath, name, tag, class. Note what's missing versus Playwright — there's no accessibility snapshot, so the agent is working from screenshots and its own guesses at selectors rather than a structured tree. That is the core trade-off.

Wire it up

claude mcp add selenium -- npx -y @angiejones/mcp-selenium

{
  "mcpServers": {
    "selenium": {
      "command": "npx",
      "args": ["-y", "@angiejones/mcp-selenium"]
    }
  }
}

Browser drivers must be resolvable on the host — modern Selenium handles most of this via Selenium Manager, but a corporate proxy will break that silently. Test start_browser before assuming the install worked. For Grid, the agent starts a session against your hub URL, so the same network access rules as your normal suite apply.

Workflows

1 · Locator audit

2 · Prototype before you write Java

3 · Migration triage

Gotchas

• No accessibility tree means guessier locators. The agent is inferring selectors rather than reading references. Review everything it produces; a locator that worked once may have matched by accident.
• Session leakage. Agents forget to call close_session. Orphaned browsers accumulate, and on a shared Grid that's someone else's outage. Check for stray sessions after long conversations.
• Community maintenance. Check the repo's commit activity before committing a team to it. This is not a vendor-supported product with an SLA.
• Don't run alongside Playwright MCP. Tool collision is near-certain.

Where it still fits

Three honest cases. First, you already have a Puppeteer codebase and want the agent to speak the same API. Second, you want a very small footprint for a scheduled headless check — "does the login page render and return 200" — where Playwright's browser matrix is overkill. Third, content extraction: pulling rendered HTML out of a JS-heavy page into the agent's context, where Fetch MCP would only get you the empty shell.

That third case is real and under-appreciated. If you're building test data or a RAG corpus from pages that render client-side, a headless browser is the only thing that works.

Tool surface

Small by design: puppeteer_navigate, puppeteer_screenshot, puppeteer_click, puppeteer_fill, puppeteer_select, puppeteer_hover, puppeteer_evaluate. CSS selectors throughout — no accessibility-tree reasoning, no built-in tracing, no network panel.

Wire it up

{
  "mcpServers": {
    "puppeteer": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-puppeteer"],
      "env": {
        "PUPPETEER_LAUNCH_OPTIONS": "{\"headless\": true, \"args\": [\"--no-sandbox\"]}",
        "ALLOW_DANGEROUS": "false"
      }
    }
  }
}

Workflows

1 · Post-deploy smoke

2 · Rendered-content extraction for test data

Gotchas

• Maintenance is on you. Archived reference, forks of varying quality. Pin a version and read the source before it touches anything sensitive.
• Scraping has rules. Respect robots.txt, terms of service, and rate limits. "The agent did it" is not a defence.
• No trace, no network panel. When something fails you get a screenshot and a shrug.

Why a tester should care

Mobile automation has historically been the worst developer experience in test engineering: Appium capability matrices, driver version drift, and a feedback loop measured in minutes. Maestro's pitch is declarative YAML flows with built-in waiting — no explicit sleeps, no WebDriverWait ceremony. The MCP server puts an agent in front of that.

The gateway architecture matters practically: the MCP server is a thin layer, and the actual device interaction is the same Maestro CLI your CI already runs. Flows the agent authors are ordinary .yaml files you commit — no separate agent-only execution path. That is exactly the property you want, and it's what makes generated mobile tests trustworthy.

Tool surface

Wire it up

Install the Maestro CLI first — the MCP server is a subcommand of it, not a separate package.

curl -fsSL "https://get.maestro.mobile.dev" | bash
maestro --version

{
  "mcpServers": {
    "maestro": {
      "command": "maestro",
      "args": ["mcp"]
    }
  }
}

Prerequisites are the usual mobile ones and they are the real install cost: Android SDK plus a configured emulator (or a device with USB debugging), and for iOS, Xcode with a booted simulator on macOS. Windows users testing iOS still need a Mac somewhere — MCP does not change that.

Workflows

1 · Author a flow by doing it

"Run it twice" is not padding. A mobile flow that passes once and fails the second time is the most common failure mode, usually an animation or a permission dialog on first launch.

2 · Permission and interrupt handling

3 · Cross-platform parity

That last question is the valuable one — parity testing frequently surfaces accessibility labelling that one platform team did and the other didn't.

Gotchas

• Environment setup dominates. Ninety percent of the pain is SDKs, emulators, and signing. The MCP layer is the easy part; budget accordingly.
• Emulators are not devices. They won't reproduce thermal throttling, real network conditions, biometric hardware, or manufacturer skins. Pair with BrowserStack for the real-device matrix on anything user-facing.
• Screenshot-driven tapping is fragile. Push the agent to inspect_view_hierarchy and address elements by accessibility id. Tapping coordinates derived from a screenshot breaks on the next device size.
• iOS needs macOS. No way around it.