The Best MCP Servers to Control a Browser From Your Coding Agent (2026)

If you want your coding agent to use a browser, I'd start with Browser Harness. It runs in the Chrome you already have open, logged in as you. In our matched eval, run as its CLI and skill on a cloud browser, it scored the same as Playwright MCP and Chrome DevTools MCP with 2.1M median input tokens against their 4.4M and 6.7M. That made it the cheapest per task.

• Need clean throwaway sessions, or Firefox and WebKit? Use Playwright MCP.
• Debugging your own app's performance, network or console? Use Chrome DevTools MCP.
• Want one binary with an encrypted auth vault, a domain allowlist and action policies? Use agent-browser.
• Just want to hand one tab to an agent? Browser MCP is the quickest, but its MCP server has not had an npm release since April 2025.

Disclosure: we make Browser Use and Browser Harness, so Browser Harness goes first. Competitor facts come from their own repos and docs, checked October 18, 2026.

What this covers

All five give your agent step-level control: click, type, read, screenshot. Your agent plans every step. To hand off whole tasks, or if you already pay a cloud browser vendor, see the full MCP round-up.

The real difference is which browser they drive. Their own Chrome is clean and repeatable but logged out of everything. Your Chrome has your tabs and logins. Most do both with a flag.

Our matched eval

We ran four of these tools on 100 public tasks from BU Bench V2.1 (bu2-001 to bu2-100, half of its 200). Same agent for every tool: Codex CLI 0.144.6 with GPT-6 Luna on medium reasoning, web search off. Same fresh Browser Use cloud browser with a US proxy for every task. Same prompt except one line naming the tool, same frozen V2.1 judge. Agent failures were never retried; runner, browser and judge failures were rerun once (Browser Harness 3 tasks, Playwright MCP 4, Chrome DevTools MCP 6, agent-browser 0, per the Browser Harness README). Measured October 14, 2026.

Not everything here ran as MCP. Playwright MCP and Chrome DevTools MCP ran as MCP servers with default settings. Browser Harness ran as its CLI and skill, not as browser-harness-mcp. agent-browser also ran as its CLI and skill.

All numbers are per task. Agent cost is the model bill only, not browser, proxy or judge.

• Nobody won on score. Paired differences, Browser Harness minus each tool: Playwright MCP +0.4 points (95% interval -5.7 to +6.6), Chrome DevTools MCP -0.6 (-6.6 to +5.6), agent-browser +4.0 (-1.8 to +10.0). Every interval includes zero. Chrome DevTools MCP had the highest raw score, and that is noise too.
• Browser Harness used the fewest tokens. 2.1M median input tokens against 3.3M for agent-browser, 4.4M for Playwright MCP and 6.7M for Chrome DevTools MCP, with the fewest tool calls (42). That made it the cheapest per task: $0.042 against $0.056, $0.066 and $0.097.
• Playwright MCP and Chrome DevTools MCP were faster. 8.3 and 8.7 minutes median against 9.0 for Browser Harness. agent-browser was slowest at 11.3.

Why the token gap? I don't know for sure, we did not isolate it. Part of it is probably MCP overhead: both CLIs came in under both MCP servers, and Playwright's own README argues that CLI calls skip large tool schemas. But agent-browser is also a CLI and still used about 1.6x Browser Harness's tokens, so being a CLI is not the whole story. We did not run browser-harness-mcp, so I can't give you its token count.

Limits: one run per task, 100 of 200 tasks, one agent and one model, and a fresh cloud browser every time, not your logged-in Chrome. A first agent-browser pass was thrown out because a setup bug on our side let it skip the shared cloud browser; the table has the corrected rerun. Versions, method and every per-task score are in the data file.

The tools

1. Browser Harness

Browser Harness is our open-source tool for letting Claude Code, Codex, Cursor or anything that can run a shell command use your real Chrome. It talks to Chrome directly over the Chrome DevTools Protocol (CDP). No Playwright, no extension. A background daemon holds one connection to your whole Chrome, and the tab it controls gets a horse emoji at the start of its title. Its skill tells the agent to open its own tab first with new_tab, which doesn't switch the tab you're looking at. Skip that step and the first navigation can land in a tab you already had open. When the agent needs a helper that does not exist yet, it writes one, so the harness gets better with each task.

