Интересное выступление Tara Agyemang из Google Chrome про WebMCP. Зацепило не само появление нового browser API, а более практичная мысль: нормальное управление браузерным flow для агентов может быть устроено не через “посмотри на экран и угадай, куда кликнуть”, а через явные инструменты, которые сайт сам отдает агенту.
Я реально чувствую, что это может быть интересной возможностью. Сейчас браузерный агент часто делает дорогую работу: читает DOM, смотрит accessibility tree, берет screenshot, угадывает визуальную структуру, вычисляет координаты и кликает. А потом ломается, потому что сверху загрузился баннер и все съехало. Это впечатляет как multimodal reasoning, но инженерно выглядит как обходной путь.
WebMCP предлагает другой способ. Сайт объявляет tools: например
search_concerts, purchase_ticket, filter_results или submit_application. У каждого tool есть имя, описание и schema параметров. Агент не угадывает назначение кнопки по пикселям, а видит меню допустимых действий. В демо Tara показывает это на игре-лабиринте и сайте с билетами: агент не “тыкает” в интерфейс, а последовательно вызывает инструменты страницы, при этом UI остается синхронизированным.Мне кажется, что тут прослеживается аналогия с accessibility фичами для повышения доступности для людей - когда интерфейс сделан только для зрячего человека с мышкой, другому исполнителю приходится восстанавливать смысл из внешних признаков. WebMCP выглядит как accessibility-слой для агентов: сайт объясняет не только как он выглядит, но и какие действия в нем реально существуют.
Важно, что Tara не продает WebMCP как замену обычному MCP. По ее объяснению, MCP обычно про server-side интеграции: агент идет в отдельный backend tool/API. WebMCP - про client-side браузерный контекст. Нужна открытая вкладка или webview, tools живут на странице, а пользователь видит состояние и может возвращать управление себе. Это human-in-the-loop workflow внутри привычного web UI.
Технически есть два пути.
1️⃣ Declarative API подходит для HTML forms: добавляешь атрибуты, браузер собирает schema из полей
2️⃣ Imperative API нужен для сложных flow: через JavaScript регистрируешь tool и внутри execute вызываешь существующую логику приложения.
В документации Chrome это progressive enhancement, а не переписывание сайта под агентов.
Статус стандарта пока ранний, и это важно не перепутать. WebMCP описан как proposed web standard; текущая спецификация опубликована Web Machine Learning Community Group как Draft Community Group Report, то есть это еще не W3C Standard и не документ на W3C Standards Track. Google анонсировал early preview 10 февраля 2026 года, а origin trial доступен с Chrome 149.
Если спрашивать про GA честно, я бы разделял два ответа. Для Chrome implementation Chrome Status сейчас показывает origin trial на M149-M156 и стадию ship с M157 для Desktop, Android и WebView. С учетом перехода Chrome на двухнедельный release cycle с M153 8 сентября 2026 года, M157 ориентировочно попадает на начало ноября 2026 года, если план не сдвинется. Но это не значит, что “веб-стандарт вышел в GA” в широком смысле: спецификация еще обсуждается, API меняется, а межбраузерная история будет зависеть от обратной связи и реализации другими браузерами.
Практический вывод такой: если у продукта есть сложные flow - покупка, заявка, support, booking, диагностики, многошаговые настройки, - стоит уже сейчас думать, какие действия в них являются “инструментами”, а какие просто визуальным оформлением. Хороший semantic HTML, accessibility, быстрые страницы и понятные states остаются базой. WebMCP добавляет следующий слой: безопасную и наблюдаемую ручку управления вместо мучения мультимодальной модели. Мне кажется, именно такие вещи будут отличать зрелую agent-ready платформу от красивой демки. Не “агент научился кликать как человек”, а “система дала агенту правильные интерфейсы и оставила человеку контроль”.
P.S.
Потом попробую поразбираться с этими возможностями в своих публичных проектах типа system-design.space или polomodov.tech:))
#AI #Agents #Web #Software #Architecture #Engineering