Browser Relay
FreeNot checkedMCP server that drives a user's real Chrome browser via a WebSocket-connected MV3 extension, enabling tab management, navigation, page interaction, screenshots,
About
MCP server that drives a user's real Chrome browser via a WebSocket-connected MV3 extension, enabling tab management, navigation, page interaction, screenshots, and script evaluation through natural language.
README
Drives the user's real, logged-in Chrome from AI agent sessions without ever handing another browser client the user's cookies (which gets sessions invalidated). An MV3 extension lives inside real Chrome and executes commands sent over a WebSocket from a local relay daemon.
Architecture
Claude session -> MCP (HTTP :9277/mcp) -> relay daemon -> WebSocket -> MV3 extension -> real Chrome tabs
extension/- the Chrome MV3 extension.server/relay.js- the relay daemon: MCP streamable-HTTP server + WebSocket server. Node >= 18, single dependency (ws).deploy/ai.wecko.browser-relay.plist- launchd LaunchAgent template (macOS);install.shfills in your node and repo paths.install.sh- installs deps + the LaunchAgent and prints the two remaining manual steps.test/- MCP smoke test (e2e.sh), a direct tool-call helper (call.js), and a mock extension for testing the relay without Chrome.
The extension connects out to ws://127.0.0.1:9277/ws as a client (it does
not run a server itself), sends a hello on open, and answers every command
the relay sends with exactly one ok:true/ok:false reply.
Install
/bin/bash install.sh
This copies the LaunchAgent, (re)starts it, and waits for
http://127.0.0.1:9277/health to answer. It then prints two steps you do by
hand:
- Register the MCP server:
claude mcp add --transport http browserx http://127.0.0.1:9277/mcp -s user - Load the extension:
chrome://extensions-> enable Developer mode -> Load unpacked -> selectextension/.
Tools (relay commands)
| command | args | result |
|---|---|---|
list_tabs |
{} |
{tabs:[...]} |
new_tab |
{url?, active?} |
{id,url} |
close_tab |
{tab_id} |
{closed:true} |
activate_tab |
{tab_id} |
{id,title,url} |
navigate |
{url, tab_id?} |
{id,url,title} |
back |
{tab_id?} |
{id,url} |
forward |
{tab_id?} |
{id,url} |
snapshot |
{tab_id?, max_elements?} |
{tab_id,title,url,elements,truncated?,text_excerpt} |
click |
{ref, tab_id?} |
{clicked:ref} |
type_text |
{ref, text, submit?, clear?} |
{typed:ref} |
evaluate |
{js, tab_id?} |
{result} |
screenshot |
{tab_id?, format?} |
{mime,data_base64} |
wait_for |
{text, tab_id?, timeout_ms?} |
{found:true,waited_ms} |
tab_id is optional everywhere it appears - it falls back to the active tab
of the last focused normal window.
snapshot is the main way an agent finds things to act on: it walks the top
document (same-origin iframes are out of scope in v1) for interactive
elements, tags each one with a stable data-bx-id="eN" ref, and returns a
compact list plus a text excerpt of the page. click and type_text then
target elements by that ref.
Known limitations
- Synthetic input is not trusted input.
clickandtype_textdispatch real DOM events, but they are not OS-level input, so some sites (payment iframes, bot-detection-heavy forms) may reject or flag them. - Screenshots require the tab to be active.
chrome.tabs.captureVisibleTabonly captures the active tab of a window;screenshotbriefly activates the target tab if it isn't already, then restores the previous one. evaluatecan be blocked by a page's CSP. Strictscript-srcpolicies can reject the injected eval; when that happens the error is surfaced verbatim rather than swallowed. A future version should switch tochrome.userScripts.executein theUSER_SCRIPTworld, which is exempt from page CSP.- The MV3 service worker gets killed by Chrome. It is normal for
background.jsto be torn down and revived repeatedly; thebx-keepalivealarm (every ~24s) and the reconnect-on-close logic are what keep the WebSocket connection coming back. A short gap in connectivity right after Chrome starts or the SW is revived is expected. - Google (and similar) may challenge with reCAPTCHA or a security check. If that happens, the agent must stop and ask the human to clear it in the real browser window rather than trying to script around it.
- Same-origin iframes are not walked by
snapshotin v1.
Troubleshooting
curl 127.0.0.1:9277/health- confirms the relay daemon is up.tail -f relay.log- relay daemon stdout/stderr (from the LaunchAgent).- Reload the extension from
chrome://extensionsif it stops responding. - Inspect the service worker console:
chrome://extensions-> browserx relay -> "service worker" link, to see WebSocket connect/reconnect logs and any errors from injected scripts.
Installing Browser Relay
This server has no published package — it is built from source. Open the repository and follow its README.
▸ github.com/Wecko-ai/browser-relayFAQ
Is Browser Relay MCP free?
Yes, Browser Relay MCP is free — one-click install via Unyly at no cost.
Does Browser Relay need an API key?
No, Browser Relay runs without API keys or environment variables.
Is Browser Relay hosted or self-hosted?
Self-hosted: the server runs locally on your machine via the install command above.
How do I install Browser Relay in Claude Desktop, Claude Code or Cursor?
Open Browser Relay on unyly.org, pick your client tab (Claude Desktop, Claude Code, Cursor) and press Install — the config is generated automatically, no JSON editing.
Related MCPs
Playwright
Browser automation, scraping, screenshots
by MicrosoftPuppeteer
Browser automation and web scraping.
by modelcontextprotocolopentabs-dev/opentabs
Plugin-based MCP server + Chrome extension that gives AI agents access to web applications through the user's authenticated browser session. 100+ plugins with a
by opentabs-devrobhunter/agentdeals
1,500+ developer infrastructure deals, free tiers, and startup programs across 54 categories. Search deals, compare vendors, plan stacks, and track pricing chan
by robhunterCompare Browser Relay with
Not sure what to pick?
Find your stack in 60 seconds
Author?
Embed badge for your README
Browse similar
All browse MCPs
