Chrome vs. Safari vs. Firefox: AI debugging MCPs tested

Major browsers now ship a way for AI agents to open your app, look around, and debug it. Chrome’s comes from Google. Safari 27 added one from Apple. Firefox’s is maintained by Mozilla.

So I did what I normally love doing. I built a small React app, planted four bugs in it, and gave all three to debug.

My theory behind this was that browser tools stop at the DOM, so none of them would find the cause of a React re-render bug without extra help. I was half wrong, and that half tells the story in this article.

Here’s the short version:

• All three found the network, layout, and console bugs
• All three could find the React bug too, with no React tooling at all
• Only Firefox got it exactly right, and it did that by opening the source file
• Chrome and Safari dug through React’s internals by hand. They landed in the right area, then blamed a missing memo. The memo was already there

One thing to note before we start. Most of these numbers come from one or two runs each. Read this as a field report, not a lab benchmark; here is the GitHub repo.

What is browser agent debugging MCP?

An agent debugging MCP is a small server that sits between your coding agent and a real browser. The agent calls tools like “list the network requests” or “run this JavaScript”, and the browser answers.

We’ve already covered how to connect the Chrome DevTools MCP, so I’ll skip the setup tour. Here are the three things that tripped me up instead:

• Safari needs version 27: On Safari 26.6, safaridriver --mcp answers with unrecognized option '--mcp'. After the update, you tick “Allow remote automation and external agents” in the Developer settings, and you’re in
• Firefox hides its best tools: The default preset has no network, console, or debugger tools. You have to start it with --tool-preset developer. Remember this flag. It decides the test later
• Chrome hides its React tools: They only show up if you start the server with --categoryExperimentalThirdParty=true

There’s also a cost you pay before the agent does any work. Every tool a server offers gets described to the model on every run. I measured that with a one-word prompt:

Setup	Tools	Extra input tokens
Safari 27 (safaridriver --mcp)	17	3,846
Chrome (chrome-devtools-mcp 1.10.1)	30	7,797
Chrome with the React tools flag	32	8,194
Firefox (@mozilla/firefox-devtools-mcp 0.10.4, developer preset)	48	8,207

With no MCP at all, the same prompt used 5,807 input tokens. Safari costs about half of what the other two cost, because it ships about half the tools. Keep that in mind, because fewer tools cut both ways.

What bugs can browser debugging agents find?

The app is a small dashboard built with Vite 8, React 19.3, and TypeScript. It has a row of 8 project cards, a notes box, and a big activity table. React Compiler is off because it could quietly fix the React bug for me.

I planted four bugs:

1. A network waterfall: The stats for the 8 projects load one at a time, with await inside a loop. That takes about 3 seconds when 350 ms would do
2. A layout break: One project has a very long name with no spaces. The title can’t wrap, and the card can’t shrink, so the row spills off the page. A very common rookie mistake

3. A console error with a hidden cause: One card shows “Something went wrong”. The console blames a component. The real cause is one API response with a different shape from the other seven
4. The React one: Typing in the notes box feels slow. Feel free to clone and run the app to witness this

Bug 4 is the one this article is about, so here’s the code:

// AppContext.tsx
<AppContext.Provider value={{ user, theme, draftNote, setDraftNote }}>
  {children}
</AppContext.Provider>

// ActivityTable.tsx
const TableRow = memo(function TableRow({ row }) {
  const { theme } = useAppContext();
  // builds 11 Intl formatters, then renders the row
});

The text of the notes box lives in the same context as the theme. Every keystroke builds a new context value. Every row reads that context, so every row renders again, and memo can’t block a context update. The rows only wanted the theme. They got your whole diary.

I started with 300 rows. My M4 Mac didn’t even blink, so I raised it to 1,500, then I noticed it.

How did I test Chrome, Safari, and Firefox debugging agents?

The agent was Claude Code 2.1.97 running Opus 4.6. I set four rules:

• The agent that debugs never sees the code: One session built the app. Every debugging run was a fresh session with file and shell tools switched off. It had browser tools and nothing else
• One line of symptom, no hints: For bug 4, the symptom line was: “Typing in the notes box above the activity table feels slow”
• It had to commit: Each run ended with a root cause, the evidence, and a list of what the tools couldn’t show
• The answer key came first: Each bug had two required facts, written down before any run. A script graded every answer against them, and I re-read the bug 4 answers by hand

I planned three runs for every browser and bug. Time ran out, so most pairs got one run and a few got two.

Can Chrome, Safari, and Firefox debug common browser bugs?

Every run that finished named the right cause. Here’s how long each browser took.

Bug	Chrome	Firefox	Safari
1. Network waterfall	123 s (1 run)	59 s (1 run)	108 s (2 runs)
2. Layout break	104 s (2 runs)	78 s (2 runs)	86 s (1 run)
3. Console error	68 s (1 run)	67 s (2 runs)	82 s (1 run)

Where a pair has two runs, the number is the middle of the two. Each run cost between $0.18 and $0.36, by Claude Code’s own estimate.

• Firefox read the code: On bug 1, it turned on its debugger, pulled the source of CardRow.tsx, and quoted the loop back to me. No timing math needed
• Safari started with an empty network log: It doesn’t keep requests from before the session began. The agent worked that out fast: “The network buffer is empty since the page already loaded. Let me reload and capture network requests.” On its second run, it went further and fetched CardRow.tsx through evaluate_javascript. Remember that. A browser with no source tool can still read source
• Chrome choked on its own snapshot: On bug 2, it asked for a text snapshot of the page and got 562,941 characters back. That’s what 1,500 table rows will do. The server saved it to a file, and the agent tried to open that file with tools I had taken away. Two errors later, it gave up, asked the page for its CSS directly, and solved the bug

So for everyday bugs, use the browser where the bug shows up. With one or two runs each, I wouldn’t bet my money on a 20-second gap.

Which browser debugging agent is best at finding React bugs?

The first round looked like a blowout.

Browser	Result	Time	Turns	Total tokens
Firefox	Exact cause	76 s	13	225,095
Chrome	Right area, wrong detail	398 s	26	500,693
Safari	No answer

How did Firefox find the React re-render bug?

Firefox’s developer preset has three tools the other two lack: enable_debugger, list_scripts, and get_script_source. The agent used them to read AppContext.tsx, ActivityTable.tsx, and NotesBox.tsx. Nine turns in, it said: “Found it. Let me verify the number of activity rows and confirm the mechanism.”

Its answer was exact. The rows are wrapped in memo. They read a context that also holds the note text. A context update goes straight past memo. It even counted the damage: 16,500 Intl formatters built on every keystroke, at about 228 ms each time. It did what you’d do. It stopped guessing and read the code.

Why did Chrome misdiagnose the React re-render bug?

Chrome’s MCP has no tool named for reading source. The agent could have fetched the file through evaluate_script. But it didn’t. It walked React’s internal fiber tree by hand instead.

Then it started a performance trace, typed into the notes box, and the tab died:

MCP error -32000: Connection closed

The agent’s reply is my favourite line of the whole test: “Page crashed during trace. Let me reopen and measure differently.”

It did, and it found the shared context. Then it blamed the table for not being wrapped in memo, and marked its confidence as high. But the rows are already wrapped in memo, and context walks right past it. If I’d trusted that answer, I’d have added a memo that changes nothing.

Could Safari diagnose the React re-render bug?

Safari’s first run stalled. A script it ran to time a keystroke hit a 30-second limit, and the run ended with no answer.

Then I got a second look by accident. My test of a separate React CLI broke (more on that below), and those runs fell back to plain browser tools. They’re messy runs. The agent was told about a CLI that wasn’t there, and it lost a few turns hunting for it. But the browser tools were the same.

