Browser MCP extension: let AI use your real Chrome tab

A browser extension paired with a local Model Context Protocol (MCP) server can hand your AI agent the Chrome or Edge tab you already have open, logged-in sessions included, instead of a blank headless browser. The ScreenSync browser MCP extension does this through a hub on your own computer: Claude Code, Claude Desktop, Cursor or VS Code call web_* tools, the extension runs them in your tab, and anything that looks destructive on a site you have not trusted waits for your approval.

Why use your real tab instead of a headless browser

Most browser automation starts a fresh browser profile. That is right for CI, but it gets in the way when you want help with the page in front of you. A fresh profile has no cookies, so the agent lands on your login page, then a 2FA prompt, then an SSO redirect it cannot finish. Staging sites behind a company login are out of reach.

Your real tab already has the session, the feature flags, the half-filled form and the bug you are staring at. A browser MCP extension lets the agent work there.

The isolation row is the trade-off: an agent in your real tab acts as you, so the safety model below matters.

How the extension connects your tab to an agent

Three pieces are involved:

• The hub, a small Node.js 18+ program for Windows, macOS or Linux. It serves HTTP on port 3000 to the extension (and to the Android app, if you use it), requires a bearer token (SCREEN_SYNC_TOKEN) on its API endpoints, and speaks MCP over stdio to your AI client.
• The extension, a Manifest V3 extension for Chrome or Edge 114 and later. It keeps a Server-Sent Events stream open to the hub.
• Your MCP client, which sees 226 tools. 197 of them are web_* browser tools.

When the agent calls a web_* tool, the hub pushes the request down that stream. The extension's service worker runs it through the approval gate, executes it on the target tab and posts the result back to the hub, which hands it to the agent. The hub only relays while it has heard the extension's heartbeat recently, so a closed browser reads as "not connected" instead of a hung call. If the phone side is new to you, start with what a screen MCP server is.

Set it up in five steps

1. Run the hub. Download the hub zip and unzip it, then double-click start-hub.bat on Windows or run sh start-hub.sh on macOS or Linux. It prints a pairing link and QR code and serves http://localhost:3000. Leave it running.
2. Load the extension. Download the zip from the ScreenSync browser extension page, unzip it, open chrome://extensions (or edge://extensions), switch on Developer mode, click Load unpacked and pick the unzipped screensync-extension folder.
3. Pair it. The welcome wizard finds localhost:3000 by itself when the hub runs on the same computer. From another machine, paste the pairing link the hub printed, and allow the one-time LAN permission if the browser asks for it. Browsers cannot use mDNS, so if the extension stays offline, work through fixing hub discovery and pairing on your LAN.
4. Connect your MCP client. Add the hub to your client's config, as shown below.
5. Check Web access. Web access is switched on by default, so the Web access for AI agents card in the extension dashboard should show a green pill. Then ask your agent to call web_status, which reports whether the extension is connected and which tab is active.

For Claude Code, a project .mcp.json looks like this (Claude Desktop takes the same block in claude_desktop_config.json):

{
  "mcpServers": {
    "screensync": {
      "command": "node",
      "args": ["<HUB_DIR>/screensync-hub.js"],
      "env": { "SCREEN_SYNC_TOKEN": "screensync-local-dev" }
    }
  }
}

Or register it from a terminal with claude mcp add screensync node "<HUB_DIR>/screensync-hub.js". To pass a token you changed, use --env as the Claude Code MCP documentation describes:

claude mcp add --env SCREEN_SYNC_TOKEN=<your-token> --transport stdio screensync -- node "<HUB_DIR>/screensync-hub.js"

Cursor and VS Code also run stdio servers; check your client's MCP docs for where the file lives, or follow the ScreenSync setup guide, which lists each layout.

What the agent can do in your tab

The agent picks tools itself, but knowing the main groups helps you write better prompts.

• See: web_screenshot returns the active tab as an image. Pass background: true while you are using the browser, so nothing jumps to the front. web_full_screenshot captures the full length of the page.
• Read: web_hierarchy returns the title, URL, visible text and a numbered list of interactive elements. web_page_digest gives a compact, token-bounded view, and web_markdown_extract turns an article into clean Markdown.
• Act: web_click takes visible text, a CSS selector or an index from web_hierarchy. web_type fills a field and can submit. web_scroll, web_navigate, web_tabs and web_tab handle scrolling, navigation and tabs.
• Debug: web_console reads console output, web_network reads fetch/XHR requests made after it starts capturing, and web_perf reports metrics such as LCP and CLS.

