DEV Community: Emad Omar

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

Emad Omar — Wed, 17 Jun 2026 11:18:00 +0000

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.

Your AI Doesn't Need Screenshots. It Needs DevTools.

Emad Omar — Sat, 28 Mar 2026 22:04:34 +0000

Your AI Doesn't Need Screenshots. It Needs DevTools.

Most AI coding agents are still debugging web apps in the dumbest possible way.

They ask for a screenshot.

Meanwhile the real answer is usually sitting in the browser console, the Network tab, the request payload, or the response body.

That is not really an AI problem. It is a tooling problem.

I got tired of watching agents guess from screenshots while I had DevTools open right next to them, showing the exact reason something failed. So I built mare-browser-mcp, a browser MCP designed less like "remote control for a webpage" and more like "give the model the same debugging signals I actually use."

That changed the loop from this:

AI writes code -> I test it -> I describe the bug -> AI guesses a fix -> repeat

to this:

AI writes code -> AI tests it -> AI reads the failure -> AI fixes it

That difference matters more than people think.

The Screenshot Trap

Most browser MCPs start from the same assumption: if the model can see the page, it can debug the app.

That sounds reasonable until you try to debug anything real.

A screenshot does not tell the model:

that login failed with a 401
that the frontend sent user_email instead of email
that a button click triggered a JS exception
that the UI is fine but the API returned invalid JSON
that the missing data is actually below the fold in a scrollable grid
that the context menu only appears on right-click

A screenshot is expensive, unstructured, and often the least useful artifact in the whole debugging flow.

Language models are good at reasoning over structured text. We keep handing them pixels and asking them to guess.

What I Wanted Instead

I wanted a browser MCP that makes the model think more like a developer with DevTools open.

That means a few things:

It should read console logs and page errors directly
It should see network requests, payloads, response bodies, and timing
It should batch actions instead of making one tiny tool call per click
It should query the DOM as structured data
It should handle hover, drag, right-click, and nested scroll containers
It should only use screenshots when the problem is actually visual

That is the core idea behind mare-browser-mcp.

It is a lean MCP server built with Playwright and the MCP SDK, and the whole design is biased toward structured debugging data first.

The One Tool I Wish More Browser MCPs Had

The most important tool in the server is browser_debug.

One call returns:

current URL
page title
console logs
page errors
dialogs
network request history

And the network history is the useful part. The server captures things like:

method
URL
parsed query params
request headers
request body
status code
JSON response body
duration in milliseconds

So instead of the model seeing "submit button clicked and page still looks wrong," it can see:

{
  "method": "POST",
  "url": "https://app.example.com/api/session",
  "requestBody": {
    "user_email": "user@example.com",
    "password": "secret"
  },
  "status": 401,
  "responseBody": {
    "error": "missing field: email"
  },
  "duration_ms": 23
}

That is a completely different debugging experience.

At that point the model is not guessing anymore. It can actually reason from evidence.

There are a few guardrails in the implementation too:

static assets are skipped
OPTIONS preflights are ignored
bodies are capped at 4 KB
auth headers are masked
cookies are reduced to "[present]"
failed requests are logged with the failure reason

So the data stays useful without turning into junk.

Batching Matters More Than It Sounds

Another thing that slows agents down is one-action-per-call design.

Click. Wait. Screenshot. Fill. Wait. Screenshot.

That is not just annoying. It makes the whole debugging loop slower and dumber.

browser_act fixes that by accepting an ordered list of actions in one call:

[
  { "action": "fill", "selector": "#email", "value": "user@example.com" },
  { "action": "fill", "selector": "#password", "value": "secret" },
  { "action": "click", "selector": "button[type=submit]" }
]

The current action set covers a lot of what real apps actually need:

click
hover
drag
clicklink
fill
select
keypress
waitfor
scrollto
wait
clearconsole

That means the model is not stuck the moment the UI uses hover states, resize handles, sortable grids, or context menus.

And yes, right-click works through click with button: "right", which turns out to matter more often than you might expect.

Structured DOM Queries Beat Giant Dumps

Another thing I did not want was a browser tool that just vomits the whole DOM back at the model.

browser_query is useful because it lets the model ask narrower questions:

How many rows are there?
Is this button visible?
What text do these badges have?
Is this input disabled?

Examples:

{ "selector": ".ag-row", "count_only": true }

{ "selector": "button", "all": true, "visible_only": true, "limit": 10 }

{ "selector": ".badge", "fields": ["text", "className", "visible"] }

The supported fields are deliberately practical:

text
value
visible
disabled
className
href
innerHTML

That keeps the output small enough to reason about and avoids wasting context on useless noise.

Screenshots Are Still There. They Just Aren't First.

I did keep browser_screenshot.

But I made the tool description explicitly say it should be the last resort, not the default.

That sounds minor, but it really changes how an agent behaves. If the tool surface itself tells the model:

use browser_debug first
use browser_query second
use screenshots only for visual problems

then the model starts spending its attention on data instead of appearance.

That is the behavior I wanted.

Real Apps Need More Than Page Scroll

One of the easiest ways browser tools fall apart is scrolling.

Scrolling the page is not enough for modern apps. A lot of important UI is inside:

data grid viewports
chat panels
sidebars
overflow containers
modals

browser_scroll can scroll the page, scroll an element into view, or scroll inside a specific container.

