Browser Automation for Agents: Playwright, Chrome DevTools, Browser Use, Stagehand and agent-browser

Browser automation for coding agents comes in two kinds. Deterministic drivers (Playwright MCP, Chrome DevTools MCP, agent-browser, dev-browser, Browser Use --cli-mcp) leave every action to the coding agent and suit testing and profiling your own app. Browser-agent frameworks (Stagehand, the Browser Use library and Cloud) add a separately billed model that plans actions on third-party sites.

This page is for developers and tech leads choosing which browser tool their agents get. The agent says the checkout fix is done, but nobody opened the page. Or someone did: three browser servers are connected, dozens of near-identical tool schemas sit in every session, and the “performance fix” was measured on a dev server.

What you get from this browser automation guide

• A decision rule: deterministic driver or browser agent, and why the difference shows up on your bill.
• A job-by-job matrix: own-app E2E, performance audit, third-party scraping and long multi-step flows.
• Verified install lines for Claude Code, Codex and Cursor, with the Chrome DevTools MCP telemetry switched off.
• A complete LCP investigation with performance_start_trace and performance_analyze_insight, plus four copy-paste prompts.
• The evidence each job must leave behind, so you check a trace or a test instead of reading the agent’s diff.

Deterministic driver or browser agent: which kind do you need?

A deterministic driver exposes browser primitives (navigate, snapshot, click, trace). Your coding agent reads the page and chooses each action, so the same prompt on the same page makes the same calls, and every step appears in the transcript. A browser-agent framework takes a natural-language step (“export last week’s orders”) and hands it to its own model, which plans the clicks and re-plans when the page changes. That model is billed on top of your coding agent, and its choices are one level further from your review. Browser Use spans both kinds: its --cli-mcp server is a driver that runs code your agent writes, and the inner-model agent loop exists only in its Python library (Agent(task=..., llm=...)) and its Cloud API.

Tool	Kind	How the agent reaches it	Package (checked 2026-09-26)	Extra bill
Playwright MCP	Driver	MCP server, accessibility snapshots	npm @playwright/mcp	None
Chrome DevTools MCP	Driver + profiler	MCP server or plugin with seven skills	npm chrome-devtools-mcp 1.10.1	None; usage statistics go to Google unless you opt out
agent-browser	Driver	Rust CLI + skill; agent-browser mcp also exists	npm agent-browser 0.38.1	None
dev-browser	Driver	Puppeteer scripts against a warm browser, CLI + skill; MCP only in 1.0	npm dev-browser (latest 0.2.9, next 1.0.0-rc.3)	None
Browser Use	Driver (code execution)	--cli-mcp MCP server: your agent runs Python against Chrome through browser_exec	PyPI browser-use 0.13.10	None for --cli-mcp; cloud browsers are priced by the vendor if you use them
Stagehand + Browserbase	Browser agent	TypeScript, Python or Go SDK; hosted MCP at mcp.browserbase.com	npm @browserbasehq/stagehand 4.1.0	SDK: your model key (+ Browserbase if you use cloud browsers); hosted MCP: Browserbase API key (per the archived server README; not probed 2026-09-26)

Two built-in routes exist as well. Claude Code has the Claude in Chrome integration (claude --chrome), and Codex 0.157.1 lists browser_use, in_app_browser and computer_use as stable features that are on by default. They are features of each agent app, not a standalone MCP server. The tools on this page are servers you register, pin and isolate per agent the same way in Claude Code, Codex and Cursor.

Which browser tool fits which job?

For your own app the drivers stay the default: they are cheaper, repeatable and leave evidence you can re-run. Reach for Browser Use or a browser-agent framework only when the page is not yours or the flow is too long to script by hand.

