brave-devtools-mcp Connects Brave to Agents
brave-devtools-mcp is an open-source Model Context Protocol server by triuzzi that gives coding agents access to Brave Software's Brave browser through DevTools. Can Claude Code OpenAI's Codex, Cursor and other agent clients inspect a real browser instead of guessing from source files alone? The answer is yes, with the usual catch: browser control is powerful, so the useful move is to wire it in with a narrow debugging boundary. For Cursor MCP users, this is best treated as a browser-debugging tool first, not a general-purpose remote-control surface.
What brave-devtools-mcp actually connects
brave-devtools-mcp is a TypeScript MCP server that exposes Brave DevTools capabilities to agent clients. MCP is a standard way for an AI client to call external tools, servers, and data sources through a shared protocol.
The repository describes the project as Chrome DevTools MCP parity rebuilt for Brave. In plain English, that means an agent can launch or attach to Brave, inspect console output, observe failed network requests, take screenshots, inspect accessibility state, run performance checks, and use memory or profiling features where supported.
The nice detail is that this is not only for one assistant. The README names Claude Code, Codex, Cursor, and OpenCode as intended clients, and it also includes a standalone brave-devtools CLI. As of August 12, 2026, the repository had 21 GitHub stars, an Apache-2.0 license, and a same-day push, so this is early open source rather than a long-established browser platform.
Watch for to hear “control Brave” and imagine a magic QA engineer. It is closer to giving your agent a proper inspection window. The agent can see what your app actually does in the browser, but it still needs a good task, a safe environment, and a human review pass.
What changes once the browser is in the loop
The day-to-day change is simple: the agent can stop inferring frontend failures from code alone. Instead of asking Cursor to “fix the broken dashboard,” you can ask it to open the local app in Brave, read console errors, check failed network requests, inspect the accessibility tree, and explain the highest-impact issue before changing files.
That matters most on bugs where the source code is only half the story. A React component may look fine until a feature flag changes a response shape. A CSS change may pass unit tests but hide a button at a real viewport. A backend route may return a 401 because the browser has a stale cookie, not because the TypeScript type is wrong.
A good Cursor workflow keeps the agent's browser observations close to the diff. For example, ask the agent to produce a short receipt before editing:
- URL opened
- console errors found
- failed network requests found
- accessibility or Lighthouse issue found
- files it believes are relevant
- proposed first edit
That receipt is boring on purpose. It gives you something reviewable in the IDE before the agent starts touching application code.
Don't let the browser session become a fog machine. If the agent clicks through five pages, changes local storage, submits a form, and then says “I found it,” you may not know which observation mattered. Keep the first pass observational.
Put a boundary around Cursor MCP browser access
The safest first setup is read-mostly browser debugging against a local or disposable environment. In Cursor, use MCP to make Brave available, then use cursor rules to tell the agent what it may inspect and what it must not mutate.
A small .mdc rule is enough to make the boundary visible:
---
description: Use Brave DevTools MCP only for local browser debugging
alwaysApply: false
---
When using Brave through MCP:
- Prefer local URLs such as http://localhost:3000.
- First collect console errors, failed network requests, screenshots, and accessibility findings.
- Do not submit forms, change account settings, purchase items, delete data, or run destructive JavaScript.
- Ask before using authenticated production sessions.
- Before editing code, summarize the browser evidence and the files you plan to change.
This is also where Cursor subagents and Cursor skills can help, but only if they stay boring. A “browser-debugger” custom subagent can gather evidence. A Cursor skill can store the exact checklist for triaging console, network, accessibility, and performance issues. Neither should become an always-on license to browse anything the developer can access.
If you keep an AGENTS.md in the repo, add the same boundary near the frontend app instructions. Local scope helps. The browser rules for apps/web should not silently apply to packages/billing-worker unless that is really what you want.
For a broader map of Cursor rules, skills, and subagents, see Subagents and skills. If your main pain is shared memory across multiple coding agents, Vibsync Shares Memory Across Cursor, Claude, Codex is the adjacent story.
A small decision table for trying it safely
Use brave-devtools-mcp when the bug needs a live browser observation. Do not use it as a shortcut around normal review, auth hygiene, or test isolation.
| Question | Good first answer | Keep out of bounds |
|---|---|---|
| What browser should the agent open? | A local Brave window or disposable profile | Your daily authenticated profile |
| What URLs should it inspect? | localhost, preview apps, seeded test data |
Production admin pages or customer data |
| What can it collect? | Console logs, network failures, screenshots, accessibility tree, performance notes | Secrets, tokens, private user data, unrelated tabs |
| What can it do before editing code? | Explain evidence and propose files to inspect | Click destructive buttons, submit forms, run arbitrary page scripts |
| What should the human review? | The browser receipt, code diff, and reproduction steps | A vague “fixed it” summary |
Permission-boundary note: start with observation, not action. The first useful integration test is “open my local app in Brave and tell me what is broken,” not “use my browser until the issue is fixed.”
A tiny experiment looks like this:
- Start the app locally with seeded test data.
- Install brave-devtools-mcp using the repository's current instructions.
- Restart Cursor so the MCP server is available.
- Ask the agent to inspect one route and return only a browser receipt.
- Approve code edits only after the receipt names the evidence and the likely files.
That gives you the value of real browser context without turning the browser into an unreviewed side channel.
Further reading
Next step
Try brave-devtools-mcp on one local frontend bug and require an evidence receipt before any code edit. If that feels useful, turn the boundary into a repo rule so the next browser-assisted fix is repeatable.