Привет! Меня зовут Вася Пикулев, я руковожу кор-командой веб- и Smart TV-клиентов в Окко. Стандарт WebMCP может изменить мою работу в ближайшие годы. И я хочу попробовать вместе с вами разобраться, что он нам несёт и какие открывает перспективы.

Представьте: один и тот же сайт. Один и тот же запрос пользователя к ИИ-агенту — подписаться на рассылку. Два способа выполнить.

Способ первый, сегодняшний. Агент открывает страницу. Делает скриншот (1500 – 5000 input-токенов в visual-модель). Решает, где поле email. Решает, какая кнопка нужна. Кликает. Редирект, ещё один скриншот, ещё токены, ещё шаг рассуждения. От намерения пользователя до галочки в подтверждении — обычно минута-другая, в худшем случае до пяти минут. Стоимость — несколько центов в API.

Способ второй, новый. Сайт заранее объявил действие subscribe. Агент спрашивает у браузера, что эта страница умеет. Получает машиночитаемый список. Вызывает функцию с email. На всё уходит 1 – 3 секунды — это бэкенд (миллисекунды) плюс inference агента. И inference тоже стоит денег: модель должна понять запрос, выбрать tool, сформировать аргументы, обработать ответ. Спецификация допускает и скриншоты, но они перестают быть главным способом понять страницу. Итерации сокращаются с 5 – 20 до 1 – 2. Получается 1 – 2 тысячи токенов на задачу против десятков-сотен тысяч в первом варианте.

Числа примерные. Точные значения зависят от модели, страницы и сценария. Но сложно не заметить, что мы имеем около двух порядков разницы по обеим осям: latency и стоимости. Это уже не оптимизация. Это качественный скачок.

И всё это умещается в одну новую браузерную функцию — navigator.modelContext.registerTool().

Давайте взглянем, что скрывается за этой простой фичей.

Код WebMCP

navigator.modelContext.registerTool({
  name: "subscribe",
  description: "Подписать пользователя на рассылку",
  inputSchema: {
    type: "object",
    properties: { email: { type: "string", format: "email" } },
    required: ["email"]
  },
  async execute({ email }) {
    const r = await fetch("/api/subscribe", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ email })
    });
    return { ok: r.ok };
  }
});

[щас будет скучно]

Ваш JS вызывает API браузера, регистрирует tool: имя, описание (по нему агент поймёт, зачем этот tool), JSON Schema на вход, тело обработчика. Браузер хранит эту регистрацию в реестре текущей вкладки.

Потом агент спросит у браузера, что страница умеет, и вызовет tool по имени, передав параметры в формате схемы.

Браузер не лезет на ваш сервер — он зовёт вашу же JS-функцию на вашей же странице. Что она делает, решаете вы.

Спецификация — Draft Community Group Report от W3C Web Machine Learning CG. Не стандарт. Реализация одна — Chrome, под флагом, с февраля 2026.

В API уже есть базовые аннотации, обеспечивающие безопасность: readOnlyHint — вы заявляете, что tool только читает данные, не меняет состояние; untrustedContentHint — защита от prompt injection; requestUserInteraction() — «остановись, спроси человека». Декларативная часть API через HTML — пока TODO. Идея — декларировать tools прямо в разметке, а не императивно через JS.

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

Это всё.

[вот, опять интересно]

Но я приглашаю вас задаться вопросом, куда это может нас привести и, скорее всего, приведёт.

Как агенты оперируют сайтами

Чтение сайтов машинами — отдельная тема со своими стандартами (Schema.org / Rich Results, Open Graph, RSS, скрейперы). Здесь говорим про действия. Сегодня машина может сделать что-то на клиенте тремя способами:

Через человеческий UI. Сайт сделан для глаз и пальцев. Крупные кнопки, поля с placeholder, путь к подписке через хедер. Если машине надо туда попасть, она надевает костюм человека: смотрит на экран, скроллит, угадывает, кликает.

Через реверс-инжиниринг. Двери для тех, кто пришёл подготовленным: разобрать API на бэке, WASM-модули, клиентские функции, схемы данных, аутентификацию. Машина здесь дверь не открывает — её приводят за руку и объясняют, что делать. Нестабильно, маргинально, путь хакера.