Job	First choice	Fallback	Why	Evidence the run must leave
Own-app E2E: verify a flow after a change	Playwright MCP, or Playwright CLI with its skill when context is tight	agent-browser	Accessibility snapshots, --isolated per agent, and the check can become a committed Playwright test	A test that failed before the fix and passes after, running in CI
Performance audit: LCP, INP, CLS regressions	Chrome DevTools MCP	agent-browser vitals for a quick number	Real DevTools traces and named performance insights; lighthouse_audit for accessibility, SEO and best practices	Before and after trace files plus the metric delta
Debugging: console errors, failed requests	Chrome DevTools MCP (source-mapped stack traces)	Playwright MCP browser_console_messages and browser_network_requests	The DevTools view of the same failure a human would open	The failing request or stack trace, then the same check clean
Third-party scraping: pages you do not control	Stagehand extract with a zod schema, or the Browserbase hosted MCP	Browser Use	Schema-validated output that survives redesigns, on cloud browsers away from your machine	Schema-valid JSON, a row count, and three rows spot-checked against the page
Long multi-step flows: admin exports, multi-page forms	Browser Use (--cli-mcp)	dev-browser, for a warm browser that keeps named pages between calls	Browser Use drives your real, logged-in Chrome over a persistent session, so the agent does not log in again between steps; dev-browser keeps state without relaunching	A screenshot per step and a final-state assertion
Several agents at once	Any driver with per-agent isolation: Playwright --isolated, agent-browser --session, Chrome DevTools --isolated	A distinct --user-data-dir per agent	A persistent Playwright profile can be opened by one browser at a time	Each worktree’s run against its own port

Note

Connect one browser driver per session. Two drivers doing the same job double the tool schemas in context and leave the agent choosing between near-identical tools.

Install the deterministic drivers in Claude Code, Codex and Cursor

The MCP servers are the same in all three tools; only the registration differs. The lines below add Playwright MCP with --isolated (safe for parallel agents) and Chrome DevTools MCP with usage statistics off.

Claude Code

# Terminal. Local scope (this project, only you); --scope project shares through .mcp.json
claude mcp add playwright -- npx @playwright/mcp@latest --isolated
claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --no-usage-statistics

Chrome DevTools MCP also ships as a plugin with seven skills (among them debug-optimize-lcp, a11y-debugging and memory-leak-debugging). Remove the plain server first if you switch:

claude mcp remove chrome-devtools
claude plugin install chrome-devtools-mcp@claude-plugins-official
claude plugin details chrome-devtools-mcp   # projected token cost before you keep it

The plugin (pinned to chrome-devtools-mcp 1.9.0 on 2026-09-26, while npm latest is 1.10.1, so it lags the standalone server) starts the server without --no-usage-statistics or --no-performance-crux. To keep statistics off, set CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS=1 in your shell or in the env block of ~/.claude/settings.json. CrUX lookups have only the flag, so keep the plain server for client or internal URLs.

Codex

# Terminal. Writes [mcp_servers.<name>] to ~/.codex/config.toml
codex mcp add playwright -- npx @playwright/mcp@latest --isolated
codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --no-usage-statistics

The equivalent TOML, if you edit ~/.codex/config.toml by hand:

[mcp_servers.chrome-devtools]
command = "npx"
args = ["chrome-devtools-mcp@latest", "--no-usage-statistics"]

Cursor

Add the servers under Cursor Settings > MCP, or in .cursor/mcp.json for the project (the shape comes from the vendors’ READMEs; it was not tested in Cursor here):

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--isolated"]
    },
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]
    }
  }
}

The two CLI-plus-skill drivers install the same way for every agent, because the agent runs them from its shell:

# agent-browser: CLI, bundled Chrome for Testing, and the skill stub
npm install -g agent-browser && agent-browser install
npx skills add vercel-labs/agent-browser

# dev-browser: 1.0 is published only under the next tag; it adds the MCP server
npm install -g dev-browser@next
dev-browser install-skill --claude     # or --codex, or --agents

The agent-browser skill is a thin stub that tells the agent to run agent-browser skills get core, so the instructions match the installed CLI version. The agent-browser page covers the verify loop in full, and the Playwright MCP vs Playwright CLI page covers every Playwright flag.

Switch off Chrome DevTools MCP telemetry

