agent-browser or mare-browser? Here's how I actually choose.

If you're building web apps with an AI agent, you hit the same wall pretty fast: the model can write the code, but it can't see what the code does in a real browser. It can't click the button, watch the login fail, read the console error, or check what the API actually returned. It's coding blind.

That's what browser automation fixes. You give the agent a real browser it can drive — open a page, fill a form, click around, read the DOM, watch the network — so the loop stops being "AI writes code, you test it, you describe the bug, AI guesses" and becomes "AI writes code, AI tests it, AI reads the failure, AI fixes it." For both developing and testing, that's the difference between an assistant and an actual pair.

The way you wire that up is an MCP server — a small program that exposes browser actions as tools your agent can call. Both tools in this post are exactly that:

• agent-browser is Vercel's browser automation tool for agents — a fast native CLI with a huge feature set and an MCP mode. Think "do almost anything in a browser, anywhere."
• mare-browser-mcp is my lean, debugging-first MCP server built on Playwright. Think "give the agent the same DevTools signals I'd look at myself."

So which do you install? Someone asked me last week: "Vercel's agent-browser has 36,000 stars. Why are you still working on your little browser MCP?"

Fair question. And the honest answer is more interesting than "mine is better," because it isn't. They're not even really the same kind of tool.

So instead of pretending there's a winner, let me tell you how I actually decide which one to reach for. Because I use both.

First, let's be honest about agent-browser

agent-browser is excellent. I'm not going to do the thing where I damn a competitor with faint praise. It's a native Rust CLI, backed by Vercel, with a hundred-plus contributors and a feature list that's genuinely intimidating:

• An accessibility-tree snapshot with stable refs (@e1, @e2) — which is the correct way to let an LLM point at elements
• Semantic locators (find role, find label, find testid)
• Tabs, frames, dialogs, HAR recording, traces, profiler
• React DevTools introspection and Web Vitals
• Network mocking, cookies, auth vault, an MCP server with tool profiles
• iOS Simulator support and a stack of cloud browser providers (Browserbase, Kernel, and friends)
• Visual + snapshot diffing

If you handed me a blank slate and said "pick the most capable general-purpose browser automation tool for agents," I'd point at agent-browser and not feel conflicted about it.

So why does mare-browser-mcp exist?

Because breadth and fit are different things

mare is small on purpose. It's a Playwright-based MCP server with about a dozen tools, and the whole thing is bent toward one job: debugging a web app you're actively building, with an AI agent sitting next to you.

That's it. That's the niche. It doesn't do iOS. It doesn't do cloud browsers. It doesn't do HAR files. And it's never going to out-feature a Vercel project — I'm one person, and I'm not trying to.

What it does have is a different center of gravity. The flagship tool is browser_debug, which returns the console, the network requests (with payloads, response bodies, status codes, and timing), the current URL, the title, and any dialogs — in a single call. When you're debugging your own app, that one call is basically the whole game. (I wrote a whole separate piece about why telemetry beats screenshots, so I won't rehash it here.)

In agent-browser, that same information is spread across console, errors, network requests, and network request <id>. Nothing wrong with that — it's a more granular, more general design. But for my loop, one call beats four.

So here's the actual decision

I stopped thinking of it as "which tool is better" and started thinking about what I'm actually doing that hour.

Reach for agent-browser when:

• You need a browser somewhere that isn't your laptop — CI, serverless, a cloud provider
• You're testing on real mobile Safari or emulated devices
• You're doing broad automation: many tabs, frame juggling, recorded traces, visual regression diffs
• You want React fiber introspection or Web Vitals out of the box
• You want a mature, well-staffed tool with a release cadence and a big community behind it
• You're scraping or automating across many sites and want stealth, proxies, domain allowlists

Reach for mare when:

• You're building a web app and debugging it locally with an agent
• The bug is "the button does nothing" and the real answer is a 401 with the wrong field name in the request body
• You want the model looking at network payloads and console errors, not screenshots
• You want a tiny, readable tool surface the model won't get lost in
• You log in once by hand (it runs headed by default) and then let the agent work in your real session
• You want to crack open browser_eval and poke at window state or computed styles

Notice these lists barely overlap. That's the point. One is a Swiss Army knife. The other is a screwdriver I ground down to fit one screw I turn forty times a day.

The honest gap I just closed

For a while there was one place mare was genuinely worse, not just smaller — and it's worth admitting because it's the kind of bug that quietly lies to you.

mare also has ref-based snapshots (browser_snapshot gives you e1, e2, ...), but until recently those refs resolved through a generated CSS path like #list > li:nth-of-type(3) > button. Think of it as directions: "the third house on the second street." If the page re-rendered between the snapshot and the click — a row inserted, a list re-sorted, React reconciling — that "third house" could now be a different house. And mare would click it. Confidently. Without telling you.

For a debugging tool, that's the worst possible failure: it doesn't error, it misleads.

I just rewrote it so each ref is pinned to the exact element it was captured on (via a unique attribute on the node itself). Now click e3 either hits that element or fails loudly and tells you to re-snapshot. It can't silently drift anymore. agent-browser already got this right with its ref system; mare does now too.

I'm telling you this partly because it's a real improvement, and partly because I think "here's where my tool was wrong and here's how I fixed it" is more trustworthy than a feature table.

You're allowed to use both

This isn't a cage match. They're both MCP servers. They can both be registered with the same agent at the same time. I genuinely run mare for the inner loop of building something — the tight write-test-read-fix cycle on localhost — and I'd reach for agent-browser the moment the job grows past my own machine.

If you want the most capable, most supported, broadest browser tool for agents, use agent-browser. That's the easy, correct default and I'll be the first to recommend it.

If you specifically want a small, debugging-first MCP that hands your agent the same DevTools signals you'd look at yourself — and you're mostly working on your own app on your own machine — that's the gap mare was built for.

Pick the screwdriver or pick the Swiss Army knife. Just don't pick based on the star count.

Try mare

git clone https://github.com/emadklenka/mare_browser_mcp
cd mare_browser_mcp
pnpm install
npx playwright install chromium
pnpm run setup

It's free. If it saves you an afternoon of squinting at screenshots, buy me a coffee. And if you try both tools and disagree with where I drew the line, I'd honestly like to hear it.