Example:

{
  "container": ".ag-body-viewport",
  "direction": "down",
  "pixels": 500
}

And because it returns scroll position data, the model can tell where it is instead of just flailing around.

There Is Also an Escape Hatch

Even with all of that, fixed tools never cover every case.

So there is browser_eval, which runs JavaScript in the page context.

That is useful for things like:

reading computed styles
inspecting app state on window
appending input text without clearing it
simulating more custom interactions
calling fetch() directly
checking CSS visibility details

I do not think the escape hatch should be the first thing the model reaches for. But it absolutely should exist.

What This Looks Like in Practice

A realistic flow is:

1. browser_navigate({ url: "https://myapp.com", clear_logs: true })

2. browser_act({
     commands: [
       { action: "fill", selector: "#email", value: "user@example.com" },
       { action: "fill", selector: "#password", value: "secret" },
       { action: "click", selector: "button[type=submit]" }
     ]
   })

3. browser_wait_for_network({ url_pattern: "/api/session", method: "POST" })

4. browser_debug({ console_types: ["error"], last_n: 20 })

From there the model can see:

whether the request fired
what payload got sent
what response came back
whether the browser threw an error
whether the failure is frontend, backend, or both

That is the kind of loop where an agent becomes genuinely useful.

Why I Think This Matters

I think a lot of people are measuring browser MCPs by the wrong thing.

The question is not "can the AI click buttons?"

The real question is: when something breaks, can the AI see the same evidence a good developer would look at?

If the answer is yes, the quality of debugging jumps fast.

If the answer is no, you end up with a very expensive screenshot viewer.

That is why I built mare-browser-mcp the way I did. Not to make agents better at looking at pages, but to make them better at understanding what happened in the browser.

Not screenshots first. Telemetry first.

Try It

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

It also supports global install:

pnpm add -g mare-browser-mcp
npx playwright install chromium

The repo has setup instructions for Claude Code and OpenCode, and the current server exposes:

browser_navigate
browser_act
browser_debug
browser_query
browser_screenshot
browser_eval
browser_scroll
browser_restart
browser_upload
browser_wait_for_network

If you are building web apps with AI, that combination is much closer to giving your agent DevTools than giving it a screenshot and hoping for the best.

claude

Emad Omar — Sat, 28 Mar 2026 20:38:00 +0000

Give Claude Your Browser Console — It Debugs Like a Real Developer

Emad Omar — Sun, 22 Mar 2026 10:20:20 +0000

Give Claude Your Browser Console — It Debugs Like a Real Developer

You know that moment when something breaks in your web app and you open DevTools, check the console, scan the network tab, find the failing API call, read the JSON response — and finally figure out what went wrong?

That's exactly what mare-browser-mcp gives Claude.

Not a screenshot. Not a DOM dump. The actual console errors, the actual network requests, the actual JSON responses from your API. Claude reads them the same way you do.

The Problem With Other Browser MCP Tools

Most browser MCP servers give the LLM one move: take a screenshot.

Screenshots are pixels. Claude has to guess what's happening from an image. It can't see a 401 response. It can't read a JS stack trace. It can't tell if an API returned { error: "session expired" }.

That's not debugging. That's guessing.

What mare-browser-mcp Does Differently

One tool does the heavy lifting: browser_debug

Call it after anything goes wrong and you get back:

Current URL and page title
All console logs (errors, warnings, everything)
All network requests with status codes and full JSON response bodies

{
  "current_url": "https://myapp.com/dashboard",
  "title": "Dashboard",
  "console": [
    { "type": "error", "text": "Uncaught TypeError: Cannot read properties of undefined (reading 'user')" }
  ],
  "network": [
    { "url": "/api/session", "method": "POST", "status": 401, "body": { "error": "token expired" } }
  ]
}

Claude reads that and knows exactly what happened — token expired, session failed, JS crashed because user was undefined. Same conclusion you'd reach in 30 seconds of DevTools.

The Full Toolkit

8 tools, each with a clear job:

browser_navigate — go to a URL, optionally clear logs before starting
browser_act — click, fill, keypress, scroll — batch multiple steps in one call
browser_debug — start here when something breaks
browser_query — read DOM elements without a screenshot
browser_eval — run any JavaScript in the page
browser_scroll — scroll by pixels or to a specific element
browser_wait_for_network — wait for a specific API call to complete
browser_screenshot — last resort only

Real Debugging Session

1. browser_navigate("https://myapp.com", clear_logs: true)

2. browser_act([
     { action: "fill", selector: "#email", value: "user@example.com" },
     { action: "fill", selector: "#password", value: "secret" },
     { action: "click", selector: "button[type=submit]" }
   ])

3. browser_wait_for_network({ url_pattern: "/api/session", method: "POST" })

4. browser_debug({ console_types: ["error"] })
   → sees 401 + "token expired" in the response body

5. Figures out the fix. No back and forth. No screenshots.

This is the workflow. Claude acts, waits for the network, reads the debug output, understands what happened.

Install in 5 Commands

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

pnpm run setup registers the MCP with Claude Code automatically — no manual path config.

It's Free

MIT license. Use it however you want.

If it saves you debugging time → https://buymeacoffee.com/emadomar

GitHub → https://github.com/emadklenka/mare_browser_mcp

Built this because I was tired of Claude guessing from screenshots. Now it debugs the way I do.