Объяснение WebMCP: возможность для веб-сайтов публиковать инструменты вместо того, чтобы агенты нажимали на элементы интерфейса.

Представьте себе небольшой побочный проект, в котором ИИ-агент должен самостоятельно управлять веб-приложением. Первая версия работает так же, как большинство браузерных агентов: агент получает доступ к приложению и определяет дальнейшие действия на основе того, что отображается на странице. Для простого приложения для управления задачами запрос может выглядеть как «Добавить ‘Купить яйца’ в мой список». Чтобы его выполнить, агенту необходимо изучить страницу, найти поле ввода, определить, какая кнопка отправляет форму, нажать на неё, а затем проверить результат.

Этот подход работает, но требует слишком много усилий. Приложение уже точно знает, что должно произойти. За этой кнопкой находится функция, за этой функцией — API, а сама операция представляет собой один простой вызов:

add_todo(title)

Так зачем агенту смотреть на интерфейс и догадываться, как выполнить действие, которое приложение уже может описать? Именно здесь WebMCP начинает иметь смысл. Поток действий выглядит примерно так:

User request
     ↓
AI agent
     ↓
WebMCP tool
     ↓
Application logic
     ↓
UI updates

Интерфейс по-прежнему существует для людей-посетителей. Агенту просто не нужно его декодировать, чтобы выполнить действие. Это меняет подход к решению всей проблемы. Вопрос может заключаться не в том, как сделать ИИ лучше в использовании веб-сайтов, а в том, как сделать веб-сайты лучше в том, чтобы объяснить ИИ, что они могут делать.

Два способа использования веба агентами сегодня и их недостатки

У агента, который должен действовать на сайте, в настоящее время существует два распространённых пути.

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

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

Это создаёт пробел: автоматизация браузера слишком косвенна, а специальные интеграции слишком трудоёмки. WebMCP направлен на решение проблемы, лежащей между ними.

Что такое WebMCP

Проще говоря, WebMCP позволяет веб-сайту сообщить ИИ-агенту: «Вот что можно сделать на этой странице». Вместо того чтобы агент сам пытался определить, на какую кнопку нажать, сайт предоставляет список действий.

Например, интернет-магазин может опубликовать такие инструменты:

search_products()
get_product_details()
add_to_cart()

Агент, просматривающий сайт, сам находит необходимые инструменты и вызывает их с использованием структурированных данных, указанных каждым из них. Нет необходимости заранее регистрировать что-либо внутри агента. Инструменты обнаруживаются динамически на веб-сайте, и именно это заслуживает внимания. Сайт перестаёт быть просто набором страниц и начинает предоставлять функциональность.

Конкретный пример: приложение Todo

Возьмём простое приложение для управления задачами. Без WebMCP агенту пришлось бы изучать страницу, находить поля ввода, вводить текст, определять кнопку «Добавить», нажимать на неё и снова читать обновлённый интерфейс.

С WebMCP приложение может публиковать четыре инструмента:

add_todo(title)
list_todos()
toggle_todo(id)
delete_todo(id)

Агенту больше не нужны знания о визуальном макете. Он знает, что может делать приложение. Демо-версия, построенная именно таким образом, показала приложение для управления задачами, предоставляющее четыре инструмента; подключенный агент считывал их схемы и сразу же вызывал функцию add_todo. Приказ агенту добавить в список фразу «Мне нужно купить яйца» запускал вызов соответствующего инструмента, и новая запись появлялась в приложении.

Ментальная модель становится гораздо проще: интерфейс предназначен для людей, инструменты — для агентов, и оба взаимодействуют с одним и тем же приложением.

Как выглядит определение инструмента

Здесь инженерам фронтенда может быть интересно. В демо-версии инструменты регистрируются через navigator.modelContext. Каждый инструмент состоит из нескольких компонентов:

{
  name: "add_todo",
  description: "Add a todo item",
  inputSchema: {
    // structured inputs
  },
  execute: async (input) => {
    // application logic
  }
}

Структура остаётся неизменной: имя, описание, схема ввода данных и функция-исполнитель, которая выполняет работу, обычно путём вызова API серверной части, уже имеющихся в приложении. Именно этот момент имеет большое значение. WebMCP не требует от вас переписывать бизнес-логику для ИИ. Существующее приложение по-прежнему остаётся системой, выполняющей операцию, а агент лишь получает структурированный способ её запуска.

Проблема аутентификации

Всё становится серьёзнее, когда приложение уже не является простым инструментом для экспериментов. Представьте себе подобные инструменты:

get_profile()
update_profile()
create_order()
cancel_order()
transfer_money()

Неизвестный агент не должен иметь возможности свободно вызывать эти функции. Вторая демонстрация в том же материале решает именно эту проблему с использованием OAuth. Инструменты WebMCP работают в рамках аутентифицированного приложения, поэтому пользователи, которые не вошли в систему, не могут выполнять защищённые действия.

Это важно, поскольку агенты могут поступать с самых разных клиентов: браузера с поддержкой ИИ, десктопного агента или другого приложения-агента. Стандартный механизм вроде OAuth значительно упрощает защиту функционального слоя во всех этих случаях, по сравнению с необходимостью создания отдельного процесса входа для каждой интеграции. Как только сайты открывают доступ к своим функциям агентам, аутентификация становится частью их работы с самого начала, а не дополнением, добавленным позже.

Новый вопрос для дизайна фронтенда

На протяжении многих лет архитектура фронтенда строилась вокруг одной цепочки: интерфейс, состояние, API, бэкенд. WebMCP вводит ещё один вопрос: какие возможности должно предоставлять это приложение агенту?

Это кажется незначительным, но это может изменить способ проектирования функций. Кнопка «Добавить в корзину» представляет собой взаимодействие с человеком. Этот вызов же является возможностью приложения:

add_to_cart(productId, quantity)

В конечном итоге их можно будет разработать вместе. У пользователей появится упрощённый интерфейс, у агентов — структурированный интерфейс для выполнения задач, причём оба будут использовать одну и ту же бизнес-логику.

Речь идёт не только о скорости

Здесь есть более глубокая причина, почему это важно, чем просто более быстрые агенты. Когда агент работает с скриншотами и кликами, сам интерфейс является контрактом, и любые изменения в интерфейсе могут нарушить его работу. С WebMCP определение инструмента становится частью этого контракта.

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

Ещё ранний этап

Следует обратить внимание на один важный момент. WebMCP пока остается предложением в стадии раннего тестирования и не является утвержденным веб-стандартом. Демонстрация проходила в версии Chrome Beta с включенным WebMCP через флаги браузера, и демонстратор прямо заявил, что API может еще измениться. Создавать производственную архитектуру на его основе сейчас было бы преждевременно. Экспериментировать с ним — другое дело, поскольку идея, лежащая в его основе, шире современного API.

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