Открываем действия вашего сайта для AI-агентов с помощью WebMCP
WebMCP показывает, как регистрировать инструменты сайта через document.modelContext, задавать аннотации и безопасно запускать действия в сеансе входа.
WebMCP разворачивает направление Model Context Protocol. Вместо того чтобы агент подключался к серверу, который вы хостите, ваша страница сама регистрирует собственные инструменты в JavaScript через document.modelContext.registerTool(), а агент, у которого страница уже открыта, напрямую вызывает объявленные действия — вместо того чтобы кликать по интерфейсу и гадать, что означают поля вашей формы.
Если вы уже подключали MCP-сервер к кодинг-агенту, серверная модель вам знакома: процесс, транспорт, список инструментов, клиент, который подключается. Неудобный случай — как раз браузерный. Трафик агента приходит на отрендеренную страницу с уже выполненным входом в сессию, и до сих пор единственным путём было «актуирование» (actuation): прочитать DOM, догадаться, что делают кнопки, и надеяться, что шаг оформления заказа не перерисуется прямо посреди клика.
В этой статье разбираются механизмы, которые важны тем, кто отвечает за реальное приложение: как выглядит корректная регистрация инструмента, что именно три подсказки-аннотации меняют в поведении агента, где сегодня работают инструменты сайта и каковы последствия для безопасности от того, что инструмент выполняется внутри авторизованной сессии пользователя.
Ключевые выводы
- Инструменты регистрируются через
document.modelContext.registerTool(), которому требуются имя, описание иinputSchema;navigator.modelContext— более раннее пространство имён, которое всё ещё встречается в устаревших примерах. - Поведение агента меняют три подсказки-аннотации:
readOnlyHint,consequentialHintиuntrustedContentHint. - Зарегистрированный инструмент выполняется на живой странице под авторизованной сессией пользователя, поэтому каждая открываемая вами возможность — это возможность, которой агент может воспользоваться с полномочиями этого пользователя.
- Встроенный браузер ChatGPT не поддерживает декларативный API на основе HTML-форм и не обнаруживает инструменты внутри iframe, поэтому регистрируйте их императивно, в документе верхнего уровня.
- WebMCP — не канал обнаружения: Chrome относит обнаруживаемость инструментов к открытым ограничениям, поскольку до загрузки страницы агентом ничто не сообщает о наличии у сайта инструментов.
Инверсия: в чём отличие WebMCP?
Серверный MCP-сервер — это то, к чему агент подключается сам: настраивается один раз и доступен независимо от того, открыта ли какая-либо страница. WebMCP работает в обратную сторону. Документация OpenAI по site tools проводит границу по тому, где живут инструменты. MCP направляет AI-приложение к серверу — локальному или удалённому, — который находится вне страницы и работает независимо от того, открыт ли браузер. Сайт с WebMCP передаёт собственные возможности в виде готового набора инструментов, которые агент обнаруживает сразу по прибытии, и пользователю не нужно ничего устанавливать.
Выигрыш — в точности. Документация Chrome по WebMCP формулирует разницу через то, кто решает, что означает тот или иной элемент управления: с инструментом сайт заявляет об этом прямо, и агенту не остаётся ничего додумывать. Актуирование же даёт ему цепочку шагов и необходимость выносить суждение на каждом из них. Агент, вызывающий search_orders({ status: "open" }) по написанной вами схеме, не может промахнуться мимо выпадающего фильтра и не сломается из-за того, что вы переименовали CSS-класс.
Как зарегистрировать инструмент через document.modelContext.registerTool()?
Регистрация инструмента принимает объект с полями name, description и inputSchema; справочник Chrome по императивному API считает эти три поля обязательными, а annotations и функция execute отвечают за поведение. Выполняйте проверку доступности возможности перед вызовом — ровно так, как в собственном примере OpenAI, — потому что в большинстве браузеров этого API пока нет.
async function registerAgentTools() {
if (typeof document.modelContext?.registerTool !== "function") return;
await document.modelContext.registerTool({
name: "list_orders",
description:
"List the signed-in customer's orders, newest first, optionally filtered by fulfilment status. Returns order number, placed date, status and total.",
inputSchema: {
type: "object",
properties: {
status: {
type: "string",
enum: ["open", "shipped", "delivered", "cancelled"],
description: "Fulfilment status to filter by. Omit for all orders.",
},
limit: {
type: "integer",
minimum: 1,
maximum: 20,
description: "Maximum orders to return. Defaults to 10.",
},
},
required: [],
additionalProperties: false,
},
annotations: { readOnlyHint: true },
// Same function the orders table calls. The API still checks the session.
execute: async ({ status, limit = 10 }) => fetchOrders({ status, limit }),
});
}
Описание — единственное, что читает модель, решая, подходит ли этот инструмент под запрос, поэтому оно значит не меньше, чем стоящий за ним код. Назовите форму возвращаемых данных, назовите фильтр и скажите, чего инструмент не покрывает.
Обратите внимание, что здесь делает execute: он делегирует. Инструмент вызывает ту же функцию получения данных, что и UI, а сервер за ней применяет ту же авторизацию, которую применял и раньше. Рекомендации OpenAI направляют разработчиков к их существующей аутентификации и авторизации, а не к параллельному пути, и инженерная причина очевидна: два пути в коде к одной и той же возможности неизбежно разойдутся, и разойдётся незаметно именно тот, перед которым нет UI.
Что меняют три подсказки-аннотации?
Аннотации — это метаданные, которые сообщают агенту, как относиться к инструменту ещё до вызова. Chrome документирует три, и руководство Chrome по безопасности инструментов переформулирует каждую из них в терминах риска, о котором она сигнализирует.
| Подсказка | Когда устанавливать | Влияние на агента |
|---|---|---|
readOnlyHint | Инструмент только читает и ничего не меняет | Позволяет агенту оценить, нужно ли подтверждение вообще |
consequentialHint | Действие имеет реальные последствия и необратимо: платёж, перевод, бронирование | Указывает агенту или браузеру сначала получить подтверждение пользователя |
untrustedContentHint | Вывод содержит пользовательские или внешние данные | Помечает полезную нагрузку как недоверенную, чтобы агент обращался с ней с повышенной осторожностью |
Устанавливайте их для каждого инструмента осознанно. Инструмент cancel_subscription без consequentialHint — это инструмент, который агент может запустить без паузы, а инструмент, получающий отзывы, без untrustedContentHint передаёт модели блок текста, написанный посторонними, безо всякой пометки.
Где сегодня работает WebMCP?
Страница OpenAI о site tools описывает, где ChatGPT будет учитывать зарегистрированный инструмент: во встроенном браузере десктопного приложения ChatGPT, поддерживаемом в актуальном состоянии, где ChatGPT Work и Codex могут находить и вызывать всё, что предлагает страница. Модель тоже имеет значение: GPT-5.6 Sol и GPT-5.6 Terra поддерживаются, а на GPT-5.6 Luna WebMCP отключён. Рабочие пространства Enterprise и Edu не охвачены, и то, появится ли функция вообще, по-прежнему зависит от раскатки и от того, что регистрирует открытая страница. Стрелка в адресной строке показывает список инструментов, предоставляемых страницей, а всю функцию можно отключить в разделе Browser permissions.
Реализация в Chrome пока находится в статусе предварительной. Chrome документирует WebMCP за флагом chrome://flags/#enable-webmcp-testing для локальной разработки (нужно установить Enabled и перезапустить браузер), а также origin trial, к которому можно присоединиться начиная с Chrome 149. По умолчанию в стабильной версии он не включён, и заявления обоих вендоров о поддержке меняются, так что перед выпуском в продакшн сверяйтесь с первоисточниками.
Чего не поддерживает браузер ChatGPT
Документация OpenAI прямо говорит, что встроенный браузер покрывает лишь часть WebMCP, и называет два пробела. Инструменты, определённые через атрибуты HTML-форм, не становятся инструментами сайта, а инструменты, зарегистрированные внутри iframe, не обнаруживаются — включая iframe того же источника. Практическая рекомендация коротка: регистрируйте императивно, в документе верхнего уровня, и не полагайтесь ни на что экзотическое.
Ограничение по iframe — это ограничение ChatGPT, а не стандарта. Chrome помещает оба API за Permissions Policy tools, значение которой по умолчанию — self. При таком значении регистрировать инструменты могут документ верхнего уровня и фреймы того же источника, а кросс-доменный iframe — нет. Встроенный виджет с другого источника может регистрировать инструменты, если фрейму предоставлена политика tools, инструмент передаёт exposedTo со списком авторизованных источников, а вызывающая сторона передаёт fromOrigins в getTools(). Кроме того, Chrome ограничивает WebMCP документами с изоляцией по источнику (origin-isolated), поэтому страница, использующая document.domain, не получит API вовсе.
Ваш инструмент работает от имени авторизованного пользователя
Зарегистрированный инструмент выполняется внутри живой страницы под авторизованной сессией пользователя, а значит, каждая открытая вами возможность — это возможность, которой агент может воспользоваться с полномочиями этого пользователя. Вопрос об охвате состоит не в том, что было бы удобно автоматизировать. Он в том, с чем вы готовы согласиться, если это будет вызвано без единого клика.
Руководство Chrome по безопасности необычно прямолинейно объясняет, почему это важно. Модель воспринимает инструкции и данные как один непрерывный поток токенов, без границы между ними. Безопасность нельзя гарантировать внутри чего-то вероятностного. Prompt injection уже срабатывал — воспроизводимо — против агентных систем на лучших доступных моделях, и число таких атак в вебе продолжает расти. OpenAI говорит примерно то же и о самих инструментах: в документации по site tools и определения инструментов сайта, и возвращаемые ими результаты считаются недоверенным контентом.
Отсюда следуют три конкретные меры. Видимость инструментов изначально закрыта: другие сайты и кросс-доменные iframe не видят ваши инструменты, пока вы не укажете их источники в exposedTo; относитесь к инструментам только для чтения, раскрывающим пользовательские данные, с той же осторожностью, что и к инструментам записи. Chrome также отмечает путь доступа, который вы не открывали: расширения могут запрашивать и выполнять ваши инструменты из content script, а расширение с host_permission для вашего сайта в любом случае уже может выполнять на странице собственный JavaScript. И держите тексты короткими. Chrome рекомендует 500 символов на описание инструмента, 150 на описание каждого параметра, 30 на имена инструментов и параметров и 1,5 K на вывод инструмента, описывая все четыре значения как рекомендации, которые могут измениться с учётом обратной связи от экосистемы и позже быть формализованы. Работа над управлением согласиями продолжается, включая черновик спецификации requestUserInteraction() для того, чтобы задать пользователю вопрос посреди выполнения, — он ещё не выпущен.
WebMCP — это не SEO-инструмент
Регистрация инструментов сайта меняет то, что агент может сделать, уже попав на вашу страницу. Она никак не влияет на то, попадёт ли он туда. Собственный список ограничений Chrome называет обнаруживаемость инструментов открытой проблемой: клиент или браузер узнаёт, что у сайта есть вызываемые инструменты, только зайдя на него. Нет ни обхода краулером, ни индекса, ни фида зарегистрированных инструментов. С учётом этого механизма вывод прост, хотя это наша интерпретация, а не заявление вендора: WebMCP — это поверхность на пути конверсии, а не рычаг для ранжирования или цитирования, и относиться к описанию инструмента как к тексту meta description значит неправильно понимать, кто его читает.
Выберите одно действие, которое ваши пользователи и так совершают на вашем сайте, зарегистрируйте его сначала как read-only и вложите реальные усилия в описание и схему. Именно здесь агент либо понимает ваше приложение, либо нет, и это та часть, которую за вас не исправит никакая раскатка браузера.
Часто задаваемые вопросы
Как отменить регистрацию инструмента WebMCP, когда пользователь уходит со страницы?
Метода unregisterTool не существует. Передайте AbortSignal в объекте опций document.modelContext.registerTool, а затем вызовите abort у этого контроллера, когда инструмент перестаёт быть применимым — например, при размонтировании компонента или смене маршрута в SPA. Лучшие практики Chrome формулируют это в терминах состояния страницы: регистрируйте инструмент, пока он полезен, и снимайте регистрацию, когда он перестал быть таковым. Привязка abort к переходам между состояниями страницы — практичный способ это сделать, и он не даёт устаревшему инструменту задержаться или столкнуться с новой регистрацией под тем же именем. Агенты отслеживают изменение через событие toolchange на document.modelContext.
В чём разница между декларативным и императивным API WebMCP?
Декларативный API превращает существующую HTML-форму в инструмент: добавьте атрибуты toolname и tooldescription к элементу form, а также toolparamdescription к отдельным полям, и браузер выведет структурированное представление из формы. Удаление любого из этих атрибутов снимает регистрацию инструмента. Императивный API, document.modelContext.registerTool, подходит для динамических инструментов и сложной логики. Встроенный браузер ChatGPT поддерживает только императивный путь.
Есть ли поддержка React или Angular для регистрации инструментов WebMCP?
Есть и то и другое, и обе поддержки экспериментальные. Chrome Labs сопровождает хук useWebMCP в пакете use-webmcp-tool, который регистрирует инструмент при монтировании, снимает регистрацию при размонтировании, требует React 18 или новее и вырождается в no-op там, где API отсутствует. Angular предоставляет provideExperimentalWebMcpTools из своего core-пакета, привязывая время жизни инструмента к инжектору; рекомендуемое место размещения — провайдеры маршрута или приложения.
Проверяет ли браузер аргументы, передаваемые агентом, на соответствие моей inputSchema?
Не рассчитывайте на это. Считайте входные данные, доходящие до execute, непроверенными и валидируйте их в коде, прежде чем что-либо делать. Руководство Chrome по WebMCP предписывает разработчикам проверять ограничения и возвращать описательные ошибки, чтобы агент мог повторить попытку, а Angular прямо говорит, что не сверяет переданные агентом аргументы с объявленной вами JSON-схемой. Серверные проверки авторизации при этом никуда не деваются.