Многие люди уверены: раз агент «ходит» по сайту, он уже почти как покупатель. Им кажется — тыкает кнопки, заполняет поля, всё само.
Точнее, обычно это либо медленный тык по интерфейсу для людей, с ошибками. Либо сайт приходится переписывать под агентов: свои действия, свой код, свой выпуск на сервер.
Шестого августа Cloudflare показала третий путь. Для сайтов за их сетью — тумблер в панели. Сам подсовывает WebMCP в разметку ответа. Код вашего сервера не трогают.
Это ранний доступ для разработчиков, не «все сайты уже готовы к агентам». Но смысл сдвига простой: агенту можно отдать именованные действия вместо угадывания кнопок на странице.
Что именно вставила Cloudflare
На краю сети, пока страница ещё летит к браузеру, в ответ попадает мост: скрипт с адреса того же сайта. Ваш сервер не меняют. Вставка идёт на стороне Cloudflare.
Мост ищет на странице поверхность WebMCP — место, где сайт выставил действия для агента. Нет поверхности — тишина: страница для людей как раньше. Есть готовые наборы или своя регистрация действий — агент в подходящем браузере может звать структурированные команды, а не кликать наугад.
Адрес моста на том же сайте — /.webmcp/bridge.js. Включение короткое: панель → Agent Readiness → Labs. Оба готовых набора в раннем доступе по умолчанию включены. Новые наборы можно подключать без повторного выпуска сайта.
Проверка совсем бытовая: в разметке ответа есть строка «webmcp». В анонсе — через curl и grep. Тест без своего агента — Browser Run у Cloudflare уже умеет находить и вызывать эти действия.
Это не «лёгкий браузер для агентов» и не кошелёк с лимитом трат. Здесь герой — действия на стороне сайта: край сети раздаёт мост и наборы, агент зовёт команды, а не тычет по картинке интерфейса.
WebMCP простыми словами
Любопытно, как быстро слово WebMCP начали таскать как заклинание. А смысл простой.
WebMCP — браузерный программный доступ, ещё черновик стандарта. Сайт регистрирует действия: имя, описание, что на входе, что выполнить. Агент в браузере вызывает эти действия вместо «угадывания» кликов по человеческому экрану.
В Chrome это пока эксперимент (Chrome 146). В документации Chrome поверхность называется «document.modelContext». Программный доступ ещё обсуждают, поведение может меняться.
Все просто: без браузера с поддержкой WebMCP тумблер на краю сети сам по себе агента не «оживит».
Два набора из коробки — что реально даёт ранний доступ
Оба набора работают в браузере посетителя. Вызов действия в раннем доступе не гоняет каждый раз туда-обратно на сервер Cloudflare.
- Content Credentials (C2PA) — метки происхождения картинки. Действия вроде сводки по изображениям и разбора манифеста: история правок, автор, сертификат. Читает первые килобайты метаданных локально. Криптопроверки подписи нет: в результатах «signatureVerified: false». Это расшифровка следа, не «доказали подлинность».
- Site MCP Server — динамический набор. Смотрит MCP того же сайта (по умолчанию адрес «/mcp», можно задать «data-mcp-url»), просит список действий и регистрирует прокси. Вызовы идут с куками сессии посетителя — права как у человека в этом браузере.
Атрибуты вроде «data-packs» (например «c2pa,mcp-server-client») говорят, какие наборы подтянуть. Будущие наборы могут ходить в Worker на краю сети — в этом раннем доступе такого ещё нет.
Тумблер — не весь магазин «по кнопке»
Каждый раз, когда слышите «включили WebMCP — сайт готов к агентам», знайте: это маркетинг одной фразой.
Независимый разбор той же недели говорит прямо: включить переключатель ≠ стать готовым к агентам по продукту. Тумблер даёт транспорт и доставку моста. Поиск, корзина, бронь становятся действиями только если уже есть MCP-сервер на сайте или своя регистрация на «document.modelContext».
Из коробки в раннем доступе в основном чтение C2PA и прокси к уже существующему «/mcp». Обещать «агент сам оформит заказ одним тумблером» нельзя.
Логи «кто что вызвал» в анонсе Cloudflare не описаны. Это зона доверия, которую владелец сайта ещё должен закрыть сам.
Безопасность: ставки выше «просто скрипта»
Прокси того же сайта тащит сессию посетителя. Значит унаследованная авторизация, подсказки-ловушки в описаниях действий, вопрос кто решает разрешения — владелец сайта или интерфейс браузера и агента. Это уже не косметика.
В документации Browser Run для чувствительных действий показывают подтверждение человеком: например бронь ждёт «Confirm». Для тестов — лабораторные сессии на Chrome 146 beta.
Не путать лабораторные имена в docs Browser Run с каноном Chrome: для WebMCP в документации Chrome — «document.modelContext».
Что сделать владельцу сайта на Cloudflare
Нужно не «весь стек завтра», а пять спокойных шагов.
- Включить WebMCP в Agent Readiness → Labs (ранний доступ).
- Проверить, что в разметке есть мост / строка «webmcp».
- Решить, какие действия агенту реально нужны: свой MCP на «/mcp» (или другой адрес) либо ручная регистрация действий.
- Прогнать поиск и вызов через Browser Run, прежде чем ждать «агентов из дикой природы».
- Не считать набор C2PA проверкой подписи; не ждать общего запуска и поддержки во всех браузерах.
Куда смотреть дальше
Разбор края и практики агентов, Make и Cursor — в канале Ковчег и в MAX. Если нужен каркас под автоматизацию с нейросетями без зоопарка инструментов — обучение Cursor + Make + AI.
Первичный анонс: Cloudflare Blog — Give any website a WebMCP interface. Независимый угол: RuntimeWire, DEV Community. Chrome: Imperative API WebMCP. Docs теста: Browser Run / WebMCP.