Через WebMCP. Сайт сам говорит вошедшему агенту: «вот что я умею прямо сейчас, на этой странице, для этого пользователя — бери». Без документации, без отдельных ключей для агента, без посредника-человека. Авторизация та же, что у пользователя в браузере: какие действия открыты ему, открыты и агенту. Какие «ручки» показать — решает сайт.

Все три способа могут жить одновременно. Но экономика толкнёт в сторону третьего.

Почему контракт победит скриншот

Я не аналитик и предсказывать не люблю. Но если просто прикинуть на пальцах, то выходит вот что.

Когда один способ делать что-то стоит примерно в сто раз дешевле другого, рано или поздно дешёвый выигрывает. Просто вряд ли кто-то будет долго платить в сто раз больше за тот же результат. У тех, кто гоняет миллион действий агентов в день, эта разница превращается в бюджеты, которые сложно игнорировать.

И «миллион в день» не преувеличение. Браузерные агенты — реальность 2026-го. ChatGPT Agent от OpenAI, Computer Use и Claude in Chrome от Anthropic, Comet от Perplexity — шипнутые продукты, а не прототипы. Сегодня они ходят на сайты через screenshot/click. Бюджеты на этот режим уже растут.

Открытый вопрос не в том «будет ли» этот сдвиг в сторону машиночитаемого UI, а какая форма победит. WebMCP — одна из форм. С ней конкурируют MCP-серверы (Anthropic), agentic-браузеры у Perplexity и Arc, расширения для браузеров. Какая из них начнёт выигрывать, мы узнаем в ближайшие 2-3 года.

Как меняется разработка

Появляется новая поверхность — та, через которую веб-клиент общается с агентами. Раньше такого не было. Это даёт два эффекта.

Первый. Веб-клиент перестаёт быть конечной точкой. Между ним и пользователем теперь агент — клиент превращается в роутер между вашим бэком и другим (скорее всего не вашим) клиентом. Фронтенд смещается из наших контролируемых рантаймов в чужую среду.

Второй. Ваш веб-клиент сам станет ИИ-driven в принятии решений — не у всех, но в части доменов. Входные данные и так не вполне детерминированы (были клики, теперь tool-call’ы). А вот сама логика исполнения внутри браузера тоже может стать недетерминированной — там поселится локальная модель, принимающая часть решений. Это и есть ИИ-driven клиент со своим чёрным ящиком внутри. Для многих веб-приложений и сайтов этого может не произойти, и клиент останется тонкой витриной для агента. А в более крупных продуктах со сложными сценариями взаимодействия с пользователем и большим количеством данных — почти наверняка.

Эти два эффекта станут причиной новых задач на клиенте, нового UX и даже нового веба.

Новые задачи

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

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

Новый UX

Параллельно привычная часть фронтенда никуда сразу не денется — просто рядом будет расти новая.

Банальный confirm какого-то действия теперь живёт не только на сайте, но и в интерфейсе агента, где пользователь сейчас в диалоге. Вы передаёте контент, агент рендерит. Окружение вы не контролируете, но содержимое — да. И это критично. В мире, где лишь миллисекунды между намерением и действием, простое «Подтвердить» уже не гигиеническая формальность. Это последняя точка, где можно предотвратить дорогую ошибку.

Новый веб

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

Если честно, мне кажется, что GUI с кнопками и формами надо оставить профессионалам. Надо ли всем уметь разбираться в стандартных интерфейсах, когда можно просто сказать, что ты хочешь и от кого ты это хочешь?!

Вывод

Два порядка. Во столько раз дешевле обходится действие агента, когда сайт сам объявил свои действия, вместо гадания агента по скриншоту.

WebMCP вполне может оказаться правильной формой для реализации этого рыночного потенциала. А может быть заменён другим стандартом. Может застрять только в Chrome, а индустрия пойдёт обходным путём (через backend MCP, расширения, agent-first браузеры). Может быть по-всякому. Но! Сам сдвиг от агентов, кликающих вслепую, к агентам с контрактом произойдёт. Не потому что Google этого хочет, не потому что появилась новая спецификация, не потому что красивая идея, а потому что 100x нельзя игнорировать.

Возможно, с этим черновиком стандарта рождается новый веб — прямо у нас на глазах. Мне лично этот черновик напомнил тот самый веб HTML 4.01, вроде бы уже повидавший, но ещё совсем молодой. Такая, новая молодость. Новая опытная молодость! По-моему, это прекрасно ❤️