mozilla/firefox-devtools-mcp: an MCP server that drives Firefox through WebDriver BiDi
Model Context Protocol server for Firefox DevTools - enables AI assistants to inspect and control Firefox browser through the Remote Debugging Protocol
At a glance
- What is it?
- Mozilla's MCP server exposes Firefox DevTools capabilities to AI assistants over the Remote Debugging Protocol. It is a local-only tool with a real security surface, a preset system that decides how much the agent can do, and a licence file the repository metadata does not resolve.
- Who is it for?
- Adopt it if you already drive Firefox and want an MCP client to inspect pages, capture network traffic and take snapshots inside a browser you launch yourself. Do not adopt it for cloud-hosted agents, for Chromium-only test suites, or as a replacement for a scripted end-to-end test runner.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills: letting an assistant see a real Firefox session
An MCP client can read files and run shell commands, but it cannot look at what a page actually rendered, which requests it made, or what the console printed. This server exists to close that gap for Firefox specifically. It speaks the Model Context Protocol to the assistant on one side and drives Firefox through WebDriver BiDi, via Selenium WebDriver, on the other. The README states the target audience directly: it works with Claude Code, Claude Desktop, Cursor, Cline and other MCP clients. The topics list on the repository names claude-code, firefox, mcp and mcp-server, which is a fair summary of the scope. If your debugging happens in Chromium, this project is not aimed at you. If your team already runs Firefox and wants an agent to inspect a running page rather than guess from source, that is the case it was written for.
WebDriver BiDi underneath, MCP tools on top
The transport choice is the most consequential design decision here. Rather than a bespoke extension or a patched DevTools protocol, the server goes through WebDriver BiDi by way of Selenium WebDriver. That buys compatibility with stock Firefox 100 and later, auto-detected or pointed at explicitly with --firefox-path, and it means the automation surface is the one Mozilla and the WebDriver working group maintain rather than something this repository owns. On top of that transport sits a set of MCP tools grouped into modules. The README's own walkthrough names list_pages, select_page, navigate_page, take_snapshot, click_by_uid, fill_by_uid, list_network_requests, get_network_request, list_downloads, set_download_behavior, screenshot_page and list_console_messages. Two of those deserve attention: network request capture and download listing are described as always-on, so the agent is not required to arm a recorder before the traffic it cares about has already gone past. The snapshot and uid flow is the other notable mechanism. take_snapshot produces a representation of the page, and click_by_uid and fill_by_uid act on identifiers from that snapshot instead of on CSS selectors the model would otherwise have to invent.
Tool presets are the real permission model
The --tool-preset flag selects which tool modules load, with values slim, basic (the default), developer, mozilla and all. The README is explicit that the default basic preset already includes evaluate_script, and that slim drops it. That single sentence should shape how you deploy this. Arbitrary script evaluation inside a browser that holds your cookies is a different proposition from taking screenshots, and the default does not protect you from it. The developer preset adds debugging, network, console and profiler modules; the mozilla preset reaches into privileged context and requires MOZ_REMOTE_ALLOW_SYSTEM_ACCESS=1 to be set. If you want to bypass presets entirely, --tools takes an explicit module list such as pages network script. Two older flags, --enable-script and --enable-privileged-context, are marked deprecated in favour of preset or explicit module selection, so configuration copied from an older setup will still work but is on a path the maintainers have already flagged. The preset ladder is the closest thing to a capability boundary in this project, and it is coarse: there is no per-tool allowlist beyond naming modules yourself.
Getting it running: npx, JSON config, or a TOML block
The README recommends npx so you always run the latest published version. For Claude Code the shortest form is claude mcp add firefox-devtools npx @mozilla/firefox-devtools-mcp@latest. Flags go after a double dash, for example claude mcp add firefox-devtools npx @mozilla/firefox-devtools-mcp@latest -- --headless --viewport 1280x720, or you can pass environment variables with --env START_URL=https://example.com --env FIREFOX_HEADLESS=true. Codex uses codex mcp add firefox-devtools -- npx @mozilla/firefox-devtools-mcp@latest. If you prefer editing files, Claude Code takes a JSON block under mcpServers with command npx, args including -y, the package, --headless and --viewport, and an env object holding START_URL. Codex takes a TOML block in ~/.codex/config.toml with [mcp_servers.firefox-devtools] and a separate [mcp_servers.firefox-devtools.env] table. A third path, npm run setup, is described as a helper script for a local dev build that asks which client you use and writes the JSON to the right place. To poke at the tools without a client, the README gives npx @modelcontextprotocol/inspector npx @mozilla/firefox-devtools-mcp@latest --start-url https://example.com --headless. Requirements are Node.js 20.19.0 or newer and Firefox 100 or later.
The limitation the README states plainly: local only
A note near the top says the server requires a local Firefox installation and cannot run on cloud hosting services such as glama.ai, which is why the README points to npx or to the provided Dockerfile instead. That rules out the pattern many teams reach for first: a hosted MCP endpoint shared by a group. Every user needs Firefox on their own machine. The second constraint is the security model, and the README does not soften it. Browser MCP servers carry inherent risks, and the guidance is to use a dedicated Firefox profile rather than your regular one, because the agent has access to whatever the browser can reach, including cookies and saved sessions. It also warns that pages can return content designed to manipulate the agent, and that you should stick to sites you control or trust. That is prompt injection described in plain terms, and no preset setting removes it, because the injection arrives through page content the agent was asked to read. The --unrestricted-save-paths flag widens the blast radius further by letting the saveTo parameter write anywhere on disk rather than the default roots, and the README defers to SECURITY.md for the details. Treat all of this as the cost of admission rather than a configuration problem to be solved.
Where it sits next to Playwright and Selenium on their own
The obvious alternative is Playwright's MCP server, and the difference is not feature parity but transport and browser scope. Playwright drives its own browser builds across Chromium, Firefox and WebKit through its own protocol layer, so a single setup covers multiple engines and the browser binaries are managed for you. This project drives the Firefox you already have installed, through WebDriver BiDi by way of Selenium WebDriver, so the browser under test is the real local Firefox, including the version your users run, and the automation stack is the standards-track one rather than a vendor's own. That cuts both ways. You get fidelity to the installed browser and no second browser download; you give up cross-engine coverage and you inherit the constraints of the BiDi surface as Selenium exposes it. If your suite must pass in Chromium and WebKit as well, this server is the wrong tool and you should not try to make it the right one. If the question is specifically what Firefox does with a page, driving the installed Firefox through the standard protocol is the more direct answer.
Maintenance cost and the licence question the metadata leaves open
The repository is active, not archived, with v0.10.2 published in September 2026 and v0.10.1 and v0.10.0 in the weeks before that, so the release cadence is roughly monthly at the point the material was captured. Running through npx means upgrades are a version bump rather than a rebuild, and the @latest tag means you get them without asking. That is convenient and also means behaviour can shift under a client configuration you did not touch, which is the argument for pinning a version once a setup works. On licensing, the repository metadata reports NOASSERTION, while the README carries MIT and Apache 2.0 badges pointing at LICENSE-MIT and LICENSE-APACHE. Those two signals disagree, and the only way to resolve it is to read the licence files in the repository and, if the dual licence matters to your legal review, ask. Nothing in the supplied material explains the discrepancy, so I will not guess at it. A dual MIT and Apache 2.0 grant is a permissive arrangement, but the metadata as reported does not confirm it.
Editorial conclusion
Adopt it if you already drive Firefox and want an MCP client to inspect pages, capture network traffic and take snapshots inside a browser you launch yourself. Do not adopt it for cloud-hosted agents, for Chromium-only test suites, or as a replacement for a scripted end-to-end test runner. Before wiring it into a client, verify three things: that the licence files in the repository match the MIT and Apache 2.0 badges rather than the NOASSERTION value reported alongside the project, that you have created a dedicated Firefox profile instead of pointing --profile-path at your daily one, and that the tool preset you pass is the narrowest one that still covers your task, since the default basic preset already includes evaluate_script.
Community notes