Browser	Messy runs	The memo detail
Firefox	134 s and 190 s	Right both times
Chrome	223 s	Wrong
Safari	189 s and 244 s	Wrong once, not mentioned once

So Safari can find this bug. It walked the fiber tree like Chrome did, hit the same 30-second timeout in one run, and kept going.

Put both rounds together and the picture changes. The 76 seconds against 398 seconds was a lucky pair. Firefox was still quicker on the whole, but nowhere near five times.

The gap in accuracy is the one that held. Firefox read the source and got memo right in all three runs. Chrome and Safari read React’s internals and got it wrong in three of their four answers.

So my theory was half right. The browsers aren’t blind to React. They’re blurry.

Do React DevTools MCP tools improve AI debugging accuracy?

The React team now ships react-devtools-cdt-mcp. You add one import before React loads:

import 'react-devtools-cdt-mcp/register';

It’s Chrome only. Its README lists 12 React tools, such as the component tree, owner stacks, and a profiler. The agent reaches them through two extra tools on Chrome’s MCP. I ran bug 4 again on Chrome with it turned on. This was version 0.1.0, and one run.

Setup	Answer	Time	Total tokens
Chrome alone	Right area, wrong detail	398 s	500,693
Chrome with the React tools	Exact	144 s	493,518
Firefox alone	Exact	76 s	225,095

The React tools did two things for Chrome. They cut the time by more than half, with no crashes. And they turned a blurry answer into an exact one.

The profiler counted 13,606 components rendering again on every keystroke, at roughly 180 to 330 ms each time. The agent named Memo(TableRow) as a reader of AppContext, and said the update goes past React.memo.

They didn’t cut the tokens. One reason is that the profiler’s commit report came back at 2.1 million characters, and the agent could only read the top of it.

So this is the React layer I expected to need. It just isn’t the only way to a sharp answer. Firefox reading the file got there with half the tokens.

I also meant to test agent-react-devtools, the community CLI that works with any browser. My harness never put its command on the agent’s PATH, so every run got command not found. That’s my bug, not theirs, so I’ve left it out of the results. Its only gift to this article is those messy runs.

Which browser debugging MCP should you use?

If the bug is	Reach for	Why
Network, layout, or console	Whichever browser shows the bug	All three found these, and the times were close
A React re-render, in dev	Firefox with --tool-preset developer	It reads the source with a named tool, and it was the only bare browser to get memo right
A React re-render, and you live in Chrome	Chrome plus react-devtools-cdt-mcp	You get an exact answer with real render counts. Without it, Chrome was slow and got memo wrong twice
Only broken in Safari	Safari’s MCP	It’s the only one of the three that runs WebKit, and the cheapest to keep connected

• The one I’d skip isn’t a browser: It’s the default setup. Firefox on its default preset has no debugger tools, so no get_script_source. Chrome without the extra flag has no React tools. Both defaults hide the exact tool that won this test
• No source tool? The agent can still fetch the file: Safari’s agent did that once through script evaluation, without being asked
• Watch the output sizes: Chrome handed back a 562,941-character snapshot and a 2.1-million-character profiler report. A big page can eat your context before the agent learns anything
• You still own the answer: Chrome’s first answer came with high confidence and pointed at the wrong fix. Even with the right cause, somebody has to choose. Split the context? Memoize the value? Move the notes state down a level? That’s a design call, and it’s still yours, reminding us of this engineering masterpiece

Conclusion

Agent debugging stopped being a Chrome-only trick this year. Three engines ship it now, and they aren’t equal. The gap just wasn’t where I expected.

All three can find everyday bugs. All three can even find a React re-render bug. What separates them is how sharp the answer is. The sharp answers came from an agent that could read the code, or from React’s own tools. The blurry ones came from an agent guessing at React’s internals.

So before you add anything to your loop, check two things. Can your agent read the source of the page it’s debugging? And are the good tools switched on?

Then keep a human around. Somebody still has to check the answer and choose the fix.