Chrome DevTools MCP: как подключить ИИ-агента к браузеру для диагностики сайта

Обычный coding agent хорошо видит исходный код. Но реальная проблема сайта часто находится не в файле как таковом, а в том, что происходит после запуска кода в браузере.

Почему LCP появился поздно?

Какой запрос задержал интерфейс?

Что именно вызвало ошибку в Console?

Какой JavaScript task занял main thread?

Почему память продолжает расти после закрытия компонента?

Раньше разработчик открывал DevTools, собирал эти данные вручную и уже потом передавал наблюдения модели. Chrome DevTools for agents позволяет подключить coding agent непосредственно к живому Chrome, чтобы он сам мог исследовать страницу через диагностические возможности браузера. Chrome описывает продукт как набор из MCP Server, Chrome DevTools CLI и Agentic Skills.

Это важное отличие от обычного browser automation.

Цель здесь не просто «нажать кнопку вместо пользователя», а дать агенту достаточно технического контекста для отладки.

Зачем coding agent доступ к живому браузеру

Представим проблему:

страница каталога иногда открывается нормально, а иногда после клика интерфейс зависает почти на секунду.

Исходный React-, Vue- или обычный JavaScript-код можно передать модели. Но из исходников ещё неизвестно:

• какой handler реально сработал;
• какие requests ушли;
• какой bundle выполнялся;
• сколько занял layout;
• была ли ошибка;
• что попало в performance trace;
• воспроизводится ли проблема именно в текущей сборке.

Live browser превращает обсуждение из:

«вот код, предположи причину»

в:

«вот работающая страница, воспроизведи проблему и собери доказательства».

Chrome DevTools for agents умеет подключать coding agent к Chrome через Model Context Protocol. Агент может исследовать страницу, получать структуру, взаимодействовать с элементами, читать Console и Network, записывать traces и работать с другими диагностическими инструментами. CLI предоставляет более узкий набор возможностей для shell-based automation.

Agentic Skills дополняют отдельные инструменты инструкциями, как правильно соединять их в диагностический процесс. Иными словами, agent получает не только команду «запиши trace», но и рабочую методику анализа performance, accessibility и других задач.

DevTools MCP и WebMCP решают противоположные задачи

Это особенно важно, потому что названия легко перепутать.

Chrome DevTools MCP — разработческий интерфейс.

Он позволяет вашему coding agent исследовать Chrome так, как разработчик использует DevTools: смотреть страницу, requests, console output, performance и другие технические данные.

WebMCP находится с другой стороны.

Это предлагаемый веб-стандарт, через который сайт может объявлять структурированные tools для браузерных AI-агентов. Например, интернет-магазин может намеренно предоставить действие add_to_cart, а сервис бронирования — book_flight.

Chrome прямо подчёркивает: DevTools MCP предназначен для debugging разработчиком, тогда как WebMCP tools рассчитаны на агентов, которыми пользователи взаимодействуют с сайтом.

Поэтому опубликованный на Vagizov.com материал про агентный просмотр в PageSpeed Insights рассматривает другую сторону вопроса: готов ли сайт к машинному взаимодействию. Здесь задача противоположная — дать разработчику AI-инструмент для диагностики браузера.

Из чего сейчас состоит Chrome DevTools for agents

На октябрь 2026 года это уже не один небольшой MCP server.

MCP Server

chrome-devtools-mcp подключает MCP-compatible coding agent к Chrome.

Официальный пример для Codex:

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

Для клиентов с обычным mcpServers используется конфигурация примерно такого вида:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

После подключения простой тестовый prompt может попросить агента проверить performance указанной страницы. В официальном руководстве ожидаемый результат — агент открывает Chrome и записывает performance trace.

Chrome DevTools CLI

CLI предназначен для случаев, когда браузерные возможности нужно использовать из терминала без полноценного MCP workflow.

Но это не абсолютная копия MCP-инструментария: Google прямо предупреждает, что CLI поддерживает targeted subset возможностей для shell automation.