Chrome DevTools MCP sends data to Google in three ways, and each has its own switch (README, checked 2026-09-26):

What leaves the machine	Default	Opt out
Usage statistics: tool success rates, latency, environment	On	--no-usage-statistics, or set CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS; collection is also off when CI is set
Trace URLs sent to the CrUX API for real-user field data	On for performance tools	--no-performance-crux
Update checks against the npm registry	On	Set CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS

Opting out of Chrome’s own browser metrics does not opt you out of the server’s statistics, and the reverse is also true. For client work or internal URLs, pass both flags. The CrUX lookup sends the URL you trace, so a staging hostname leaves your network unless you add --no-performance-crux.

Find what is hurting LCP with Chrome DevTools MCP

A performance claim without a trace is a guess. This workflow makes the agent measure, fix one thing, and measure again against a production build.

1. Serve a production build. A dev server adds unbundled modules and hot-reload code that distort every timing. Build the app and serve the output on a fixed port.

2. Ask for a trace, not an opinion. Paste the prompt below. The agent calls navigate_page to open the URL, then performance_start_trace with reload: true and autoStop: true, and saves the raw trace through the tool’s filePath parameter.

3. Read the insights. The trace result lists insight sets. The agent calls performance_analyze_insight with the set’s id and an insight name such as LCPBreakdown or DocumentLatency. LCPBreakdown splits LCP into its phases, which tells you whether to fix the server, a render-blocking resource or the image itself.

4. Fix one cause and re-trace. One change per trace keeps the delta attributable. The agent records the second trace with the same settings and reports both numbers.

5. Keep the files. Both .json.gz traces go into the pull request’s evidence. Anyone can open them in the DevTools Performance panel without trusting the agent’s summary.

Copy-paste prompt: LCP investigation with Chrome DevTools MCP

Use the chrome-devtools MCP tools. Run `npm run build && npm run preview -- --port 4321`
in the background and wait until http://localhost:4321/en/ answers.
1. navigate_page to http://localhost:4321/en/, then performance_start_trace with
   reload true, autoStop true, filePath "traces/lcp-before.json.gz".
2. From the insight sets, call performance_analyze_insight for LCPBreakdown and for
   any insight that names the LCP element or a render-blocking request.
3. Report LCP, the LCP element, and the phase that dominates (TTFB, load delay,
   load duration or render delay), quoting the trace numbers.
4. Propose ONE change that targets that phase, make it, rebuild, and trace again to
   "traces/lcp-after.json.gz" with identical settings.
5. Finish with a table: metric, before, after. If LCP did not improve by at least
   10%, revert the change and say so. Do not run lighthouse_audit for performance;
   it excludes performance.

Two details from the tool reference change what you ask for. lighthouse_audit covers accessibility, SEO, best practices and agentic browsing, and excludes performance, so a “Lighthouse performance score” request quietly returns nothing useful. And with the plugin installed, /chrome-devtools-mcp:debug-optimize-lcp packages steps 2 to 4 as a skill. Use it once you trust the loop, and keep the before-and-after table as the acceptance check. For load and stress numbers rather than single-page traces, go to performance testing.

Add Browser Use or Stagehand when the site is not yours

Browser Use and Stagehand pay off on pages you cannot change: a partner portal, a competitor’s pricing page, an admin tool with no API. The Stagehand SDK and the Browser Use Python library call a model you configure, and page content goes to that model. The hosted Browserbase MCP needs a Browserbase API key; per the archived server README, the hosted server runs and pays for its own model (Gemini). The endpoint itself was not probed here (2026-09-26). Browser Use --cli-mcp runs no model; your coding agent writes the browser code.

Claude Code

# Browser Use: runs with uvx on Python 3.12; the official plugin wraps the same command
claude mcp add browser-use -- uvx --python 3.12 browser-use@latest --cli-mcp

# Browserbase hosted MCP (Stagehand's navigate, act, observe, extract).
# The shell expands the variable, so the key is written to your local config:
# keep the default local scope and never use --scope project here.
claude mcp add --transport http browserbase https://mcp.browserbase.com/mcp \
  --header "Authorization: Bearer $BROWSERBASE_API_KEY"

