A little while ago I wrote an MCP server that lets an AI agent inspect and control Firefox through the Remote Debugging Protocol. It got adopted into the Mozilla org. That’s a nice flex, and I’ll take it, but it buries the more useful story, which is why I built it. It wasn’t to give my agent a browser. It was to make my agent write its own tests.
The real problem: e2e tests, not browsing
Multi-agent orchestration I’ve mostly got a handle on. My actual pain, the thing that eats my evenings, is end-to-end testing. Nobody wants to write it, it rots the moment the UI shifts, and it’s exactly the kind of mechanical-but-fiddly work you’d love to hand off.
So the flow I actually care about looks like this:
- Claude has a “test skill” that tells it to click through the app using the Firefox MCP: open the page, fill the form, follow the flow, read the DOM back.
- Once it’s walked the flow and knows what the app does, it writes a Cypress or Playwright test for it.
- From then on it just runs the test. The MCP was scaffolding to author the test, not a permanent dependency.
- If it gets stuck, it pings me and I finish that one by hand.
The result is a reasonably tight dev loop: the AI builds a thing, tests the thing, and knows when it broke the thing. The browser control is a means to that end.
Why Firefox, when Chrome DevTools MCP exists
Fair question. Chrome’s DevTools MCP does most of the same moves. Three reasons I reached for Firefox anyway, and none of them is “Firefox is better at everything.”
It’s stricter about standards. Firefox holds the line on W3C (CSS Grid inspection, layout edge cases) where Chrome quietly papers over your mistakes. That sounds like a downside until you realize it’s exactly what you want from a test browser. If a layout is going to break, I’d rather it break in the strict engine during testing than in front of a user.
Leaner to run on a server. I don’t run this on my laptop. It runs on a server, next to a Claude CLI or Codex session and whatever else is going. When you’re stacking agents on one box, a lighter headless browser is the difference between fitting and swapping. And for my setup, headless Firefox is the lighter one. (Measure it on your own box; it depends on what you load.)
It’s open source. For something I want to run on my own infrastructure and tinker with, that speaks for itself.
What this says about MCP servers in general
The thing I keep taking away from this one: the best MCP servers are scaffolding for a workflow, not a permanent appendage. The Firefox MCP is at its most valuable in the minutes it takes the agent to learn a flow and codify it into a real test. After that, a plain playwright test command does the job: no agent, no MCP, no tokens.
Designing for that (“help the agent build something that outlives the session” instead of “keep the agent calling me forever”) is a different mindset than most tool servers take. And it happens to produce the tool I actually reach for every day.
Try it
If your pain is the same as mine, writing and maintaining e2e tests, this flow is worth stealing even if you never touch Firefox: let the agent explore the app through a browser MCP, then have it emit a real Playwright/Cypress test you can run headless forever after.
The repo lives in the Mozilla org now: mozilla/firefox-devtools-mcp.
What’s your current e2e testing loop: hand-written, recorded, or generated? I’m always looking to tighten mine.
답글 남기기