The hub also ships ready-made MCP prompts for the browser, among them web_see_and_report, web_form_autofill, web_visual_qa, web_reproduce_issue and web_debug_session. A typical request:

I'm logged into our staging admin. Open Orders, filter by "refunded" and open the first order. Find out why the total shows NaN.

A sensible agent calls web_status, then web_console once so console capture is installed before anything happens (a navigation resets it), uses web_hierarchy to find the filter, clicks with web_click by text, reads web_console again and finishes with a web_screenshot as evidence, all inside the session you already have.

The safety model: grants, approvals and a kill switch

Web access is on as soon as you install and pair the extension, so the controls below are what limit the agent from day one. The agent cannot change any of them.

Per-site grants. Each site has read, act and cookie flags that you manage on the dashboard's Web Access tab. Tools that read a page's content or act on it check the grant first. The exception is a short built-in trusted list: local development origins (localhost, 127.0.0.1 and .test domains) plus a few hosts pinned in the extension source (lib/consent.js in the unzipped folder). There the agent gets full access without a grant and its own confirmed argument counts as approval, so read that list before you rely on prompts. Anywhere else, a missing grant fails the call with "access not granted", and the agent can call web_request_access with a one-sentence reason. You then pick Deny, Allow once (read and act for 15 minutes) or Always allow this site. Only a person can answer, and a decline stops the agent from asking again for 10 minutes. The agent can read grants with web_consent but cannot change them.

Approval for destructive actions. On a site outside the trusted list, an action that looks destructive, such as a click on "Delete", an authenticated POST, a cookie edit or a permission grant, waits in an approval queue for up to 60 seconds. You get a count on the toolbar icon, a desktop notification and a card on the page with Approve and Decline. Silence counts as a refusal, and the agent cannot approve its own request by sending confirmed or force arguments.

Hard limits. chrome:// and edge:// pages, extension pages, the Chrome Web Store and PDFs are refused outright.

A kill switch. Turn the Web access toggle off, or press Alt+Shift+S (the default shortcut), and the agent loses the browser at once. web_extension_settings can read that switch; nothing over MCP can flip it.

Hand-offs instead of passwords. At a login, 2FA prompt, CAPTCHA or payment step, the agent should call web_takeover, which pauses it and asks you to do that part. web_request_help does the same for any step that needs a human.

Two habits add a margin: run agent work in its own window with web_agent_window (it gets an amber border, and borrowing one of your other tabs needs approval), and use web_profile to pin calls to one browser profile. web_audit_log lists recent web tool calls. For a wider checklist, read our MCP security checklist for letting an AI control your phone; most of it applies to the browser too.

Where your page data goes

Page data travels from the extension only to your hub, over HTTP and SSE with the bearer token, on your computer or local network. EpsolDev runs no server for the hub or the extension, and no telemetry is sent home. Settings, grants and the action log stay in the browser's local extension storage until you remove the extension; display preferences such as the theme can sync through your browser account if browser sync is on.

The part that is easy to miss: anything the agent reads, screenshots and page text included, goes to that agent's model provider as part of the conversation. A screenshot shows whatever is visible in the tab, so close sensitive tabs first or switch Web access off. On a shared network, change SCREEN_SYNC_TOKEN from its default. The ScreenSync data policy has the full data map.

Limits worth knowing

• Chrome and Edge only, version 114 or later. There is no Firefox or Safari build.
• Sideloaded for now. You load it in Developer mode; a Chrome Web Store listing was in review at the time of writing.
• Local stdio clients only. ChatGPT's web app connects only to remote HTTPS MCP servers, so it cannot use the hub.
• Capture follows Chrome's rules. Chrome's capture API sees only the front tab of a focused window. With background: true, a tab that is not in front is captured through the DevTools protocol instead, and if that is impossible the call fails with CAPTURE_UNAVAILABLE rather than return the wrong page.
• Rate limited. Outside the trusted list, each site accepts up to 120 agent operations per minute.
• It acts as you. Start with read-only grants and widen them site by site.

This guide reflects hub and extension 1.14.4 (October 2026). ScreenSync is free while it is in active development.

Next steps

1. Install the hub and the extension, and confirm web_status reports a connected browser.
2. Run the web_see_and_report prompt on a page you are logged into, with read access only.
3. Grant act access to one staging site and try a web_reproduce_issue run on a real bug.