Объяснение WebMCP: предоставление инструментов ИИ-агентам браузеров вместо догадок
WebMCP позволяет веб-страницам предоставлять ИИ-агентам браузера реальные инструменты: как их зарегистрировать, оценить уровень риска, протестировать в Chrome, обеспечить безопасность, а также где можно найти поддержку в 2026 году.
Источники: Meet WebMCP: MCP’s Browser Cousin That Makes AI Agents More Accurate
Попросите ИИ-агента забронировать билет на самолет на веб-сайте и посмотрите, что произойдет. Он откроет страницу и начнет исследовать ее. Какой элемент — это выборник дат? В каком выпадающем меню находится пункт назначения? На какую кнопку нужно нажать дважды из-за модального окна, закрывающего ее? Иногда агенту удается добиться цели. Иногда он нажимает не на ту кнопку, заполняет поле чем-то ненужным или застревает на этапе оплаты из-за изменения макета после обучения модели.
Так сегодня работают большинство агентов, основанных на браузере. Они сканируют DOM, определяют назначение каждого элемента по его метке и расположению, а затем имитируют клики и нажатия клавиш, которые совершил бы человек. Эта техника называется актуализацией, и она отлично смотрится в демо-версии, но полностью терпит неудачу на практике. Достаточно изменить один класс CSS или переместить кнопку, и агент, который работал вчера, начинает давать сбои.
WebMCP — это ответ на эту проблему. Если вы знакомы с протоколом Model Context Protocol (MCP) на стороне сервера, суть решения легко понять: берется концепция инструментов и переносится в браузер, так что они остаются на страницах, которые вы создаете.
Почему недостаточно работы с DOM
В настоящее время агенты подключаются к сервису двумя способами:
- Интеграция с сервером. Сервис регистрирует инструменты в платформе ИИ через сервер MCP, OpenAPI или какой-либо проприетарный API, при этом ИИ взаимодействует непосредственно с сервером, не затрагивая браузер.
- Активация через браузер. Агент открывает страницу, как человек, и пытается определить, какие элементы необходимо нажать или заполнить.
Такой способ активации требует значительных ресурсов и легко приводит к ошибкам. Каждый шаг может быть неправильно интерпретирован, особенно в сложных, многоуровневых интерфейсах современных одностраничных приложений.
WebMCP добавляет третий способ взаимодействия, который не является ни интеграцией с бэкендом, ни автоматическим нажатием кнопок. Сам сайт указывает, что он может делать. Вместо того чтобы агент догадывался о функции кнопки «Оплата», разработчик описывает, что именно выполняет процесс оплаты, какие данные требуются и что возвращается.
Что такое WebMCP
WebMCP — это предложенный веб-стандарт от Группы сообщества веб-машинного обучения при W3C. Спецификация определяет JavaScript-API вместе с аннотациями для элементов HTML-форм, чтобы агент мог использовать функции страницы без необходимости догадок.
Сравните его с MCP бэкенда. Страница, реализующая WebMCP, ведет себя как сервер MCP, чьи инструменты выполняются в виде скриптов на стороне клиента. Там, где обычно требуется создавать отдельный сервер для предоставления функции, её можно зарегистрировать из JavaScript, уже работающего на странице.
Дизайн состоит из трех компонентов:
- Открытие: стандартный способ регистрации страницами инструментов, таких как
checkoutилиsearch_products, у агента. - JSON Schema: четкие определения ожидаемых входных и выходных данных, что снижает вероятность ошибок и недопонимания.
- Состояние: общая картина текущего контекста страницы, позволяющая агенту знать, с чем он может работать в данный момент.
Еще один момент: инструменты по-прежнему выполняются непосредственно на странице. Когда агент вызывает инструмент add_to_cart, результат отображается в интерфейсе, а не происходит незаметно. Это важно для доверия, поскольку пользователи могут видеть, что с ними делается, и ваша разработанная схема работы не обходится стороной.
Регистрация WebMCP на сайте
Добавление этого функционала на существующий сайт не подразумевает полной перестройки. Речь идет о дополнительном слое обмена данными, работающем поверх уже существующего бэкенда. Шаги:
1. Включите среду тестирования. Поскольку стандарт пока находится в стадии предложения, включите его вручную для экспериментов. В Chrome откройте chrome://flags/#enable-webmcp-testing, установите значение на «Включено» и перезагрузите браузер. Для более близкого к продакшну решения зарегистрируйтесь на пробную версию WebMCP origin, доступную начиная с Chrome 149, чтобы реальные пользователи могли использовать эту функцию без необходимости изменять настройки браузера.
2. Выбирайте инструменты, которые стоит показывать. Этот шаг легко недооценить. Не показывайте каждую функцию только потому, что у вас есть такая возможность. Подумайте, с какими действиями люди действительно хотели бы получить помощь от агента — обычно это те, у которых есть четкая цель: поиск, фильтрация, отправка формы, оформление заказа. Избегайте десятков инструментов на одной странице, поскольку каждый зарегистрированный инструмент занимает место в окне контекста, а длинный меню затрудняет выбор агента.
3. Выберите императивный или декларативный API. Императивный API регистрирует инструменты с помощью обычного JavaScript через функцию registerTool и подходит для более сложной логики, такой как управление состоянием, навигация или последовательное выполнение действий. Декларативный API позволяет добавлять аннотации непосредственно в стандартный HTML-формат <form>, при этом инструмент создается автоматически, что подходит для простых случаев, основанных на формах. У проектов React и Angular есть встроенные в фреймворки варианты: React предлагает пакет usewebmcp, где хук useWebMCP связывает жизненный цикл инструмента с моментами подключения и отключения компонента, а Angular имеет экспериментальную поддержку, позволяющую преобразовывать Signal Forms в инструменты.
4. Сделайте inputSchema более подробным. Это определяет степень понимания инструмента агентом. Запишите description на простом естественном языке, без внутренних сокращений, и укажите тип каждого свойства. Для замкнутого набора значений используйте enum, чтобы снизить вероятность отправки агентом недопустимых данных.
5. Установите annotations в соответствии с реальным уровнем риска. Каждому инструменту необходимо честное маркировочное обозначение:
readOnlyHint: true— для инструмента, который только читает данные и ничего не изменяет.consequentialHint: true— для действия с реальными последствиями, которое должно сначала запросить подтверждение у пользователя.untrustedContentHint: true— когда результат включает контент от других пользователей, такой как отзывы или комментарии, который может скрывать какие-либо инструкции.
6. Подключите функцию execute к существующему конечному пункту. Функция execute может просто вызывать уже существующий API-маршрут с использованием fetch(). Маршрут Laravel подойдет без проблем. Отдельного бэкенда WebMCP не требуется. Вы создаете фронтенд-мост к бизнес-логике, которая уже проверена в производственных условиях.
7. Протестируйте его. Установите расширение для Chrome под названием Model Context Tool Inspector (Chrome Web Store), откройте вашу страницу и посмотрите, какие инструменты регистрируются. Также можно связаться с представителем через это расширение, чтобы убедиться, что ваш инструмент вызывается и его схема корректно считывается.
8. Рассматривайте это как постепенное улучшение. Поддержка браузерами ограничена, поэтому обычные клики по кнопкам должны продолжать работать для посетителей, у которых отсутствует WebMCP. Это добавляет новый путь, но не заменяет старый.
Пример: инструмент для отслеживания статуса заказа
Возьмём онлайн-магазин, построенный на Laravel, с страницей статуса заказов. Обычный процесс включает в себя вход пользователя, открытие раздела «Мои заказы», выбор диапазона дат и просмотр списка заказов с информацией о статусе доставки. Сотрудник, использующий инструменты актуализации данных, должен будет найти соответствующие выпадающие списки и кнопку отправки, а затем парсить таблицу результатов из необработанного HTML, которая теряет структуру при малейших изменениях форматирования.
С помощью WebMCP один инструмент оборачивает уже существующий конечный пункт:
await document.modelContext.registerTool({
name: 'get_order_status',
description: 'Look up orders within a given timeframe. Returns order number, shipping status, and current location.',
inputSchema: {
type: 'object',
properties: {
timeframe: {
type: 'string',
enum: ['today', 'yesterday', 'last_7_days', 'last_30_days', 'last_6_months'],
description: 'Timeframe for the order lookup.'
}
},
required: ['timeframe']
},
annotations: {
readOnlyHint: true,
consequentialHint: false,
untrustedContentHint: false
},
execute: async ({ timeframe }) => {
const response = await fetch(`/api/orders/status?range=${timeframe}`, {
headers: { 'Accept': 'application/json' }
});
const data = await response.json();
return JSON.stringify(data);
}
});
Выделяются три важных момента. Параметр inputSchema избавляет агента от необходимости угадывать формат, поскольку он знает, какие значения принимает timeframe. Аннотация readOnlyHint: true указывает на отсутствие побочных эффектов у инструмента, поэтому подтверждение не требуется. Кроме того, функция execute просто вызывает существующий маршрут Laravel, поэтому ничего не нужно пересоздавать.
Процесс оплаты более чувствителен, поскольку происходит перевод денег и оформляется заказ. Для этого требуется другой сигнал:
await document.modelContext.registerTool({
name: 'checkout_cart',
description: 'Completes checkout for the currently logged-in user\'s cart.',
inputSchema: {
type: 'object',
properties: {
paymentMethod: { type: 'string', description: 'Payment method selected by the user' }
},
required: ['paymentMethod']
},
annotations: {
readOnlyHint: false,
consequentialHint: true,
untrustedContentHint: false
},
execute: async ({ paymentMethod }) => {
const response = await fetch('/api/checkout', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ payment_method: paymentMethod })
});
return await response.text();
}
});
При настройке consequentialHint: true браузер или агент понимает, что необходимо отобразить диалоговое окно подтверждения перед выполнением действия. Даже если агент нажмёт кнопку, окончательное решение остаётся за пользователем.
Чтобы перечислить инструменты, зарегистрированные на странице:
const tools = await document.modelContext.getTools();
console.log(tools);
Чтобы вручную запустить его для тестирования:
const [tool] = await document.modelContext.getTools();
const result = await document.modelContext.executeTool(tool, '{"timeframe": "last_7_days"}');
Полный цикл обработки запроса
Вот последовательность действий при общении с агентом, использующим инструмент get_order_status.
- Вы пишете агенту простым языком что-то вроде «найдите мои заказы прошлой недели», имея открытую страницу магазина.
- Агент запускает процедуру поиска, вызывая метод
getTools()на данной странице. - Страница возвращает список своих инструментов вместе с описаниями, включая
get_order_statusс его описанием и форматом ввода. - Агент сопоставляет ваш запрос с описаниями. Четкое описание помогает ему сразу выбрать подходящий инструмент.
- Агент вызывает метод
executeTool()с аргументами, сформированными на основе хода разговора, например{timeframe: 'last_7_days'}. - Функция
executeстраницы вызывает тот же самый конечный пункт Laravel с помощьюfetch(), как будто вы нажали кнопку. - Бэкенд отвечает в формате JSON, и инструмент передаёт его обратно агенту.
- Агент формулирует результат на естественном языке и отображает его, при этом вся информация остаётся видимой в интерфейсе страницы.
Почему это лучше, чем обычное выполнение действий?
- Меньше нагрузки на контекст. Агент читает компактную схему, а не тысячи строк маркировки, поэтому ответы поступают быстрее и стоят дешевле.
- Результаты остаются стабильными. Инструмент вызывает вашу реальную функцию, поэтому изменение цвета кнопки или перемещение элемента не нарушает её работу.
- Люди сохраняют контроль. Действия с высоким риском, помеченные как
consequentialHint: true, всё равно требуют подтверждения, поэтому агент не может их выполнить без запроса.
Безопасность
Поскольку инструменты находятся на ваших страницах, безопасность находится ближе к поверхности, чем в случае с backend MCP, который обычно работает изолированно на собственном сервере. Спецификация предусматривает несколько мер защиты:
- Изоляция исходного адреса. WebMCP работает только в документах с изолированным исходным адресом. Если страница включает параметр
document.domain, например через заголовокOrigin-Agent-Cluster: ?0, WebMCP отключается. - Политика разрешений. Регистрация инструментов контролируется политикой
tools, по умолчанию установленной на значениеself; поэтому iframes из других источников не могут регистрировать инструменты, если вы не разрешите это с помощью параметраallow="tools".
exposedTo. Ничто не делается доступным автоматически.readOnlyHint, consequentialHint и untrustedContentHint — это не просто метки. Они указывают, может ли агент запускать инструмент без подтверждения или следует ли ему осторожно обращаться с его результатами, поскольку в них могут содержаться ненадежные данные, такие как отзывы пользователей, которые могут использоваться для внедрения кода.Есть одно важное замечание: изоляция между вкладками все еще находится в стадии развития. Если агент работает в двух вкладках, нет ничего, что обеспечивало бы границу, предотвращающую утечку конфиденциальной информации из одной вкладки в другую. Для процессов с высоким уровнем доверия, таких как банковские операции, стоит обратить внимание на этот аспект перед тем, как полагаться на данную функцию.
Состояние поддержки браузерами
По состоянию на середину 2026 года это еще рано:
- В сентябре 2025 года Комьюнити-группа W3C Web Machine Learning официально приняла спецификацию.
- В Chrome с версии 149 доступен пробный режим, а полная поддержка в Chrome и Edge планируется к второй половине 2026 года.
- Для локальных экспериментов флаг
chrome://flags/#enable-webmcp-testingработает без участия в пробном режиме. - Расширение Model Context Tool Inspector показывает, какие инструменты зарегистрированы на странице, и может имитировать диалог агентов.
Предложение может ещё измениться, поэтому не стоит основывать на нём производственные функции. Используйте принцип постепенного улучшения. Там, где браузер поддерживает WebMCP, агенты получают более точный опыт, а там, где нет — работает ручной процесс, как раньше.
Текущие ограничения
- Отсутствие возможности браузинга без интерфейса. API предназначен для локальных рабочих процессов браузера с участием человека, а не для автоматизации без надзора.
- Дополнительные нагрузки на сложные интерфейсы. Приложения с запутанной системой управления состоянием, скорее всего, потребуют рефакторинга, чтобы инструменты отражали реальное состояние приложения.
- Для поиска инструментов необходимо посещение страницы. Клиенты могут узнать о наличии инструментов на сайте только путем посещения соответствующей страницы. В настоящее время отсутствует глобальный индекс, подобный схеме сайта, для инструментов.
- Пока нет ресурсов и подсказок. Два других примитива из полного формата MCP ещё не были включены в WebMCP. Если агенту необходимо читать документы или получать структурированные данные из других источников, всё равно требуется отдельный сервер MCP.
С чего начать
WebMCP дополняет backend MCP, но не заменяет его. Backend MCP остается подходящим решением для данных и логики, которые должны находиться на сервере, в то время как WebMCP идеально подходит для слоя взаимодействия с фронтендом: сложных форм, многократной навигации и действий, связанных с текущим состоянием интерфейса.
Безопасный способ начала работы:
- Включите локальный флаг и зарегистрируйте один простой инструмент, желательно только для чтения, например, для поиска продуктов.
- С самого начала правильно используйте
annotations. Не откладывайте на потом использованиеreadOnlyHintиconsequentialHint, поскольку они являются основой безопасности, определяющей, в какой степени агент может доверяться при работе с вашим инструментом. - Следите за репозиторием сообщества Web Machine Learning Community Group на GitHub, поскольку обсуждения в сообществе продолжают формировать спецификацию.
WebMCP ещё далек от совершенства, но направление развития очевидно. В интернете появляется специальный язык для взаимодействия с агентами, чёткий контракт между разработчиком и агентом вместо догадок на основе DOM. Для тех, кто привык к инструментам и схемам из backend MCP, этот сдвиг покажется знакомым. Теперь контракт находится прямо в браузере.