Браузерный MCP-сервер нужен ровно в одном случае: у сервиса нет API, а данные оттуда получить надо. Разбираем, как это устроено, что даёт на практике и почему это последний путь, а не первый.
Короткий ответ
Агент получает управление настоящим браузером: открыть страницу, нажать, заполнить форму, забрать содержимое. Технически это Playwright или подобный инструмент, обёрнутый в MCP-сервер.
Когда брать: API нет и не предвидится, а работа повторяется. Когда не брать: API есть. Тогда браузер — лишний слой, который ломается от любой правки вёрстки.
Что это позволяет
- Забрать данные с сайта без API — цены, остатки, статусы, таблицы из личного кабинета.
- Заполнить форму там, где нет интеграции: заявка, отчёт, выгрузка по кнопке.
- Проверить, что видит пользователь — как страница выглядит и работает на самом деле.
- Пройти сценарий целиком — залогиниться, дойти до нужного раздела, выгрузить файл.
Типичный рабочий пример — мониторинг цен на сайтах: агент раз в день обходит страницы и пишет, что изменилось.
Почему это последний путь
Три причины, по которым браузерная автоматизация хуже прямого доступа:
1. Хрупкость. Поменяли вёрстку — сценарий сломался. API меняется редко и с предупреждением, разметка страницы — когда угодно.
2. Скорость. Браузер открывает страницу секундами там, где API отвечает миллисекундами. На сотне страниц разница становится решающей.
3. Правила сервиса. У многих сайтов автоматический сбор данных запрещён условиями. Технически возможно ≠ разрешено, и это стоит проверить до, а не после.
Поэтому порядок такой: сначала ищем API, потом официальный MCP-сервер, и только потом браузер. Что уже есть готового — в обзоре MCP-серверов.
Где браузер оправдан
Несмотря на всё выше, случаи есть, и в российской практике их немало.
Корпоративные системы без API. Внутренний портал, старая учётная система, кабинет поставщика — у всех есть веб-интерфейс и ни у кого нет документации на API. Пример из соседней темы — что делать, когда у КонсультантПлюс нет открытого API.
Личные кабинеты. Данные доступны вам, но только через интерфейс.
Разовая задача. Написать интеграцию дороже, чем один раз обойти браузером.
Безопасность: тут строже, чем обычно
Браузерный сервер получает возможность действовать от вашего имени в залогиненных сессиях. Это больше, чем доступ к данным, — это доступ к действиям.
Отсюда правила, которые не стоит считать перестраховкой:
- Отдельный профиль браузера для агента, а не ваш рабочий со всеми сессиями.
- Отдельная учётная запись в сервисе, с минимальными правами.
- Чтение по умолчанию. Нажатие кнопок — отдельное решение, а не побочный эффект.
- Никаких платёжных и административных разделов в зоне досягаемости.
И главное: агент, читающий веб-страницы, читает и то, что на них написано. Спрятанная в тексте инструкция может быть выполнена — это prompt injection, и браузерный доступ поднимает её из теории в практику. Общие принципы — в безопасности MCP.
Как подключить
Механика та же, что у любого MCP-сервера: взять готовый, прописать в конфигурации агента, выдать права. Пошагово — как подключить MCP-сервер, для Claude Code — отдельный разбор.
Если нужен не готовый сервер, а свой под конкретный сайт — как создать MCP-сервер.
Коротко
Браузерный MCP — обходной путь, и относиться к нему стоит соответственно: он решает задачу там, где прямого доступа нет, ценой хрупкости и дополнительных рисков. Если у системы есть API, берите API. Если нет — это рабочий вариант, но с отдельным профилем, отдельной учёткой и правом только на чтение.