Agentic Skills

Skills описывают более сложные рабочие методики.

Вместо бесконечного перечисления отдельных инструментов coding agent получает инструкции вроде:

воспроизведи → собери данные → проверь несколько источников → сформулируй гипотезу.

Это особенно ценно для performance-debugging, где один скриншот или один Console error редко достаточен.

Agent Plugins 1.0

В сентябрьско-октябрьском наборе Chrome DevTools MCP появилась поддержка Agent Plugins 1.0 — пакетного формата для модульных agent extensions.

Это не означает, что любой сторонний plugin автоматически безопасен. Plugin расширяет набор возможностей агента, поэтому его нужно оценивать так же, как другие инструменты и разрешения.

Что агент сейчас может исследовать

Октябрьский DevTools recap заметно расширил диагностический слой.

Поддерживаются performance traces и browser performance insights.

Network позволяет анализировать реальные запросы страницы.

Console может возвращать сообщения вместе с optional stack traces.

Source maps можно отключить и загружать по необходимости, что помогает не тратить лишнюю память на больших проектах.

Для memory investigation доступны heap snapshots; расширенные инструменты могут исследовать retained size, edges и объекты, удерживаемые V8 contexts. Часть memory debugging включается отдельной настройкой.

Также появились инструменты автоматизации PWA — установка, запуск, удаление и проверка OS integration. PWA-category не включена по умолчанию и активируется отдельно.

Это хороший пример архитектурного принципа проекта: не обязательно давать coding agent абсолютно все инструменты на каждый запуск.

Практический сценарий: AI-агент ищет причину медленной страницы

Предположим, на мобильной версии страницы услуги после загрузки интерфейс несколько секунд работает заметно хуже ожидаемого.

Самый безопасный старт — не подключать агента к обычному личному Chrome.

Запускаем отдельный профиль или используем:

--isolated

В этом режиме Chrome DevTools MCP создаёт временный user-data-dir, который очищается после закрытия браузера.

После этого coding agent получает задачу примерно такого уровня:

Открой тестовую страницу, воспроизведи загрузку на мобильном viewport, запиши performance trace и найди основные причины задержки. Не изменяй сайт и сначала покажи подтверждающие данные.

Это принципиально лучше prompt:

Сделай сайт быстрее.

Во втором случае агент заранее подталкивается к изменениям, хотя причина ещё не доказана.

Сначала Performance

Агент записывает trace и смотрит, где проходит основная задержка.

Например, он может обнаружить:

• длинную JavaScript-задачу;
• поздний запрос критичного изображения;
• дорогой layout;
• несколько тяжёлых сторонних scripts;
• работу, которая начинается сразу после первого пользовательского взаимодействия.

Главное — trace даёт временную картину реального браузера.

Затем Network и Console

Если задержка связана с сетью, нужно понять конкретный request.

Если вместе с проблемой появляется ошибка, агент может запросить Console и получить stack trace.

Октябрьское обновление отдельно добавило optional stack traces к list_console_messages, что заметно полезнее простого текста:

TypeError: undefined

Разработчику нужна точка происхождения ошибки, а не только её сообщение.

При необходимости — source maps

На production часто выполняется минифицированный bundle.

Source maps позволяют сопоставить stack с исходным кодом. Но на очень больших проектах автоматическая загрузка всех maps сама может потреблять много памяти.

Поэтому актуальная версия DevTools for agents позволяет отключать source maps и загружать их по требованию.

Получается разумный порядок:

сначала найти проблемную область → затем загрузить нужный source map.

А не наоборот.

Если проблема похожа на memory leak

Тогда одного Performance trace может быть мало.

Агент способен сохранить heap snapshot и исследовать распределение JavaScript-объектов. Расширенный memory tooling умеет работать с retained size, dominator chains, edges, duplicate strings и контекстами, удерживающими память.

Но и здесь AI-вывод:

«найден memory leak»

не должен быть финалом.

Правильная проверка — воспроизводимый сценарий:

снимок до → повторяем действие → снимок после → закрываем компонент → проверяем, что осталось удерживаться.

Затем формулируется гипотеза

Например:

после загрузки страницы сторонний widget запускает длинную синхронную задачу, из-за которой main thread блокируется; trace показывает конкретный script и соответствующий участок стека.

Это уже проверяемая гипотеза.

Фраза:

«страница медленная из-за слишком большого JavaScript»

слишком общая, чтобы менять production.

Только после подтверждения — исправление

Разработчик проверяет trace и код.

Затем меняется одна существенная причина:

• переносится инициализация;
• разбивается long task;
• меняется момент загрузки script;
• устраняется повторный listener;
• исправляется запрос;
• освобождаются удерживаемые объекты.

После этого агент записывает сопоставимый повторный trace.

Именно второй trace отвечает на вопрос, исправили ли мы проблему.

Общий подход похож на обычную работу с AI при разработке: модель особенно полезна как ускоритель исследования и рутины, но архитектурное и итоговое решение остаётся за разработчиком. Это подробнее разобрано в статье «Где AI помогает в создании сайта, а где только мешает».

Безопасность: агент видит не «браузер вообще», а то, что вы ему открыли

Официальная документация формулирует предупреждение достаточно прямо: Chrome DevTools for agents открывает агенту содержимое browser instance, поэтому тот может читать, исследовать, отлаживать и изменять данные в браузере или DevTools.

Это не ошибка архитектуры. Это и есть назначение инструмента.

Проблемы начинаются, когда полномочия шире задачи.

Авторизованный браузер передаёт авторизованную сессию

Если использовать existing browser session, агент получает её текущее состояние:

• cookies;
• вошедшие аккаунты;
• открытые приложения;
• содержимое страниц.

Google отдельно предупреждает об этом в configuration guide.

Поэтому для проверки публичной страницы нет причины подключать агент к Chrome, где одновременно открыты:

wp-admin, почта, банк, CRM и облачные сервисы.

Используйте отдельный профиль.

--autoConnect расширяет удобство, а не уровень доверия

Начиная с Chrome 144 MCP может автоматически подключаться к локальному Chrome через --autoConnect, если Remote Debugging разрешён в:

chrome://inspect/#remote-debugging

Chrome показывает запрос разрешения перед подключением. При этом MCP получает доступ к открытым окнам выбранного профиля.

Поэтому --autoConnect удобен для ситуации:

«я уже вручную воспроизвёл ошибку в браузере — теперь пусть агент исследует именно эту сессию».

Но для обычной автономной диагностики isolated profile часто проще контролировать.

Remote debugging port требует отдельной осторожности

При ручном подключении можно запустить Chrome с --remote-debugging-port и подключить MCP через --browser-url.

Документация проекта отдельно предупреждает: открытый debugging port позволяет приложениям на машине подключаться к браузеру и контролировать его. Поэтому при включённом порте нельзя одновременно использовать этот browser instance для чувствительных задач.

Это ещё одна причина использовать отдельный user-data-dir.

Ограничивайте JavaScript execution, если он не нужен

Современная конфигурация позволяет отключать инструменты выполнения JavaScript.

Октябрьский релиз отдельно расширил этот контроль на navigation и initialization scripts.

Если задача — только посмотреть Network или диагностические данные, возможность произвольного evaluate_script может быть лишней.

Принцип простой:

не давать инструмент только потому, что он существует.

Используйте filesystem roots

Chrome DevTools MCP поддерживает MCP roots и configurable filesystem roots.

Если клиент передаёт roots, server проверяет их перед файловыми операциями. Если roots нет, MCP Server по умолчанию ограничивает file-writing OS temporary directory. Флаг --allow-unrestricted-paths снимает это ограничение, поэтому его стоит использовать только с доверенной локальной конфигурацией.

Есть нюанс: в CLI unrestricted paths сейчас включаются по умолчанию. Поэтому shell-based workflow нужно рассматривать отдельно от более ограниченного MCP server setup.