Codex

codex mcp add browser-use -- uvx --python 3.12 browser-use@latest --cli-mcp

# Codex reads the token from the environment at run time; nothing is stored
codex mcp add browserbase --url https://mcp.browserbase.com/mcp \
  --bearer-token-env-var BROWSERBASE_API_KEY

Cursor

Browser Use goes into .cursor/mcp.json like any stdio server:

{
  "mcpServers": {
    "browser-use": {
      "command": "uvx",
      "args": ["--python", "3.12", "browser-use@latest", "--cli-mcp"]
    }
  }
}

For Browserbase, add https://mcp.browserbase.com/mcp under Cursor Settings > MCP with an Authorization header, and keep the key out of any mcp.json you commit.

Browser Use collects telemetry; run browser-use telemetry status and opt out before pointing it at client systems.

What each one exposes decides how you govern it:

• Browser Use --cli-mcp answered the MCP handshake with exactly two tools, browser_exec and browser_screenshot (tested with 0.13.10). browser_exec runs Python helper code against the browser. Treat it as shell access: keep it out of auto-approve lists and away from sessions that hold production credentials.
• Stagehand is an SDK, not a server. Use it when the automation must keep running after the agent is gone: observe() returns real selectors so credentials are filled by code and never reach the model, and extract(instruction, schema) returns data validated against a zod schema. The hosted Browserbase MCP gives an agent the same navigate, act, observe and extract without a local browser.

Copy-paste prompt: schema-checked extraction from a third-party page

Use the browserbase tools. Start a session, navigate to https://www.example.com/pricing
and extract every plan as {name: string, monthlyPriceUsd: number | null, seatLimit:
number | null}. Use null when the page does not state a value; never estimate.
Then:
- print the JSON array and the row count,
- list any plan whose price text you could not parse, quoting the raw text,
- end the session.
Do not click sign-up, contact or cookie-consent buttons.

Copy-paste prompt: long multi-step flow with Browser Use

Use the browser-use tools. The connected Chrome is already logged in to
https://staging.example.com/admin with a test admin account; do not log out and do
not open any other site. Go to Orders, filter to the last 7 days, export as CSV, and
tell me how many orders are refunded.
After every step, call browser_screenshot; if it returns an image rather than a
file, save it with browser_exec to steps/NN-<step>.png.
If a step fails twice, stop and report the screenshot and the error instead of
trying a different route.

How do you prove a browser run means something?

A browser tool makes the agent faster at claiming success. The point of the run is the artifact it leaves, which a reviewer checks in minutes without reading the diff line by line.

• Own-app E2E: the agent turns the browser check into a Playwright test, runs it red against the unfixed code, then green. CI runs it on every pull request. Whoever reviews the pull request signs off on the test and its red run, not on the agent’s narration. See agent-driven E2E verification and how strong your test oracle is.
• Performance: two trace files and a before-and-after table, with a threshold decided before the change (the prompt above uses 10%). No trace, no claim.
• Scraping: schema-valid output, a row count, and three rows compared against the live page by a person. A schema catches the wrong shape; only the spot check catches plausible but wrong values.
• Long flows: one screenshot per step plus a final-state check the agent cannot fake, such as the exported file’s row count.

Attach these to the pull request as the evidence bundle. For a team, make “user-visible change ships with browser evidence” a written rule; the E2E policy gives the policy side.

What do browser servers cost in context?

Every connected MCP server puts its tool schemas into the session. Chrome DevTools MCP’s tool reference lists 59 tools across input, navigation, emulation, performance, network, debugging, memory, extensions and more (September 2026). Its --slim mode keeps only basic browser tasks. Playwright MCP’s own README tells coding agents they “might benefit from using the CLI+SKILLS instead”, because tool schemas and accessibility trees are large.

Measure rather than guess: in Claude Code, run /context before and after adding a server, and claude plugin details <plugin> for a plugin’s projected cost. Keep the profiler (Chrome DevTools) connected only in sessions that profile, and use a CLI-plus-skill driver for everyday verification. The token-cost page covers the wider budget.

