Content
# Browser-Integration MCP
[](../../releases/latest)
[](LICENSE)
[](#)
[](#)
[](#)
An MCP server for Claude Desktop that gives Claude a controllable browser agent — a **shared** browser running in a **separate, isolated profile** (Google Chrome, Microsoft Edge, or Vivaldi), driven over the Chrome DevTools Protocol from behind a **token-guarded local broker** (Chrome on a private pipe — no debugging TCP port). Windows-only. ~29 tools, Russian/English tool titles, Chrome DevTools telemetry disabled.
_MCP-сервер для Claude Desktop: даёт Claude управляемый браузер-агент — **общий** браузер в **отдельном изолированном профиле** (Chrome / Edge / Vivaldi), которым правят по Chrome DevTools Protocol из-за **локального брокера с токеном** (Chrome на приватном pipe — без TCP-порта отладки). Только Windows. ~29 инструментов, русские/английские названия, телеметрия Chrome DevTools отключена._
**Why this, and not just built-in web access?** A plain web fetch returns a page's static text and stops at anything behind a login or rendered by JavaScript. Browser-Integration drives a **real browser** through the Chrome DevTools Protocol, so Claude can sign in and work on **login-gated pages** (the agent keeps its own persistent browser session), act on live, JavaScript-rendered pages — click, type, fill forms, handle dialogs — and read the page at the **structural level** (accessibility tree, DOM, console, network) or run JavaScript in it, instead of guessing from a screenshot.
_**Зачем это, если есть встроенный доступ к вебу?** Обычное получение страницы возвращает её статический текст и останавливается на всём, что за логином или отрисовано через JavaScript. Browser-Integration управляет **настоящим браузером** через Chrome DevTools Protocol, поэтому Claude может входить в аккаунт и работать со **страницами за авторизацией** (агент держит собственную постоянную сессию браузера), действовать на живых JS-страницах — кликать, вводить текст, заполнять формы, обрабатывать диалоги — и читать страницу на **структурном уровне** (дерево доступности, DOM, консоль, сеть) или выполнять в ней JavaScript, а не догадываться по скриншоту._
**➡️ [Download the latest installer / Скачать установщик](../../releases/latest)** · Windows · MIT License
> **⚠️ Unsigned installer.** The installer is not code-signed, so Windows SmartScreen (or your antivirus) may warn on first run. If you downloaded it from this repository's **Releases** page, you can proceed via **More info → Run anyway**. The full source of the installer is in this repository — nothing is hidden.
>
> _⚠️ Установщик без цифровой подписи — при первом запуске Windows SmartScreen может показать предупреждение. Если файл скачан со страницы **Releases** этого репозитория — «Подробнее → Выполнить в любом случае». Исходный код установщика лежит здесь же, ничего не скрыто._
## Build from source / Сборка из исходников
```
cd payload && npm ci && cd ..
cd payload\broker && npm install && cd ..\..
ISCC.exe setup.iss # Inno Setup 6 -> build\BrowserIntegrationMCP-Setup-v5.0.4.exe
```
`node_modules/` is not committed. `npm ci` in `payload/` restores `chrome-devtools-mcp` (pinned in `package-lock.json`); `npm install` in `payload/broker/` restores the broker's `ws` dependency. The shipped installer bundles a **rebrowser-patched** `chrome-devtools-mcp` for anti-detection — a plain `npm ci` restores the stock package, so for the patched build use the installer from **Releases**.
_`node_modules/` в репозиторий не коммитится. `npm ci` в `payload/` восстановит `chrome-devtools-mcp` (зафиксирован в `package-lock.json`); `npm install` в `payload/broker/` — зависимость `ws` брокера. В поставляемом установщике `chrome-devtools-mcp` **пропатчен rebrowser** (против детекта) — обычный `npm ci` ставит сток-версию, поэтому для пропатченной сборки берите установщик со страницы **Releases**._
---
<details>
<summary><b>📖 English — full README</b></summary>
<br>
# Browser-Integration MCP
## Legal
### Trademarks
Not affiliated with, endorsed by, or sponsored by Vivaldi Technologies AS, Google LLC, Microsoft Corporation, or Anthropic PBC. Vivaldi, Google Chrome, Microsoft Edge, and Claude are trademarks of their respective owners.
### Third-party (bundled)
Bundles chrome-devtools-mcp (Copyright Google LLC, licensed under Apache-2.0). Its LICENSE and THIRD_PARTY_NOTICES ship inside `node_modules/chrome-devtools-mcp`.
### Usage / Intended use
Intended for lawful, personal use. The tool automates a copy of a supported browser (Google Chrome, Microsoft Edge, or Vivaldi) that you installed yourself, via Chromium's built-in DevTools Protocol (CDP) using public command-line switches; it does not modify, reverse-engineer, redistribute, or bundle any browser or Claude, and runs as an MCP extension inside your own Claude Desktop. You are responsible for complying with applicable law and with the terms of the software it works with (your browser's terms of use or EULA and Anthropic's Usage Policy / Consumer Terms), and for any actions performed through the browser agent.
### Disclaimer of Warranty and Limitation of Liability
This software (the "MCP") is provided "AS IS" and "AS AVAILABLE", without
warranty of any kind, whether express, implied, or statutory, including but not
limited to the implied warranties of merchantability, fitness for a particular
purpose, title, and non-infringement.
Installation and use of the MCP are carried out solely at the user's own free
will and risk. To the maximum extent permitted by applicable law, in no event
shall the author be liable for any claim, damages, or other liability -
including, without limitation, any theft, leakage, disclosure, alteration,
corruption, deletion, or loss of data, or any direct, indirect, incidental,
special, exemplary, punitive, or consequential damages - arising from, out of,
or in connection with the MCP, its use or inability to use it, or any actions
performed through it, even if the author has been advised of the possibility of
such damages.
The user bears full responsibility for operating the MCP and for any
consequences thereof.
By installing or using the MCP, the user acknowledges,
agrees to, and accepts these terms.
---
## What it is
Browser-Integration is an MCP server for Claude Desktop that gives Claude a
controllable browser agent. Under the hood it uses `chrome-devtools-mcp`
(Chrome DevTools Protocol) driving a separate instance of a supported browser (Google Chrome, Microsoft Edge, or Vivaldi) running a
clean, isolated profile. Claude gets ~29 tools: navigation, clicks, typing,
page snapshots, network, scripting, and so on. Tool titles are shown in
Russian and English, and Chrome DevTools telemetry is disabled.
**Why this, and not just built-in web access?** A plain web fetch returns a page's static text and stops at anything behind a login or rendered by JavaScript. Browser-Integration drives a **real browser** through the Chrome DevTools Protocol, so Claude can sign in and work on **login-gated pages** (the agent keeps its own persistent browser session), act on live, JavaScript-rendered pages — click, type, fill forms, handle dialogs — and read the page at the **structural level** (accessibility tree, DOM, console, network) or run JavaScript in it, instead of guessing from a screenshot.
Key idea: the agent works not in your everyday browser but in a **separate,
shared browser** owned by a small local **broker**. Chrome itself runs on a
private pipe (no debugging TCP port); the broker exposes a loopback WebSocket
guarded by a random token and a connecting-process check. Multiple chats/apps
attach to the one browser and take turns. This keeps your main profile's data
out of reach and keeps the agent profile clean (it holds none of your everyday
data).
## Requirements
- **Node.js** - any version (located via PATH and standard install paths).
- **A supported browser** - Google Chrome, Microsoft Edge, or Vivaldi (any version; located via the registry and standard paths).
- **Windows** + **Claude Desktop** with unpacked-extension support.
Administrator rights are not required: everything is installed into the user
profile. The installer creates no registry entries (it only cleans up entries
left by older versions, under `HKCU`).
---
## How the MCP works
### Overview
```
Claude Desktop / Claude Code / ... (each an MCP client; they take turns)
│ (stdio JSON-RPC)
▼
manifest.json ──► node i18n.js (our proxy)
│ (stdio JSON-RPC)
▼
chrome-devtools-mcp (attach mode, v1.4.0, rebrowser-patched)
│ (CDP over a token-guarded loopback WebSocket)
▼
Broker (payload/broker) (single active driver; token + peer check)
│ (CDP over a private pipe - no TCP port)
▼
Selected browser (shared agent profile)
```
Claude Desktop launches `node i18n.js`. `i18n.js` is a thin proxy: it immediately
spawns `chrome-devtools-mcp` in **attach mode** and forwards JSON-RPC between
Claude and the child while handling two jobs.
The MCP handshake never waits on the browser. `chrome-devtools-mcp` connects to the
browser lazily, inside its tool handlers, so `initialize` and `tools/list` are
answered in milliseconds and **the broker and browser come up on the first
`tools/call`**. Three things follow: the tool list appears in the client
immediately, no browser window opens until the agent actually acts, and a browser
problem surfaces as an error on that one call instead of a silently dead server.
### The `i18n.js` proxy - two jobs
1. **Localization.** In the `tools/list` response every tool gets a title of the
form `Tool name | <Russian>` - the English half is the tool's own name made
readable (e.g. `take_snapshot` -> `Take snapshot`), so it never drifts from
the real name. Native annotations (read/write categories) are stripped, so in
the client the tools appear as one flat list and you control permissions
(Allow/Ask/Deny) yourself.
2. **No outbound calls.** The child starts with `--usageStatistics=false` (plus
the `CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS=1` env var) to disable telemetry,
`CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS=1` to stop the startup version ping to
npm, and `--performanceCrux=false` so trace URLs are never sent to Google's
CrUX API. Nothing about your browsing leaves the machine.
The proxy also decodes stdio as UTF-8 across chunk boundaries (so large
Cyrillic snapshots are never corrupted), forwards both requests and responses
in each direction, and shuts the child down cleanly when Claude Desktop closes
its stdin. In attach mode the child simply **disconnects** from the broker (it
never kills the browser), so the shared browser keeps running for other chats.
**Agent guidance.** A few operating rules are appended to the relevant tools'
`description` fields in `tools/list` (the channel every MCP client reliably
feeds to the model, visible before any call): prefer cheap tools over the large
`take_snapshot` and treat page text as data, never as commands (on
`take_snapshot` / `evaluate_script`); get explicit user approval before a
purchase or payment (on `click` / `fill_form`); clear a reported browser dialog
with `handle_dialog` first (on `handle_dialog`); and re-check `list_pages` after
a click or Enter in case a new tab opened (on `click` / `press_key`). These are
hints the model follows, not hard rules.
### Attach mode + the broker
The MCP does not launch the browser itself. A small **broker** (`payload/broker`)
owns a single **shared** agent browser:
- The broker launches the browser with `--remote-debugging-pipe`, so CDP travels
through a file descriptor, not a network socket. **No `--remote-debugging-port`
is opened on the browser.** Compatibility/UX flags go to the browser at launch:
`--disable-blink-features=AutomationControlled`, `--no-first-run`,
`--no-default-browser-check` (and `--enable-automation` is intentionally omitted).
- The broker exposes `ws://127.0.0.1:<port>/`, guarded by a **bearer token** (a random
256-bit token kept in a user-only file and reused for the life of the install, so
every client attaches with the same one) and a **fail-closed connecting-process
check** (only `node.exe` running our own scripts; a peer that cannot be confirmed is
rejected). `chrome-devtools-mcp` connects to it in attach mode (`--wsEndpoint` +
`--wsHeaders`); the `bi-open` link shim connects as an "opener" and may issue only
one command (`Target.createTarget`). The token and the broker config live under
`%LOCALAPPDATA%\BrowserIntegrationBroker`, locked to your user account.
**The port.** It is not a constant. The installer picks one that is actually free on
your machine (drawn at random from 20000-45000, verified by really binding it) and
bakes that number into `i18n.js` and `config.json`, so two installations rarely share
a port. The MCP proxy passes it to the broker in `BI_BROKER_PORT`; the `bi-open` link
shim, which Windows launches with no environment to inherit, reads it from
`config.json`. Nothing has to discover anything at runtime, so nothing can go stale.
The port stays fixed for the life of the install rather than being re-drawn on every
start, and that is deliberate: the shared port is also a **mutex**. Two brokers coming
up at the same moment hit the same bind, and the loser exits on `EADDRINUSE` *before*
it launches anything - which is what keeps a second browser off the shared profile. A
port re-drawn per start would let both brokers bind happily and open two browsers on
one profile. Reinstalling draws a new port; if a broker is still running on the old
one, the installer keeps that number instead, for the same reason. `BI_BROKER_PORT`
in the environment overrides everything, for anyone who wants a specific port.
`i18n.js` starts the broker on the first tool call (or connects to a running one). The shared
browser stays open across chats. To sign in to a site, ask the agent to open it and
log in yourself in the window - the session is saved in the agent profile and
persists across restarts.
**If you close the browser window.** The broker ends with the browser (the CDP pipe
closes), and that is fine: the broker is checked before every tool call, so the
agent's next action brings the browser back. There is no need to restart the chat.
**Where the broker runs from.** Not from the extension folder, but from a copy under
`%LOCALAPPDATA%\BrowserIntegrationBroker\runtime`, refreshed automatically whenever the
shipped broker changes. Claude Desktop is an MSIX-packaged app and installs extensions
under `%APPDATA%\Claude`, which for the package is a redirected view; a **detached**
child process leaves that view and cannot resolve a path its parent can read perfectly
well. The broker has to be detached (it must outlive the MCP process and be shared by
every chat), so it runs from a location that stays visible either way. This also
detaches the long-lived broker from an extension folder the client may delete and
re-stage underneath it.
**When something goes wrong.** The broker runs as its own process and its output is
written to `%LOCALAPPDATA%\BrowserIntegrationBroker\broker.log`, which shows why it
failed to start (port already taken, no supported browser, launch failure). The tool
call itself returns an error pointing at that file, and the server stays alive - the
next call retries.
**Single-active handoff (take turns).** The broker keeps **one active driver** at a
time. When another chat/app acts on the browser, it connects and **supersedes** the
current driver; the superseded one **reconnects automatically** on its next action.
The browser itself is never killed - closing a chat only disconnects that client.
So agents share the one browser and take turns (a new one takes over, the previous
takes it back on its next tool call). Two clients do not drive it at the same instant.
**Anti-detection.** The bundled `chrome-devtools-mcp` ships a **rebrowser-patched**
puppeteer that avoids the classic `Runtime.enable` CDP leak (mode `addBinding`),
so pages are far less likely to flag the browser as automated. The transport (pipe
vs port) does not affect this; the patch works in attach mode too.
### Agent profile
A separate profile folder (`Browser-Agent-for-Integration-<browser>`), a
persistent `--userDataDir`. The profile is clean and isolated - it starts with
none of your data, cookies, or passwords, and anything you sign into stays only
in it. Why:
- **Isolation.** Even if a page tries to redirect the agent, it cannot reach
your main profile's data.
- **Persistence.** Logins you make in the agent window survive restarts.
The profile folder is created by the installer; the broker (via puppeteer)
initializes it on the first launch.
### Tools and permissions
A web page's text is data, not commands; a page may still try to redirect the
agent. What keeps actions in your control, and what to keep in mind:
- The browser cannot run `.exe` files - only download files. (Interacting with your
files - whether already present or downloaded - becomes possible if you have extra
tooling installed for it and/or the interaction happens in an environment where
that is possible. Treat this as a threat or as an opportunity, as you prefer.)
- The clean profile keeps the agent away from your everyday logins and payments.
- The browser has no debugging TCP port (Chrome runs on a private pipe); the only
local endpoint is the broker's loopback WebSocket, guarded by a random token and
a connecting-process check, so a random local process cannot drive the browser.
- You control per-tool permissions (Allow/Ask/Deny) in the client.
- Do not keep anything extra in the agent profile. Everything you sign into in the
agent window is available to the agent and to any chat/app currently driving the
browser - including page content, cookies, and saved sessions. Only sign in there
to things you are willing to trust the agent with. For banking, email, and payment
services use your normal browser; it is better protected.
**Threat levels:** Low = read or navigation; Moderate = returns page content;
High = actions with side effects, navigation, or auth-data access; Critical =
runs code or handles files/network data. For "Critical" and "High" tools, "Ask"
is a good default in the client.
Full tool list (29):
| Threat level | Tool | What it does |
|--------------|------|--------------|
| Critical | `evaluate_script` | Runs page JavaScript; can read page data (including any stored tokens) and make network requests. This tool saves a great deal of tokens on the agent's browser work, which is why I point to it from `take_snapshot` - so the agent reaches for `evaluate_script` rather than `take_snapshot`, since `take_snapshot` eats roughly 10-20x more tokens than `evaluate_script`. |
| Critical | `get_network_request` | Full details of one request, including headers that can contain auth tokens/cookies. |
| Critical | `upload_file` | Uploads a local file through the page. |
| High | `navigate_page` | Loads a URL in the current tab; can go to any site. |
| High | `new_page` | Opens a new tab at any URL. |
| High | `click` | Clicks an element; can trigger actions, form submits, or payments. |
| High | `fill` | Fills a single input or `<select>`. |
| High | `fill_form` | Fills several form fields at once; can enter data including credentials and submit. |
| High | `type_text` | Types text into the focused input; can enter data including credentials. |
| High | `handle_dialog` | Accepts/dismisses a browser dialog; can confirm downloads or permission prompts. |
| Moderate | `get_console_message` | Reads one console message (may contain application data). |
| Moderate | `list_console_messages` | Lists the page's console messages. |
| Moderate | `list_network_requests` | Lists network requests (URLs/metadata) made by the page. |
| Moderate | `take_snapshot` | Captures the page's accessibility (text) tree; returns page content. |
| Moderate | `take_screenshot` | Screenshots the page or an element; may capture visible private data. |
| Moderate | `take_heapsnapshot` | Captures a JS heap snapshot; may contain in-memory application data. |
| Moderate | `drag` | Drags one element onto another. |
| Moderate | `press_key` | Presses a key or combination; can trigger shortcuts or submit. |
| Low | `list_pages` | Lists open tabs. |
| Low | `select_page` | Switches the active tab. |
| Low | `wait_for` | Waits until the specified text appears on the page. |
| Low | `hover` | Hovers over an element. |
| Low | `close_page` | Closes a tab. |
| Low | `resize_page` | Resizes the browser window. |
| Low | `emulate` | Emulates device/feature conditions. |
| Low | `performance_start_trace` | Starts a performance trace recording. |
| Low | `performance_stop_trace` | Stops the active performance trace. |
| Low | `performance_analyze_insight` | Returns details for a specific performance insight. |
| Low | `lighthouse_audit` | Runs a Lighthouse audit (a11y / SEO / best practices). |
---
## How the installer works
### Philosophy
The installer **prepares everything** and leaves only one final manual step to
the user. No administrator rights (only the user folder, nothing in
`Program Files`/`ProgramData`; the registry is touched only to clean up entries
from older versions). No downloads from the internet. A clean profile -
nobody's data is copied.
### Steps (in order)
1. **Precheck.** Finds Node.js and a supported browser (Chrome, Edge, or Vivaldi), and lets you choose one. No Node -> abort (code 1); no browser
-> abort (code 2). Paths are resolved via PATH, the registry (App Paths /
StartMenuInternet), and standard install locations.
2. **Deploy.** Copies the MCP folder to `Documents\Browser-Integration-mcp\
Core-Browser-Integration-mcp` and creates the profile folder.
3. **Bake.** Substitutes real values into `i18n.js` in place of the
placeholders: `__NODE__` (node path), `__BROWSER__` (selected browser exe
path), `__PROFILE__` (profile path). Each value is written as a JSON string
literal, so paths with spaces, Cyrillic, apostrophes, or `$` are escaped
safely. `__PORT__` is substituted as a bare number.
4. **Broker port.** Draws a random port in 20000-45000 and confirms it is free by
binding it for real (a port can be reserved by Windows or held in `TIME_WAIT`
with no visible listener), then bakes it into `i18n.js` and `config.json`. If a
broker is already listening on the port this install currently uses, that number
is kept instead - see "The port" above for why.
5. **Legacy cleanup.** Removes artifacts from any previous attach-mode install:
the `HKCU` browser registration and the three desktop shortcuts (which used
to launch the browser with a debugging TCP port).
6. **Self-check + report + instructions.** Writes a machine-readable result
(UTF-8, paths, chosen port, success flags), shows a "what was done" screen and
a screen with the manual step.
At runtime the agent browser is launched by the **broker** (bundled under
`payload/broker`, shipped with the MCP) on a private pipe; the compatibility/UX
flags are passed at launch:
```
--disable-blink-features=AutomationControlled
--no-first-run
--no-default-browser-check
```
### Folder layout (under Documents)
```
Browser-Integration-mcp\
├── Core-Browser-Integration-mcp\ ← the MCP itself (point Claude here)
└── Browser-Agent-for-Integration-<browser> ← the clean agent browser profile
```
### Manual steps after installation
1. **Load the MCP into Claude Desktop:** Settings -> Extensions (Advanced
Settings) -> "Install Unpacked Extension" -> select the
`Core-Browser-Integration-mcp` folder -> enable the extension.
That is the only required step. On first use the MCP starts the broker and the
shared agent browser opens; it stays open across chats (closing a chat does not
close it), and chats/apps take turns driving it. To sign in to sites, ask the
agent to open the page and log in yourself in the window. The profile is separate
and clean, and your sessions persist in it.
2. **(Optional) Open clicked links in the agent browser:** run
`Core-Browser-Integration-mcp\broker\install\register.ps1`, then choose
"Agent Browser" in Windows Settings -> Default apps. `unregister.ps1` reverses
it. (Windows requires the final default-browser pick to be manual.)
### Uninstallation
The uninstaller removes leftover registry entries and desktop shortcuts from
older versions. If you registered the agent browser as a default-browser
candidate, run `broker\install\unregister.ps1` first to remove that HKCU
registration and the "Agent Browser" shortcut. The MCP folder and the agent
profile can be removed manually.
---
## Project files (for development)
```
installer-src\
├── setup.iss ← Inno Setup script (English UI, ASCII)
├── installer-logic.ps1 ← all install logic (precheck/install)
├── payload\ ← what is delivered to the user (goes into the build)
│ ├── manifest.json ← MCP manifest
│ ├── i18n.js ← proxy (placeholders + localization + broker bootstrap + attach)
│ ├── broker\ ← the shared-browser auth broker (src, tools/bi-open, install)
│ └── node_modules\chrome-devtools-mcp ← bundled, rebrowser-patched
├── build\ ← the compiled installer
├── README.md ← project README (GitHub)
├── LICENSE ← MIT license (deployed with the MCP)
├── README.txt ← this file, EN (deployed with the MCP)
└── README.ru.txt ← Russian version (deployed with the MCP)
```
</details>
<details>
<summary><b>📖 Русский — полный README</b></summary>
<br>
# Browser-Integration MCP
## Правовая информация
### Товарные знаки
Не аффилировано с Vivaldi Technologies AS, Google LLC, Microsoft Corporation или Anthropic PBC, не одобрено и не спонсируется ими. Vivaldi, Google Chrome, Microsoft Edge и Claude — товарные знаки соответствующих правообладателей.
### Сторонние компоненты (в составе)
В составе — chrome-devtools-mcp (Copyright Google LLC, лицензия Apache-2.0). Его файлы LICENSE и THIRD_PARTY_NOTICES лежат внутри `node_modules/chrome-devtools-mcp`.
### Использование / назначение
Предназначен для законного личного использования. Инструмент автоматизирует установленный вами самими поддерживаемый браузер (Google Chrome, Microsoft Edge или Vivaldi) через встроенный в Chromium протокол отладки (CDP) публичными ключами командной строки; он не изменяет, не реверс-инжинирит, не распространяет и не встраивает ни один браузер и Claude и работает как MCP-расширение внутри вашего Claude Desktop. Вы отвечаете за соблюдение применимого права и условий ПО, с которым он работает (условия использования / EULA вашего браузера и Usage Policy / Consumer Terms компании Anthropic), а также за любые действия, совершённые браузер-агентом.
### Отказ от гарантий и ограничение ответственности
Настоящее программное обеспечение (далее — «MCP») предоставляется на условиях
«КАК ЕСТЬ» («AS IS») и «КАК ДОСТУПНО» («AS AVAILABLE»), без каких-либо гарантий —
явных, подразумеваемых или установленных законом, — включая, помимо прочего,
подразумеваемые гарантии товарной пригодности, пригодности для конкретной цели,
правового титула и ненарушения прав.
Установка и использование MCP осуществляются исключительно по собственному
свободному волеизъявлению и на собственный риск пользователя. В максимальной
степени, допускаемой применимым правом, автор ни при каких обстоятельствах не
несёт ответственности по любым требованиям, за любой ущерб или иную
ответственность — включая, без ограничения, любую кражу, утечку, раскрытие,
изменение, повреждение, удаление или потерю данных, а также любые прямые,
косвенные, случайные, специальные, штрафные или последующие убытки, —
возникающие из MCP, в связи с ним, из его использования или невозможности
использования либо из любых действий, совершённых с его помощью, даже если
автор был уведомлён о возможности таких убытков.
Всю ответственность за работу MCP и любые её последствия несёт пользователь.
Устанавливая или используя MCP, пользователь подтверждает, что ознакомлен с
настоящими условиями, согласен с ними и принимает их.
---
## Что это
Browser-Integration — это MCP-сервер для Claude Desktop, который даёт Claude
управляемый браузер-агент. Под капотом используется `chrome-devtools-mcp`
(Chrome DevTools Protocol), управляющий отдельным экземпляром поддерживаемого браузера
(Google Chrome, Microsoft Edge или Vivaldi) с чистым, изолированным профилем. Claude получает ~29 инструментов:
навигация, клики, ввод, снимки страницы, работа с сетью, скриптами и т.д.
Названия инструментов — на русском и английском, телеметрия Chrome DevTools отключена.
**Зачем это, если есть встроенный доступ к вебу?** Обычное получение страницы возвращает её статический текст и останавливается на всём, что за логином или отрисовано через JavaScript. Browser-Integration управляет **настоящим браузером** через Chrome DevTools Protocol, поэтому Claude может входить в аккаунт и работать со **страницами за авторизацией** (агент держит собственную постоянную сессию браузера), действовать на живых JS-страницах — кликать, вводить текст, заполнять формы, обрабатывать диалоги — и читать страницу на **структурном уровне** (дерево доступности, DOM, консоль, сеть) или выполнять в ней JavaScript, а не догадываться по скриншоту.
Ключевая идея: агент работает не в вашем обычном браузере, а в **отдельном,
общем браузере**, которым владеет небольшой локальный **брокер**. Сам Chrome
работает через приватный канал (pipe) — порт отладки по TCP не открывается;
брокер отдаёт локальный WebSocket, защищённый случайным токеном и проверкой
процесса-подключенца. Несколько чатов/приложений подключаются к одному браузеру
и работают по очереди. Так данные вашего основного профиля недоступны, а
агентский профиль остаётся чистым (в нём нет ваших повседневных данных).
## Требования
- **Node.js** — любая версия (ищется в PATH и стандартных путях установки).
- **Поддерживаемый браузер** — Google Chrome, Microsoft Edge или Vivaldi (любая версия; ищется в реестре и стандартных путях).
- **Windows** + **Claude Desktop** с поддержкой распакованных расширений.
Прав администратора не требуется: всё ставится в профиль пользователя.
Записей в реестр установщик не делает (только убирает записи, оставшиеся от
старых версий, в `HKCU`).
---
## Как устроен MCP
### Общая схема
```
Claude Desktop / Claude Code / ... (MCP-клиенты; работают по очереди)
│ (stdio JSON-RPC)
▼
manifest.json ──► node i18n.js (наш прокси)
│ (stdio JSON-RPC)
▼
chrome-devtools-mcp (attach-режим, v1.4.0, rebrowser-патч)
│ (CDP через локальный WebSocket с токеном)
▼
Брокер (payload/broker) (один активный «водитель»; токен + проверка процесса)
│ (CDP через приватный pipe — без TCP-порта)
▼
Выбранный браузер (общий агентский профиль)
```
Claude Desktop запускает `node i18n.js`. Файл `i18n.js` — тонкий прокси: он сразу
спавнит дочерний `chrome-devtools-mcp` в **attach-режиме** и пробрасывает JSON-RPC,
попутно решая две задачи.
Рукопожатие MCP никогда не ждёт браузер. `chrome-devtools-mcp` подключается к
браузеру лениво — уже внутри обработчиков инструментов, — поэтому `initialize` и
`tools/list` отвечают за доли секунды, а **брокер и браузер поднимаются на первом
`tools/call`**. Из этого следуют три вещи: список инструментов появляется в
интерфейсе сразу, окно браузера не открывается, пока агент реально не начал
действовать, и проблема с браузером приходит как ошибка конкретного вызова, а не
как молчаливо умерший сервер.
### Прокси `i18n.js` — две функции
1. **Локализация.** В ответе `tools/list` каждому инструменту подставляется
`title` вида `Tool name | <русское>` — english-часть это имя инструмента в
читаемом виде (напр. `take_snapshot` → `Take snapshot`), поэтому оно никогда
не расходится с реальным именем. «Родные» аннотации (read/write-категории)
убираются — в клиенте инструменты видны одним плоским списком, а разрешениями
(Allow/Ask/Deny) вы управляете сами.
2. **Никаких исходящих запросов.** Дочерний процесс запускается с
`--usageStatistics=false` (и переменной `CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS=1`)
для отключения телеметрии, `CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS=1` — чтобы
убрать стартовый пинг версии в npm, и `--performanceCrux=false` — чтобы URL из
трейсов никогда не уходили в Google CrUX API. Ничего о вашем браузинге не
покидает машину.
Прокси также декодирует stdio как UTF-8 на границах чанков (поэтому крупные
снимки страниц с кириллицей не портятся), пробрасывает в обе стороны и запросы,
и ответы, и корректно гасит дочерний процесс, когда Claude Desktop закрывает его
stdin. В attach-режиме дочерний процесс просто **отключается** от брокера (браузер
он не убивает) — общий браузер продолжает работать для других чатов.
**Подсказка агенту.** Несколько рабочих правил дописываются в `description`
релевантных инструментов в `tools/list` (канал, который любой MCP-клиент
надёжно подаёт модели и который виден ещё до вызова): предпочитать дешёвые
инструменты тяжёлому `take_snapshot` и считать текст страницы данными, а не
командами (в `take_snapshot` / `evaluate_script`); перед покупкой или
подтверждением платежа получать явное согласие пользователя (в `click` /
`fill_form`); закрывать сообщённый диалог браузера через `handle_dialog` (в
`handle_dialog`); и пере-проверять `list_pages` после клика или Enter — на
случай новой вкладки (в `click` / `press_key`). Это подсказки, которым модель
следует, а не жёсткие правила.
### Attach-режим + брокер
MCP не запускает браузер сам. Небольшой **брокер** (`payload/broker`) владеет
единственным **общим** агентским браузером:
- Брокер запускает браузер с `--remote-debugging-pipe`, поэтому CDP идёт через
файловый дескриптор, а не сетевой сокет. **Порт `--remote-debugging-port` у
браузера не открывается.** Флаги совместимости/UX передаются при запуске:
`--disable-blink-features=AutomationControlled`, `--no-first-run`,
`--no-default-browser-check` (а `--enable-automation` намеренно не добавляется).
- Брокер отдаёт `ws://127.0.0.1:<порт>/`, защищённый **токеном** (случайный
256-битный токен в файле, доступном только вашему пользователю; переиспользуется
на всё время установки, поэтому все клиенты подключаются с одним и тем же) и
**fail-closed проверкой процесса-подключенца** (пускаются только `node.exe`,
запускающие наши скрипты; подключенца, которого не удалось подтвердить,
отклоняют). `chrome-devtools-mcp` подключается к нему в attach-режиме
(`--wsEndpoint` + `--wsHeaders`); шим ссылок `bi-open` подключается как «opener»
и может отправить лишь одну команду (`Target.createTarget`). Токен и конфиг
брокера лежат в `%LOCALAPPDATA%\BrowserIntegrationBroker`, доступ — только
вашему пользователю.
**Порт.** Это не константа. Установщик выбирает порт, реально свободный на вашей
машине (случайный из диапазона 20000–45000, проверенный настоящим биндом), и
запекает это число в `i18n.js` и `config.json` — поэтому у двух установок порт
совпадает редко. Прокси передаёт его брокеру через `BI_BROKER_PORT`, а шим ссылок
`bi-open`, который Windows запускает без наследуемого окружения, читает его из
`config.json`. Во время работы ничего не нужно «обнаруживать», а значит нечему и
устареть.
Порт остаётся неизменным на всю установку, а не выбирается заново при каждом
запуске, и это сделано намеренно: общий порт работает ещё и **мьютексом**. Два
брокера, поднимающиеся одновременно, упираются в один и тот же бинд, и проигравший
выходит по `EADDRINUSE` *до* того, как что-либо запустит, — именно это не даёт
второму браузеру открыться на общем профиле. Порт, выбираемый заново при каждом
старте, позволил бы обоим брокерам спокойно забиндиться и открыть два браузера на
одном профиле. Переустановка берёт новый порт; если на старом ещё работает брокер,
установщик оставляет прежнее число — по той же причине. Переменная окружения
`BI_BROKER_PORT` перекрывает всё, если нужен конкретный порт.
`i18n.js` поднимает брокер при первом вызове инструмента (или подключается к уже
запущенному). Общий
браузер остаётся открытым между чатами. Чтобы войти на сайт, попросите агента
открыть его и залогиньтесь сами в окне — сессия сохранится в агентском профиле и
переживёт перезапуски.
**Если закрыть окно браузера.** Брокер завершается вместе с браузером (закрывается
CDP-канал), и это нормально: наличие брокера проверяется перед каждым вызовом
инструмента, поэтому следующее действие агента поднимет браузер заново. Чат
перезапускать не нужно.
**Откуда запускается брокер.** Не из папки расширения, а из копии в
`%LOCALAPPDATA%\BrowserIntegrationBroker\runtime`, которая обновляется автоматически
при смене версии. Claude Desktop — MSIX-приложение, и расширения ставятся в
`%APPDATA%\Claude`, что для пакета является перенаправленным представлением;
**отсоединённый** (detached) дочерний процесс выходит из этого представления и уже не
может разрешить путь, который родитель читает без проблем. Отсоединять брокер
обязательно — он должен пережить процесс MCP и быть общим для всех чатов, — поэтому он
запускается оттуда, где виден в любом случае. Заодно это отвязывает долгоживущий брокер
от папки расширения, которую клиент может удалить и пересобрать у него под ногами.
**Если что-то пошло не так.** Брокер запускается отдельным процессом, и его вывод
пишется в `%LOCALAPPDATA%\BrowserIntegrationBroker\broker.log` — там видно, почему
он не поднялся (занятый порт, не найденный браузер, сбой запуска). Сам вызов
инструмента в этом случае вернёт ошибку с указанием на этот файл, а сервер
останется живым: следующий вызов повторит попытку.
**Работа по очереди (single-active handoff).** Брокер держит **одного активного
«водителя»** за раз. Когда другой чат/приложение обращается к браузеру, он
подключается и **вытесняет** текущего водителя; вытесненный **автоматически
переподключается** при своём следующем действии. Сам браузер не убивается —
закрытие чата лишь отключает этого клиента. Так агенты делят один браузер и ходят
по очереди (новый перехватывает, предыдущий возвращает при следующем вызове). Два
клиента не управляют браузером в один и тот же момент.
**Против детекта.** Встроенный `chrome-devtools-mcp` использует **пропатченный
rebrowser** puppeteer, который избегает классической утечки CDP через
`Runtime.enable` (режим `addBinding`), поэтому страницы гораздо реже помечают
браузер как автоматизированный. Транспорт (pipe или порт) на это не влияет — патч
работает и в attach-режиме.
### Агентский профиль
Отдельная папка-профиль (`Browser-Agent-for-Integration-<браузер>`), постоянный
`--userDataDir`. Профиль чистый и изолированный — вначале в нём нет ваших данных,
куки, паролей, а всё, во что вы войдёте, остаётся только в нём. Причины:
- **Изоляция.** Даже если страница попытается увести агента, он не доберётся до
данных вашего основного профиля.
- **Постоянство.** Логины, сделанные в окне агента, переживают перезапуски.
Папку профиля создаёт установщик; брокер (через puppeteer) инициализирует её при
первом запуске.
### Инструменты и разрешения
Текст страницы — это данные, а не команды; страница всё же может попытаться
увести агента. Что держит действия под вашим контролем и о чём стоит помнить:
- Браузер не может запускать `.exe` — только скачивать файлы. (Взаимодействие с
вашими файлами — будь то имеющимися или скачанными — будет возможно, если у вас
установлен дополнительный инструментарий для взаимодействия и/или само
взаимодействие происходит в среде, где это возможно. Можете воспринимать это
как угрозу или как возможность.)
- Чистый профиль держит агента вдали от ваших повседневных логинов и платежей.
- У браузера нет отладочного TCP-порта (Chrome на приватном pipe); единственная
локальная точка входа — WebSocket брокера, защищённый случайным токеном и
проверкой процесса, поэтому случайный локальный процесс не сможет рулить браузером.
- Разрешениями на каждый инструмент (Allow/Ask/Deny) вы управляете в клиенте.
- Не держите в агентском профиле лишнего. Всё, во что вы вошли в окне агента,
доступно агенту и любому чату/приложению, которое сейчас управляет браузером —
включая содержимое страниц, куки и сохранённые сессии. Логиньтесь там только в
то, что вы готовы доверить агенту. Для банков, почты и платёжных сервисов
пользуйтесь обычным браузером, он защищён сильнее.
**Уровни угрозы:** Низкий = чтение или навигация; Умеренный = возвращает
содержимое страницы; Высокий = действия с последствиями, навигация или доступ к
данным авторизации; Критический = выполняет код или работает с файлами/сетевыми
данными. Для «Критический» и «Высокий» в клиенте удобно ставить «Спрашивать».
Полный список инструментов (29):
| Уровень угрозы | Инструмент | Что делает |
|----------------|------------|------------|
| Критический | `evaluate_script` | Выполняет JavaScript страницы; может читать данные страницы (включая любые сохранённые токены) и делать сетевые запросы. Этот инструмент очень сильно экономит токены на взаимодействие агента с браузером, поэтому я сделал ссылку на него в `take_snapshot`, чтобы агент чаще пользовался `evaluate_script`, нежели `take_snapshot`. Так как `take_snapshot` съедает примерно в 10-20 раз больше токенов, чем `evaluate_script`. |
| Критический | `get_network_request` | Полные детали одного запроса, включая заголовки, в которых могут быть токены авторизации/куки. |
| Критический | `upload_file` | Загружает локальный файл через страницу. |
| Высокий | `navigate_page` | Загружает URL в текущей вкладке; может открыть любой сайт. |
| Высокий | `new_page` | Открывает новую вкладку с любым URL. |
| Высокий | `click` | Клик по элементу; может запустить действия, отправку форм или платежи. |
| Высокий | `fill` | Заполняет одно поле или `<select>`. |
| Высокий | `fill_form` | Заполняет сразу несколько полей формы; может ввести данные, включая учётные, и отправить. |
| Высокий | `type_text` | Вводит текст в активное поле; может ввести данные, включая учётные. |
| Высокий | `handle_dialog` | Принимает/закрывает диалог браузера; может подтвердить загрузку или запрос разрешения. |
| Умеренный | `get_console_message` | Читает одно сообщение консоли (может содержать данные приложения). |
| Умеренный | `list_console_messages` | Список сообщений консоли страницы. |
| Умеренный | `list_network_requests` | Список сетевых запросов (URL/метаданные) страницы. |
| Умеренный | `take_snapshot` | Снимок дерева доступности (текста) страницы; возвращает содержимое. |
| Умеренный | `take_screenshot` | Скриншот страницы или элемента; может захватить видимые приватные данные. |
| Умеренный | `take_heapsnapshot` | Снимок кучи JS; может содержать данные приложения из памяти. |
| Умеренный | `drag` | Перетаскивает один элемент на другой. |
| Умеренный | `press_key` | Нажимает клавишу или сочетание; может вызвать горячие клавиши или отправку. |
| Низкий | `list_pages` | Список открытых вкладок. |
| Низкий | `select_page` | Переключает активную вкладку. |
| Низкий | `wait_for` | Ждёт появления указанного текста на странице. |
| Низкий | `hover` | Наводит курсор на элемент. |
| Низкий | `close_page` | Закрывает вкладку. |
| Низкий | `resize_page` | Изменяет размер окна браузера. |
| Низкий | `emulate` | Эмулирует устройство/условия. |
| Низкий | `performance_start_trace` | Запускает запись трейса производительности. |
| Низкий | `performance_stop_trace` | Останавливает активный трейс. |
| Низкий | `performance_analyze_insight` | Возвращает детали конкретного среза производительности. |
| Низкий | `lighthouse_audit` | Запускает аудит Lighthouse (доступность / SEO / практики). |
---
## Как устроен установщик
### Философия
Установщик **готовит всё** и оставляет пользователю один финальный ручной
шаг. Без прав администратора (только папка пользователя, ничего в
`Program Files`/`ProgramData`; реестр затрагивается лишь для очистки записей
старых версий). Без скачиваний из интернета. Чистый профиль —
ничьи данные не копируются.
### Шаги (по порядку)
1. **Precheck.** Ищет Node.js и поддерживаемый браузер (Chrome, Edge, Vivaldi) и даёт выбрать один. Нет Node → отказ (код 1); нет браузера →
отказ (код 2). Пути определяются через PATH, реестр (App Paths /
StartMenuInternet) и стандартные места установки.
2. **Развёртывание.** Копирует папку MCP в `Документы\Browser-Integration-mcp\
Core-Browser-Integration-mcp` и создаёт папку профиля.
3. **Запекание (bake).** Подставляет в `i18n.js` реальные значения вместо
плейсхолдеров: `__NODE__` (путь к node), `__BROWSER__` (путь к exe выбранного
браузера), `__PROFILE__` (путь к профилю). Каждое значение записывается как
строковый литерал JSON, поэтому пути с пробелами, кириллицей, апострофами
или `$` экранируются безопасно. `__PORT__` подставляется голым числом.
4. **Порт брокера.** Берёт случайный порт из 20000–45000 и убеждается, что он
свободен, реально забиндив его (порт бывает зарезервирован Windows или занят
в `TIME_WAIT` без видимого слушателя), после чего запекает его в `i18n.js` и
`config.json`. Если на порту, который использует текущая установка, уже
слушает брокер, число сохраняется прежним — почему, написано в разделе
«Порт» выше.
5. **Очистка легаси.** Удаляет артефакты прежней установки в attach-режиме:
регистрацию браузера в `HKCU` и три ярлыка на рабочем столе (они запускали
браузер с портом отладки по TCP).
6. **Самопроверка + отчёт + инструкция.** Пишет машиночитаемый результат
(UTF-8, пути, выбранный порт, флаги успеха), показывает экран «что сделано»
и экран с ручным шагом.
В рантайме агентский браузер запускает **брокер** (лежит в `payload/broker`,
поставляется с MCP) на приватном pipe; флаги совместимости/UX передаются при
запуске:
```
--disable-blink-features=AutomationControlled
--no-first-run
--no-default-browser-check
```
### Структура папок (в «Документах»)
```
Browser-Integration-mcp\
├── Core-Browser-Integration-mcp\ ← сам MCP (его вы указываете Claude)
└── Browser-Agent-for-Integration-<браузер> ← чистый профиль агентского браузера
```
### Ручные шаги после установки
1. **Загрузить MCP в Claude Desktop:** Настройки → Extensions (Advanced
Settings) → «Install Unpacked Extension» → выбрать папку
`Core-Browser-Integration-mcp` → включить расширение.
Это единственный обязательный шаг. При первом использовании MCP поднимает брокер,
и общий агентский браузер открывается; он остаётся открытым между чатами (закрытие
чата его не закрывает), а чаты/приложения ходят по очереди. Чтобы войти на сайты,
попросите агента открыть страницу и залогиньтесь сами в окне. Профиль отдельный и
чистый, а ваши сессии в нём сохраняются.
2. **(Опционально) Открывать кликнутые ссылки в агентском браузере:** запустите
`Core-Browser-Integration-mcp\broker\install\register.ps1`, затем выберите
«Agent Browser» в «Параметры Windows → Приложения по умолчанию». Откат —
`unregister.ps1`. (Финальный выбор браузера по умолчанию Windows требует
сделать вручную.)
### Деинсталляция
Uninstaller удаляет оставшиеся от старых версий записи реестра и ярлыки. Если вы
регистрировали агентский браузер как кандидат по умолчанию — сначала запустите
`broker\install\unregister.ps1`, чтобы убрать HKCU-регистрацию и ярлык «Agent
Browser». Папку MCP и профиль можно удалить вручную.
---
## Файлы проекта (для разработки)
```
installer-src\
├── setup.iss ← сценарий Inno Setup (UI на английском, ASCII)
├── installer-logic.ps1 ← вся логика установки (precheck/install)
├── payload\ ← то, что кладётся пользователю (идёт в билд)
│ ├── manifest.json ← манифест MCP
│ ├── i18n.js ← прокси (плейсхолдеры + локализация + подъём брокера + attach)
│ ├── broker\ ← брокер общего браузера (src, tools/bi-open, install)
│ └── node_modules\chrome-devtools-mcp ← в комплекте, пропатчен rebrowser
├── build\ ← собранный установщик
├── README.md ← README проекта (GitHub)
├── LICENSE ← лицензия MIT (устанавливается с MCP)
├── README.txt ← английская версия (устанавливается с MCP)
└── README.ru.txt ← этот файл, RU (устанавливается с MCP)
```
</details>
Connection Info
You Might Also Like
No recommendations available