Если агенту нужно сохранить trace в проект, дайте ему конкретный workspace.

Не весь домашний каталог.

Сеть тоже можно ограничивать

В текущей конфигурации доступны --allowed-url-pattern и --blocked-url-pattern.

Они позволяют ограничить browser targets по URL. Это не полноценный network sandbox уровня VM, о чём проект также прямо предупреждает.

Если нужна действительно жёсткая изоляция, одной MCP-конфигурации недостаточно — требуется OS/VM sandbox.

Почему MCP нельзя называть «уязвимостью браузера»

Сам факт того, что coding agent способен читать страницу, выполнять JavaScript или сохранять файл, не является уязвимостью.

Эти возможности документированы и включены специально для debugging.

В SECURITY.md проекта прямо указано, что запись файлов, загрузка source maps и другие предусмотренные действия сами по себе не рассматриваются разработчиками как vulnerability.

Правильный security-вопрос звучит иначе:

какие полномочия получит агент при текущей конфигурации и что произойдёт, если он ошибётся или обработает недоверенный контент?

Это обычная модель least privilege.

отдельный профиль
→
ограниченный origin
→
минимальный набор tools
→
узкий filesystem root
→
ручное подтверждение существенных действий.

Где Chrome DevTools MCP особенно полезен

Первый очевидный сценарий — производительность.

Агент может самостоятельно открыть страницу, записать trace, получить performance insights, сопоставить их с Network и исходным кодом и подготовить проверяемые гипотезы.

Второй — runtime errors.

Console stack traces плюс source maps помогают пройти от пользовательской ошибки до исходного модуля.

Третий — memory leaks.

Heap snapshots позволяют сделать investigation значительно глубже обычного «в Chrome растёт RAM».

Четвёртый — PWA.

Специальные tools могут автоматизировать установку и проверку lifecycle/OS state.

Пятый — проверка WebMCP implementation.

DevTools for agents умеет видеть зарегистрированные WebMCP tools и помогает разработчику отлаживать их schema и execution. Но сам WebMCP при этом остаётся функцией сайта, а не DevTools MCP.

Когда AI-агент внутри браузера лишний

Chrome DevTools MCP не должен заменять всю существующую QA-инфраструктуру.

Если тест всегда выполняет:

открыть URL → нажать кнопку → проверить текст

обычный Playwright test будет стабильнее и проще.

Если задача сводится к проверке HTTP-кодов тысячи URL, быстрее написать небольшой скрипт.

Если нужно узнать один waterfall, разработчик может открыть DevTools самостоятельно.

Agent особенно полезен там, где последовательность исследования заранее неизвестна.

Например:

почему эта страница иногда тормозит?

Агент начинает с trace.

Trace указывает на script.

Он проверяет Network.

Находит связь с конкретным request.

Смотрит Console.

Открывает source map.

Формулирует гипотезу.

То есть ценность появляется не в отдельном tool call, а в способности выбирать следующий диагностический шаг из предыдущих результатов.

Где проходит граница между помощником и автоматическим исправлением

Самая полезная модель для production-разработки:

агент исследует → разработчик подтверждает → код изменяется → тест подтверждает.

Не обязательно вручную писать каждую строку исправления. Coding agent вполне может подготовить patch.

Но утверждение:

«AI нашёл проблему и исправил её»

недостаточно.

Нужны проверяемые артефакты:

• trace;
• request;
• stack;
• heap snapshot;
• diff;
• test;
• повторное измерение.

Тогда Chrome DevTools MCP действительно сокращает время диагностики.

Разработчик перестаёт вручную копировать куски Console, Network и Performance в чат, а agent получает те же данные непосредственно из живого браузера.

Но архитектурная ответственность не меняется.

Чем больше доступ к browser session, filesystem и execution, тем тщательнее должны быть permissions.

Именно в этом заключается практический смысл Chrome DevTools for agents: не отдать браузер AI целиком, а предоставить coding agent ровно тот слой DevTools, который нужен для конкретной проверяемой инженерной задачи.