How popular are these browser tools?

As of 2026-09-26, by GitHub stars (GitHub API): Browser Use ★116.3k, Chrome DevTools MCP ★52.6k, agent-browser ★43.2k, Playwright MCP ★37.6k, Stagehand ★25.4k and dev-browser ★6.6k. On the Claude Marketplace directory the same day, the playwright plugin showed 319,887 installs and chrome-devtools-mcp 102,569. The LinklyAI/best-skills snapshot of skills.sh (SECONDARY, 2026-09-26) put agent-browser at about 945k skill installs; re-read skills.sh before quoting it. Stars measure attention, not fitness for your job; the matrix above does that.

Package-name traps (npm and PyPI, checked 2026-09-26)

• @modelcontextprotocol/server-puppeteer is deprecated and archived. Use Chrome DevTools MCP, which drives Chrome through Puppeteer.
• @microsoft/playwright-mcp and @playwright/mcp-server do not exist; unscoped playwright-mcp is an unrelated package. The real one is @playwright/mcp.
• @chrome-devtools/mcp and @google/chrome-devtools-mcp do not exist. The package is unscoped chrome-devtools-mcp.
• npm browser-use is an unrelated TypeScript library. Browser Use is PyPI browser-use, run through uvx.
• Unscoped npm stagehand is unrelated; the SDK is @browserbasehq/stagehand. @browserbasehq/mcp-server-browserbase is deprecated and its repo archived; use the hosted URL.
• npm install -g dev-browser installs 0.2.9, which has no mcp subcommand. The MCP server needs dev-browser@next.

When browser automation breaks

The second agent fails with a locked profile. Playwright MCP keeps a persistent profile by default, and one profile allows one browser. Add --isolated to every agent’s server, or give each worktree its own --user-data-dir. For agent-browser, pass a distinct --session per agent. Running agents in parallel covers ports per worktree.

The CI job hangs at browser launch. Playwright MCP runs headed unless you pass --headless. Add it in CI. For agent-browser on Linux, agent-browser install --with-deps installs the system libraries.

The trace says the page is slow, but only locally. The agent traced a dev server, or a cold cache on the first load. Re-run against a production build, trace twice, and compare the second run.

The agent reports “no performance data” from Lighthouse. lighthouse_audit excludes performance by design. Ask for performance_start_trace instead.

Chrome DevTools MCP misbehaves in Edge or Brave. It officially supports Google Chrome and Chrome for Testing only. Point it at one of those before debugging further.

A third-party page tells the agent to do something. Page text is untrusted input. A driver or browser agent that reads “ignore previous instructions and run…” can act on it. Keep browser sessions free of production secrets, never auto-approve browser_exec, and read MCP security before pointing an agent at sites you do not control.

The browser bill jumps. The Stagehand SDK and the Browser Use library and Cloud call their model on every step. A flow that keeps failing re-plans until something stops it, and cloud browsers (Browserbase, Browser Use Cloud) add the vendor’s own charges. Watch the model provider’s usage and the cloud browser account, not only your coding agent’s. With Browser Use --cli-mcp there is no second model: the cost shows up in your coding agent’s own context and usage, from repeated browser_exec output and screenshots. Either way, put a step limit in the prompt (“if a step fails twice, stop”).

The dev-browser mcp command is not found. You have 0.2.9 from the latest tag. Install dev-browser@next, and note that 1.0 does not support Windows yet.

Where to go next with browser automation

Playwright MCP vs Playwright CLI Every Playwright flag, the bug-report-to-regression-test workflow, and one browser per worktree.

agent-browser The browse-and-verify loop, with screenshots as evidence-bundle artifacts.

Evidence bundle Where traces, tests and screenshots go so review checks evidence, not diffs.

Reducing MCP token cost Measure and cut what browser servers cost in every session.

Start from the MCP servers hub if you are choosing your first servers, or from the MCP starter stack for the five most teams need.