С февраля 2026 года в Chrome появился экспериментальный API navigator.modelContext.registerTool() — браузерная реализация черновика стандарта WebMCP, который разрабатывает Web Machine Learning Community Group при W3C. Пока это Draft Community Group Report, а не финальный стандарт, и единственная реализация работает под флагом. Но механика, которую он описывает, уже достаточно конкретна, чтобы оценить последствия.

Чтобы понять, зачем это нужно, достаточно посмотреть на то, как ИИ-агенты работают с сайтами сегодня. ChatGPT Agent от OpenAI, Computer Use и Claude in Chrome от Anthropic, Comet от Perplexity — все они в той или иной мере используют подход «скриншот плюс клик»: агент делает снимок экрана, отправляет его в визуальную модель (1500–5000 input-токенов за кадр), определяет нужный элемент, кликает, ждёт редиректа, делает следующий скриншот. Одна задача — например, подписка на рассылку — занимает 5–20 шагов, 30 000–100 000 токенов и от одной до пяти минут. Стоимость — 5–50 центов за действие.

ПараметрСкриншоты (сегодня)WebMCP
Шагов на задачу5–201–2
Токенов на задачу30 000–100 0001000–2000
Latency1–5 мин1–3 с
Стоимость5–50 центовдо 1 цента

WebMCP меняет саму модель взаимодействия. Разработчик сайта заранее регистрирует действия — tools — прямо в JavaScript: имя, текстовое описание (по нему агент поймёт назначение), JSON Schema входных параметров и функцию-обработчик. Браузер хранит эту регистрацию в реестре текущей вкладки. Когда агент обращается к странице, он получает машиночитаемый список того, что страница умеет прямо сейчас, для этого конкретного пользователя. Вызов tool занимает 1–3 секунды, расходует 1000–2000 токенов, стоит меньше цента. Разница с подходом через скриншоты — около двух порядков по обеим осям: latency и стоимости.

Сайт регистрирует инструменты через navigator.modelContext.registerTool() — агент получает машиночитаемый список возможностей страницы без реверс-инжиниринга.

При этом авторизация работает через существующую сессию пользователя в браузере: агент получает ровно те возможности, которые открыты залогиненному пользователю. Никаких отдельных ключей для агента, никакой дополнительной документации. Браузер вызывает JS-функцию на странице — что она делает с запросом, решает разработчик сайта.

В спецификации уже есть базовые механизмы безопасности. Аннотация readOnlyHint позволяет заявить, что tool только читает данные и не меняет состояние. untrustedContentHint защищает от prompt injection — атаки, при которой вредоносный контент на странице пытается переопределить инструкции агента. Метод requestUserInteraction() останавливает выполнение и требует явного подтверждения от человека. Декларативная часть API — объявление tools прямо в HTML-разметке, без JavaScript — пока помечена как TODO.

Доступ агента к navigator.modelContext страницы сегодня возможен тремя способами: встроенный в браузер агент (Gemini в Chrome), расширение с content-script, или browser automation через DevTools Protocol. Агентская часть API ещё формируется — зафиксирована преимущественно сторона регистрации tools.

WebMCP — не единственный претендент на роль стандарта агентского взаимодействия с вебом. MCP-серверы Anthropic решают похожую задачу на уровне бэкенда. Agentic-браузеры Perplexity и Arc, браузерные расширения — альтернативные архитектуры. Какая из форм начнёт доминировать, станет понятно в ближайшие 2–3 года: экономика подтолкнёт туда, где дешевле, а при миллионе агентских действий в день разница в стоимости перестаёт быть абстрактной.

Для фронтенд-разработчиков WebMCP означает появление новой поверхности — интерфейса между веб-клиентом и агентом. Веб-клиент перестаёт быть конечной точкой и превращается в роутер между бэкендом и чужим клиентом. Параллельно в браузере может поселиться локальная модель, принимающая часть решений, — и тогда логика исполнения становится недетерминированной. Отлаживать такой код иначе, чем обычный JavaScript: он не падает с ошибкой, просто описание tool оказалось двусмысленным, и модель выбрала не тот путь. Это другая дисциплина, навыков для которой у сообщества пока нет.