It has no built-in page snapshot tool. The agent reads the page through browser_page_info, screenshots saved to a file, JavaScript, or raw CDP calls like Accessibility.getFullAXTree. Clicks are coordinate clicks sent as CDP mouse events, so they go through iframes, shadow DOM and cross-origin frames.

The setup we measured is the CLI plus a skill. Paste this into Claude Code or Codex and the agent installs it:

Install or upgrade browser-harness to the latest stable version with uv using Python 3.12, register the skill from `browser-harness skill`, and connect it to my browser. Ask whether I want local browser recordings enabled; default to no and preserve my existing preference on upgrades. Follow https://github.com/browser-use/browser-harness/blob/main/install.md if setup or connection fails.

One-time Chrome step: open chrome://inspect/#remote-debugging and tick "Allow remote debugging for this browser instance". On Chrome 144+ you then click Allow once per connection. On macOS, browser-harness mac-approve clicks it for you.

MCP-only clients (Cursor, for example): browser-harness-mcp exposes the same helpers as 23 tools, from browser_click and browser_type to browser_js and raw browser_cdp. Every tool returns JSON. We did not measure this path.

claude mcp add browser-harness -- uvx --from 'browser-harness[mcp]' browser-harness-mcp

It is MIT and free in your own Chrome, no API key. The CLI, not the MCP server, can also start Browser Use cloud browsers at $0.02 per browser-hour, with residential proxy traffic at $5/GB on by default. The MCP docs only cover your local Chrome.

Where it bites:

• The agent sees your whole logged-in Chrome, not a sandbox or a chosen tab.
• One daemon has one attached tab. Two agents acting at the same time can race and act on the wrong tab, so serialize them or give each a cloud browser.
• No clean-profile mode is documented for the MCP server, and no Firefox or WebKit.
• PyPI is at 0.1.13 from September 4, behind the repo's main branch, and the package is marked alpha.
• Telemetry is on by default. browser-harness telemetry disable turns it off.

I use it when the task needs my logins and I don't want to export cookies into some other browser. If I need a sandbox, I pick something else from this list.

2. Playwright MCP

Playwright MCP is Microsoft's MCP server for Playwright. It reads pages through structured accessibility snapshots, not screenshots, so it works without a vision model. browser_snapshot returns the tree, and actions target element refs from it. Coordinate clicks only come with --caps=vision. About two dozen tools are on by default, with more behind --caps: network mocking, storage, tracing, PDFs, test assertions.

By default it starts its own browser with a persistent profile per workspace, so logins stick between sessions. For a clean start every time, add --isolated. To use the Chrome or Edge you already have open, add --extension and install the Playwright Extension. --browser also gets you Firefox and WebKit.

claude mcp add playwright npx @playwright/mcp@latest

Needs Node.js 18 or newer. Apache-2.0, free, no account.

Gotchas:

• The README says it is not a security boundary, and browser_run_code_unsafe, in the default tool set, is "RCE-equivalent".
• A persistent profile can only be used by one browser at a time, so two clients in the same workspace conflict. Use --isolated or a separate --user-data-dir.
• Its own README says coding agents might do better with Playwright CLI plus skills, because CLI calls skip large tool schemas and accessibility trees. If you're on Claude Code or Codex, I'd try that before the MCP server.

In our eval it scored 60.0 against our 60.4, a tie, and it was the fastest at 8.3 minutes median, with 4.4M input tokens.

If a run has to start clean every time, or you need Firefox or WebKit, I'd use this over Browser Harness. Same if your team already lives in Playwright. More in Playwright MCP vs Browser Harness.

3. Chrome DevTools MCP

Chrome DevTools MCP comes from the Chrome DevTools team. It records performance traces and summarizes the insights, runs Lighthouse audits, inspects network requests, reads console messages with source-mapped stack traces, and takes heap snapshots. It automates Chrome with Puppeteer and waits for each action's result. 32 tools are on by default; --slim cuts it to 3.

By default it launches its own Chrome with a dedicated profile that sticks between runs. --isolated gives you a throwaway one instead. --autoConnect attaches to the Chrome you have open (144+, after you allow it), and then it can see every open window of your default profile. Officially it supports Chrome and Chrome for Testing only.

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

Apache-2.0, free.

Gotchas:

• Google collects usage statistics by default; --no-usage-statistics turns that off. Performance tools may send trace URLs to the Chrome UX Report API; --no-performance-crux turns that off.
• The default launch is WebDriver-controlled, and the docs say some sites block sign-in for that. Their fix is to start Chrome yourself and connect.
• Chrome refuses to run as root, and it will not start inside OS sandboxes that block Chrome's own sandbox. Both bite in containers and CI.

In our eval it had the highest raw score, 61.0, which is a tie within noise. It was also a bit faster than Browser Harness, 8.7 minutes median against 9.0. The cost was tokens: 6.7M median, about 3x ours and the most of any tool.

If I'm chasing a slow page on our own dashboard, I use this, not our own tool. Browser Harness can get a trace through raw CDP, but here there is a tool for it and it summarizes the insights for you. More in Chrome DevTools MCP vs Browser Harness.

4. agent-browser

agent-browser from Vercel Labs is a native Rust CLI. It talks to a Rust daemon that drives Chrome over direct CDP, with no Node.js needed for the daemon. snapshot returns the accessibility tree with refs like @e1, and filters like interactive-only or compact keep it small. agent-browser mcp starts a stdio MCP server whose default core profile has 29 tools; --tools all gives you 156.

It also ships safety tooling: an encrypted auth vault (save a login yourself with auth save, and the agent logs in by name without seeing the password), a domain allowlist, action policies and output caps. Its MCP tools take typed fields like url, selector and text, so your MCP client's approval prompt shows what the agent is actually about to do.

By default it runs its own headless Chrome for Testing, and each --session gets its own browser, cookies and storage. --auto-connect attaches to the Chrome you have open, a profile name (--profile Default) reuses that Chrome profile's logins, and a path (--profile ~/.myapp-profile) keeps a persistent profile directory of its own.

npm install -g agent-browser && agent-browser install

Then add {"command": "agent-browser", "args": ["mcp"]} to your MCP client config. Homebrew and Cargo work too. Vercel's own recommended setup for coding agents is the skill, npx skills add vercel-labs/agent-browser, not MCP, and that is how we ran it in our eval.

Gotchas:

• --allowed-domains cannot be combined with --auto-connect, --cdp or Chrome profiles. You get the allowlist or your logged-in Chrome, not both.
• --profile Default (a profile name) works on a copy, so logins made during a run do not write back to your real profile. A path instead of a name is a persistent directory, not a copy.
• The default MCP profile has no auth, cookie, network or console tools. You restart with --tools to get them.

In our eval, run as its CLI and skill, it scored 56.3 against our 60.4, within noise. It used 3.3M median input tokens and was the slowest at 11.3 minutes.

I'd pick it over Browser Harness if I wanted a one-binary install, a domain allowlist, or approval prompts that show the exact URL and selector. Just know the allowlist goes away the moment you attach to your own Chrome. More in agent-browser vs Browser Harness.

5. Browser MCP

Browser MCP pairs a local MCP server with a Chrome extension. The server opens a WebSocket on port 9009, the extension connects to it, and you click Connect in the extension on the tab you want automated. The extension drives that tab through Chrome's debugger API. The agent works only in that tab, logged in as you. It was adapted from Playwright MCP and returns the same style of accessibility snapshot. It has 12 tools, including a console log reader, and no tools to open or switch tabs.

claude mcp add browsermcp -- npx @browsermcp/mcp@latest

Then install the Chrome extension and click Connect. The server is Apache-2.0, and the setup docs need no account or API key.

This is the one place it beats us: the blast radius is one tab you picked, and there is no remote-debugging toggle or Allow prompt to set up.

Gotchas:

• The MCP server's last npm release, 0.1.3, was in April 2025, and the repo says the code cannot yet be built on its own.
• The extension moves a bit more. The Chrome Web Store serves 1.3.4 from May 2025. The site changelog lists 1.4.0 dated October 18, 2026, but the store still had 1.3.4 that day.
• On startup the server kills whatever process holds port 9009, so I would not run two clients at once.
• It was not in our eval. I have no score, token or cost numbers for it.

For a ten-minute try in one tab, fine. I would not build anything on it until the server gets a release.

Comparison table

All five are free. Your model tokens are the bill.

For whole-task servers and the cloud browser vendors, see the full MCP round-up.