People often ask if they need a bug capture tool when their agent can already use a browser. Fair question. The two solve different halves of the same problem: finding the bug and showing it, versus reproducing it and checking the fix. Facts about Chrome DevTools MCP below come from its README, checked on 2 November 2026.
What each one is
Chrome DevTools MCP is an MCP server that gives a coding agent access to a live Chrome browser. Its README calls it "Chrome DevTools for coding agents". It can take screenshots, read console messages with source-mapped stack traces, analyze network requests, record performance traces, and automate actions with Puppeteer. It's open source (Apache-2.0), runs with Node.js via npx chrome-devtools-mcp@latest, and by default starts its own browser when the agent needs one.
Darnly is a free Chrome extension and Mac app. You press one key, click the broken part, and say what you expected. It saves a report with a screenshot (the broken part boxed in red), the element, the page address and recent console errors and failed requests, into .darnly/inbox/ in your project for Claude Code, Codex or Cursor.
Side by side
| Darnly | Chrome DevTools MCP | |
|---|---|---|
| Who drives the browser | You, in your normal Chrome | The agent, in a browser it starts (or one you connect it to) |
| Good at | Showing exactly what you saw, with your note on what you expected | Reproducing a bug, checking a fix, performance traces |
| Your login and app state | Already there, it's your browser | The agent's browser starts fresh unless you connect it to a running Chrome |
| Setup | Install the extension, link your project folder once | Add the server to your MCP client config. Needs Node.js and Chrome |
| Data | Stays on your computer unless you turn on the cloud inbox. Secrets hidden before saving | Exposes the browser's content to your MCP client. Usage statistics on by default, can be turned off |
| Beyond the browser | Mac app for Mac apps, iOS Simulator and Android Emulator | Chrome. Other Chromium browsers "may work" |
| Price | Free | Free, open source |
When Chrome DevTools MCP is the better pick
- You want the agent to check its own fix. It can open the page, click through, and look at the console after changing code. Darnly can't do that. That's a big deal for longer sessions.
- Performance work. Recording a trace and getting insights is something only DevTools MCP does here.
- The bug is easy to describe. "The form on /signup shows an error when I submit" is enough for an agent with a browser to find it.
- You're comfortable with MCP config and Node.js. Setup is a few lines in your client's config.
When Darnly is the better pick
- The bug is hard to put into words. "That thing is a few pixels off" is easy to click and hard to describe so an agent finds the same spot.
- It took several steps to get there. You were logged in, had items in a cart, a menu open. Darnly captures that moment in your own browser. An agent would have to redo all of it.
- You don't want to stop. One key, a click, a sentence, and you keep testing. Collect ten bugs, then type
/darnlyonce. - You'd rather not set up MCP. For a local project there's nothing to add to your agent. Darnly writes files and an AGENTS.md note.
- The bug isn't in Chrome. The Mac app captures Mac apps and mobile simulators.
Using both
A good loop for testing an app before launch: you click around and capture bugs with Darnly as you find them. Then the agent fixes them from the inbox and, with Chrome DevTools MCP, opens the pages to check its own fixes. You look last.
One honest note from our own testing: our benchmark didn't let the agent open a browser, so we haven't measured how an agent with DevTools MCP compares on the same bugs. We'd expect it to do well on bugs that are easy to reproduce from a sentence.
Want to try the Darnly half? Add it to Chrome, it's free.