On this page
The browser-use MCP server lets an AI client drive a real browser, step by step or
by handing a whole task to its own agent. Start it with
uvx --from 'browser-use[cli]' browser-use --mcp. It has no login layer.
TrustedMCP grades it C.
The C isn't about neglect. The project is very active. It comes from no authentication and from the ways a model can run code through it. You can reduce both with the setup below.
How we checked: on 2026-11-07 we read the MCP docs, the source, PyPI metadata, the MCP Registry entry, OSV, NVD and the repo's advisories and issues. We didn't install or run it.
What the browser-use MCP server can do
The PyPI package is browser-use, MIT licensed,
version 0.13.14 at the time of writing. The --mcp mode has 16 tools. It runs over stdio,
so it's local to your machine.
| Tools | What they do | Needs an LLM key? |
|---|---|---|
browser_navigate, browser_click, browser_type, browser_scroll, browser_go_back |
Control the page | No |
browser_get_state, browser_get_html, browser_screenshot |
Read the page | No |
browser_list_tabs, browser_switch_tab, browser_close_tab |
Manage tabs | No |
browser_list_sessions, browser_close_session, browser_close_all |
Manage sessions | No |
browser_extract_content |
Pull structured content out of a page with an LLM | Yes |
retry_with_browser_use_agent |
Run an autonomous agent on a task, up to 100 steps by default | Yes |
The agent tool is the one that sets browser-use apart. Its own description says to use it only as a last resort. It also runs on its own LLM, so every step costs you tokens on top of whatever your AI client uses.
How to set up browser-use MCP
You need uv for uvx, and Chrome or Chromium. The package
requires Python 3.11 or later.
Claude Code. This command is from the docs. More on client setup in Claude Code MCP setup.
claude mcp add browser-use -- uvx --from 'browser-use[cli]' browser-use --mcp
Claude Desktop, Cursor or Windsurf. The docs use the same block for all three:
{
"mcpServers": {
"browser-use": {
"command": "uvx",
"args": ["--from", "browser-use[cli]", "browser-use", "--mcp"],
"env": {
"OPENAI_API_KEY": "your-openai-api-key-here"
}
}
}
}
The file goes in one of these places:
- Claude Desktop:
~/Library/Application Support/Claude/claude_desktop_config.jsonon macOS, or%APPDATA%\Claude\claude_desktop_config.jsonon Windows. Restart it after editing. - Cursor:
~/.cursor/mcp.json - Windsurf:
~/.codeium/windsurf/mcp_config.json
By default the browser window is visible. Set BROWSER_USE_HEADLESS to true if you want
to hide it. The server keeps its data in three places: the browser profile in
~/.config/browseruse/profiles/default, downloads in ~/Downloads/browser-use-mcp, and
extraction files in ~/.browser-use-mcp.
Do you need an OpenAI key?
The docs mark OPENAI_API_KEY as required, but the source is narrower. The direct browser
tools don't use a model, so your AI client can do the thinking. Only
browser_extract_content and the agent tool need a key.
The docs also list ANTHROPIC_API_KEY as an alternative. We couldn't find that working in
the MCP server code. The agent tool builds an OpenAI client, or a Bedrock one if you set
MODEL_PROVIDER=bedrock, and ANTHROPIC_API_KEY is never read there. If you only have an
Anthropic key, expect the agent tool to fail and test it before you rely on it.
Pin the version
Commit messages call 0.13.14 the "final Python runtime version". A
draft pull request would replace
the Python engine, while keeping the Python install and CLI commands. It isn't merged and
the plan could change, but plain uvx picks up the newest release on its own. To stay put,
pin it. This line is our own and we haven't run it:
uvx --from 'browser-use[cli]==0.13.14' browser-use --mcp
Three things called browser-use MCP
Check which one you're installing. They carry different risks, and our grade covers the first one.
Local --mcp |
Local --cli-mcp |
Cloud server | |
|---|---|---|---|
| Where you find it | The MCP docs | The MCP Registry entry | The cloud docs |
| Runs | On your machine, stdio | On your machine, stdio | At https://api.browser-use.com/v3/mcp |
| Tools | The 16 above | browser_exec, browser_screenshot |
7 session tools, such as run_session |
| Login | None | None | API key |
| Model can run | JavaScript in pages, through the agent tool | Any Python on your machine | Tasks in a cloud browser |
| Paying for it | Your LLM key | No key for the server itself | Browser Use Cloud |
The middle column is the one to watch. browser_exec passes the model's code straight to
Python's exec(), with no sandbox in the MCP server. So if a registry-based installer sets
up browser-use for you, read the arguments it wrote. If they say --cli-mcp, a page that
tricks the model can run code as you.
Claude Code users will also see the Browser Use CLI recommended, installed as a skill. It isn't an MCP server, and by default it drives the Chrome you already have open, with your tabs and logins.
How to run browser-use MCP more safely
This block adds two settings to the docs' version. BROWSER_USE_ALLOWED_DOMAINS comes from
the source, not the docs' list of variables. We haven't run this:
{
"mcpServers": {
"browser-use": {
"command": "uvx",
"args": ["--from", "browser-use[cli]==0.13.14", "browser-use", "--mcp"],
"env": {
"BROWSER_USE_ALLOWED_DOMAINS": "*.example.com,*.example.org",
"ANONYMIZED_TELEMETRY": "false"
}
}
}
}
- Stay on
--mcp. Don't use--cli-mcpoutside a throwaway machine. - Leave the LLM key out unless you need the agent. With no real key, the agent tool has no model to run on, and that closes the route to running JavaScript through it. If your client supports it, you can also block that one tool.
- Set a domain allowlist with bare host names. Write
*.example.com, which covers the domain and its subdomains. Avoidhttps://example.com, because entries with a scheme are matched as a text prefix, sohttps://example.com.evil.testpasses too. - Keep your real logins out. The default profile is separate from your own Chrome, but it saves whatever you sign in to. Use test accounts, and clear the profile folder when you finish.
- Run it in a VM or a separate user account with no cloud credentials or SSH keys nearby. Our MCP security best practices cover the wider setup.
- Check telemetry. It's on by default and goes to PostHog. The
telemetry docs say it can
include task instructions and URLs visited.
ANONYMIZED_TELEMETRY=falseturns it off.
Don't treat allowed_domains as a wall
It's a useful filter, but not a security boundary. Several limits showed up in our check:
- The model can replace it. The agent tool takes its own
allowed_domainsargument, and in the source a non-empty list overrides the one you configured. So a page that tricks the model could widen the list for that agent run. The direct browser tools have no such argument. - Redirects may slip past. An open report says the check misses page-initiated navigation and redirects after an allowed page. We read the report but didn't test it, and no maintainer has answered it yet.
- A broken config removes it. An
open report shows that a
config.jsonthat can't be parsed gets overwritten with defaults, which drops any allowlist in it. The code in 0.13.14 still does this. From the source, the environment variable is applied after the file loads, so setting your list there should survive this. - IP addresses are allowed by default.
block_ip_addressesdefaults to false. With no allowlist, the browser can be sent tolocalhostor a cloud metadata address. You can set"block_ip_addresses": truein the default profile in~/.config/browseruse/config.json. A pull request to change the default is still open.
The default profile also grants clipboard read and write access to pages, according to
profile.py, so don't keep secrets on your clipboard while it runs. The underlying problem
is prompt injection: a browser agent reads untrusted pages
all day, and any of them can try to give it instructions.
browser-use MCP advisories
There's one advisory against the package:
CVE-2025-47241.
Putting a decoy domain in the username part of a URL could bypass allowed_domains. It was
fixed in 0.1.45, the same day, so any current install is fine. OSV also lists it as
PYSEC-2026-300, and GitHub has a duplicate entry, GHSA-f54f-hr32-586f. They're the same bug.
Other CVEs turn up when you search the name, but they aren't this server:
- CVE-2026-82637 and CVE-2026-82640 affect
browser-use web-ui, a separate project. - CVE-2026-62863 is MoLing, another server that only mentions browser use in its description.
One dependency point: 0.13.14 pins anyio==4.12.1, and OSV lists CVE-2026-63374 against it,
fixed in 4.14.2. It's reported in the repo
and still open. We didn't check whether browser-use reaches the affected TLS code.
Fixing common browser-use MCP errors
| You see | What to do |
|---|---|
CLI addon is not installed |
Include --from 'browser-use[cli]', as the docs say. |
spawn uvx ENOENT |
Your client can't find uvx. Use the full path from which uvx. |
| The browser won't start | Check Chrome or Chromium is installed, and that nothing else is using the same profile. Try BROWSER_USE_HEADLESS=false. |
| The agent or extract tool gives an auth error | The first-run config holds the placeholder key your-openai-api-key-here. Set a real OPENAI_API_KEY. |
| You need more detail | Set BROWSER_USE_LOGGING_LEVEL=DEBUG before running the command. |
Which MCP browser server should you use?
An MCP browser server lets an AI client control a web browser. We compare three listed servers here. All three grade C, for similar reasons: no authentication, and a model that can run code. They differ in what they're good at.
| browser-use MCP | Playwright MCP | Chrome DevTools MCP | |
|---|---|---|---|
| Best for | Handing over a whole web task | Testing your own app, step by step | Debugging a page's performance, network and console |
| Who decides each step | Your client, or its agent with a second model | Your client | Your client |
| Extra LLM cost | Yes, for the agent and extract tools | No | No |
| Browser | Chromium or Chrome, own saved profile | Chromium by default, also Firefox, WebKit, Edge | Live Chrome, with an --isolated option |
| Code the model can run | JavaScript through the agent tool; Python with --cli-mcp |
browser_run_code_unsafe, on by default |
JavaScript, off with --no-javascript-evaluation |
| Grade | C | C | C |
Our short version:
- Testing your own web app? Start with Playwright MCP. It needs no second model, and our Playwright guide covers the flags that matter.
- Chasing a slow page or a console error? Use Chrome DevTools MCP.
- Want to say "go and do this" and check the result later? That's what browser-use is for. Budget for the LLM calls, and treat the result as unverified.
Two other servers come up under this search. We haven't graded Browser MCP yet. BrowserTools MCP (browser-tools-mcp) is graded C: see its listing and guide. You can compare everything we have graded in browser automation.
If you need browser automation that works with your own logins and approval rules, we build custom MCP servers.
Why browser-use MCP grades C
We graded the local --mcp server. The cloud server isn't part of this grade.
| Check | Points | Why |
|---|---|---|
| Authentication | 0 of 30 | No login. Whatever starts it controls the browser and its saved sessions. |
| Maintenance | 25 of 25 | Release 0.13.14 on 2026-10-26, commits through 2026-10-30, several active maintainers. |
| Known CVEs | 25 of 25 | The one advisory was fixed the same day. The open items above are reports, not published advisories, so they don't count yet. |
| Transport | 0 of 20 | stdio, but the model can run JavaScript through the agent tool, and --cli-mcp runs Python. |
We lowered the transport points on 2026-11-07, to match how we score Playwright MCP and Chrome DevTools MCP. The letter stayed C. If an advisory is published for the open reports and stays unfixed, the CVE points will drop and the grade will likely fall to D. See the browser-use MCP listing and how TrustedMCP scores servers.
Frequently asked questions
Is the browser-use MCP server safe?
It's safe enough in a throwaway VM with test accounts. It isn't a good fit next to real logins
or credentials, because it has no authentication and a web page can try to steer the model.
Pin the version, stay on --mcp, and set an allowlist.
Is browser-use MCP free?
The local server is free and open source under the MIT licence. You pay for your own LLM key if you use the agent or extract tools. The cloud server is a paid, pay-as-you-go service.
Does browser-use MCP need an OpenAI API key?
Only for browser_extract_content and retry_with_browser_use_agent, going by the source. The
direct browser tools work with whatever model your AI client already uses, though the docs
describe the key as required.
What's the difference between browser-use --mcp and --cli-mcp?
--mcp is the documented server with 16 browser tools. --cli-mcp exposes browser_exec, which
runs any Python the model writes, and it's what the MCP Registry entry launches. Use --mcp unless
you've isolated the machine.
browser-use MCP vs Playwright MCP: which is better?
Playwright MCP suits step-by-step work and testing your own app, with no second model to pay for. browser-use suits handing over a whole task. Both grade C, and both need isolating. Neither is a security boundary.
What is the best MCP browser server?
It depends on the job. Playwright MCP suits testing your own web app, Chrome DevTools MCP suits debugging a slow page or a console error, and browser-use suits handing over a whole web task. All three grade C.
Is browser-tools MCP the same as browser-use MCP?
No. browser-tools-mcp is a separate server. It is graded C too; see its listing and setup guide. The setup and grade on this page cover browser-use only.
Can browser-use MCP use my logged-in Chrome?
The --mcp server starts with its own saved profile, not your everyday one, so you begin signed
out. Anything you sign in to there stays saved. The separate Browser Use CLI is the product that
attaches to your open Chrome by default.
Does browser-use MCP send data anywhere?
Pages go to your LLM provider when you use the agent or extract tools. Telemetry also goes to
PostHog unless you set ANONYMIZED_TELEMETRY=false.