WebMCP и MCP: в чём разница

MCP — это протокол, который позволяет запустить сервер и открыть ИИ-агентам доступ к вашим инструментам откуда угодно. WebMCP — предлагаемый веб-стандарт, с помощью которого веб-страница объявляет, что агент может делать на ней, пока она открыта у пользователя.

Если вы уже писали MCP-сервер, название «WebMCP» наводит на мысль, что это тот же протокол, просто перенесённый в браузер. Это не так. От этого различия зависит, где будет жить код, предназначенный для агентов, от чьего имени он выполняется и можно ли уже на него полагаться.

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

В чём разница между WebMCP и MCP, если коротко?

MCP — это сервер, который вы запускаете, чтобы агент мог вызывать ваши инструменты. WebMCP — это способ для вашей страницы объявить, что агент может делать на странице, где он уже находится. Model Context Protocol — открытый стандарт для подключения ИИ-приложений к внешним данным, инструментам и рабочим процессам, и ему безразлично, запущен ли агент в браузере. В руководстве Chrome о том, когда использовать WebMCP, а когда MCP, WebMCP назван предлагаемым браузерным стандартом, состоящим из двух API. Эти API доступны только агенту, встроенному в браузер, а сам браузер передаёт сообщения между этим агентом и вашим сайтом. Подробнее о браузерах со встроенными агентами читайте в нашем введении в агентные браузеры. Chrome называет WebMCP «вдохновлённым MCP» (MCP-inspired): это браузерный API, построенный по образцу MCP, а не MCP, переписанный на JavaScript.

Что и где выполняется в MCP и WebMCP?

MCP-сервер — это отдельный процесс со своим развёртыванием, своей аутентификацией и своими требованиями к доступности. WebMCP не добавляет нового процесса: он работает внутри открытой вкладки.

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

В случае WebMCP определения инструментов поставляются вместе с фронтендом. Ничего дополнительно разворачивать не нужно, но инструменты привязаны к вкладке. Каждый инструмент WebMCP исчезает вместе с вкладкой, которая его зарегистрировала. Если пользователь уходит со страницы или закрывает вкладку, агент теряет доступ к этому инструменту.

Идентификация: агент действует от имени авторизованного пользователя

Поскольку инструменты WebMCP выполняются внутри страницы, которую пользователь уже открыл, агент, использующий их, работает в рамках существующей сессии пользователя, его cookie и разрешений. Отдельных учётных данных для вашего сайта у него нет. Chrome подчёркивает, что WebMCP может использовать актуальные данные сессии страницы, cookie и DOM — всё то, чего нет за пределами открытой вкладки. Отсюда следует, что сетевые запросы инструмента отправляются с той сессией, которая уже есть у страницы.

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

У идентификации на основе сессии в WebMCP есть своя цена. С точки зрения страницы вызов инструмента WebMCP — это действие, совершённое авторизованным пользователем. Если вы специально не заложите такое различие, ваш код не сможет отличить вызов агента от клика. Отсюда три практики:

• Ограничивайте возможности каждого инструмента тем, что пользователь и так может сделать через UI.
• Требуйте подтверждения для чувствительных действий. В обзоре WebMCP сказано, что инструмент, выполняющий чувствительное действие, например покупку, может показать пользователю диалог подтверждения, прежде чем продолжить.
• Опирайтесь на ограничения платформы. WebMCP работает только в документах с изоляцией по источнику и регулируется директивой Permissions Policy tools. По умолчанию её значение — self, поэтому iframe с другого источника должен получить доступ явно.

<iframe src="https://widget.example.com/" allow="tools"></iframe>

Если у iframe нет этого атрибута, значение по умолчанию self блокирует регистрацию инструментов в таком кросс-доменном фрейме. В документации Chrome также указано, что API WebMCP отключаются в любом документе, где включён document.domain, например с помощью заголовка Origin-Agent-Cluster: ?0.

Сравнение WebMCP и MCP

Главное различие между MCP и WebMCP: с одной стороны — постоянная доступность и охват, с другой — контекст страницы и пользовательская сессия.

Первые пять строк основаны на сравнении WebMCP и MCP от Chrome.

Когда использовать MCP, а когда WebMCP?

Используйте MCP для задач, которые выполняются на сервере без UI, и WebMCP — для задач, которые выполняются на странице, где находится пользователь.

• Бэкенд-сервис, фоновые задачи или доступ к данным без UI: MCP. WebMCP требует открытой страницы, и, согласно обзору Chrome, он рассчитан в первую очередь на человека, работающего в локальном браузере, а не на headless-сценарии. Начните с руководства о том, как создать MCP-сервер.
• Веб-приложение с авторизованным пользователем: WebMCP. Используйте его для действий на текущей странице — например, для заполнения сложной формы или выбора дат в виджете бронирования, — где важны сессия пользователя и состояние страницы.
• И то и другое. Многим продуктам понадобятся обе технологии. MCP отвечает за основную бизнес-логику и данные, а WebMCP — за действия внутри вкладки. Если у вас уже есть HTTP API, естественной серверной частью станет предоставление этого API языковым моделям через MCP. О браузерной части читайте в нашей сопутствующей статье Exposing Your Site’s Actions to AI Agents With WebMCP.

Заменяет ли WebMCP MCP?

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

Насколько зрел WebMCP?

WebMCP — экспериментальная технология. Он доступен в рамках origin trial в Chrome начиная с версии 149, а локально — через флаг chrome://flags/#enable-webmcp-testing, причём Chrome предупреждает, что API ещё обсуждается и может измениться. Origin trial проводятся ограниченное время, могут иметь лимиты на использование и нужны для сбора отзывов, которые повлияют на итоговый API. Спецификация WebMCP — это черновой отчёт W3C Web Machine Learning Community Group. Она не является стандартом W3C и не находится на пути стандартизации W3C (Standards Track). Документация Chrome описывает только реализацию в Chrome, поэтому не рассчитывайте на поддержку в других браузерах или хостах агентов, пока это не подтвердит их собственная документация. Следите за изменениями по версиям на странице WebMCP в Chrome Status. Chrome также отмечает, что WebMCP можно внедрять как прогрессивное улучшение. Так и делайте, чтобы ваш UI работал одинаково независимо от того, видит агент инструменты или нет.

Как сделать выбор

MCP и WebMCP отвечают на разные вопросы. MCP делает ваши возможности доступными любому агенту в любое время. WebMCP делает страницу, на которой находится пользователь, доступной для агента в его браузере — в рамках его собственной сессии. В качестве следующего шага составьте список действий, которые предоставляет ваш продукт, и распределите их: headless-операции отправляются на MCP-сервер, а привязанные к сессии действия на странице становятся кандидатами для WebMCP в рамках origin trial. Делайте слой WebMCP как можно тоньше, поскольку API ещё может измениться.

Часто задаваемые вопросы

Как включить WebMCP для реальных посетителей, а не только в своём браузере?

Зарегистрируйте свой источник (origin) в консоли Chrome Origin Trials и сгенерируйте токен для WebMCP. Отдавайте его на каждой странице, регистрирующей инструменты, — либо в meta-теге origin-trial, либо в HTTP-заголовке ответа Origin-Trial. Токены выдаются для каждого источника отдельно. Без токена посетители в обычном Chrome никогда не увидят ваши инструменты, поскольку локальный флаг для тестирования действует только в том браузере, где вы его включили. Испытание началось в Chrome 149 и изначально должно было продлиться до Chrome 156. Google запросил продление до Chrome 162, поэтому проверяйте дату окончания действия своего токена в консоли Origin Trials.

Как протестировать инструменты WebMCP, не создавая агента?

Используйте Model Context Tool Inspector — расширение для Chrome, упомянутое в документации Chrome по WebMCP. Оно показывает список инструментов, зарегистрированных страницей, и позволяет запускать их вручную. Расширение также подтверждает, что браузер может разобрать вашу JSON Schema, и отображает результат или ошибку, которые возвращает каждый инструмент. На странице при этом всё равно должен быть включён WebMCP — либо через флаг тестирования WebMCP в chrome://flags, либо с помощью токена origin trial.

Можно ли повторно использовать определения инструментов MCP для WebMCP?

Определения входных данных часто можно переиспользовать, а обработчики — нет. И инструменты MCP, и инструменты WebMCP описывают входные данные с помощью JSON Schema, поэтому имя инструмента, его описание и структура аргументов обычно переносятся без изменений. С обработчиком всё иначе. Обработчик MCP выполняется на вашем сервере с той аутентификацией, которую вы реализовали. Обработчик WebMCP — это JavaScript, выполняемый на странице, с доступом к сессии пользователя и актуальному состоянию DOM.

Поддерживает ли Angular WebMCP?

Да, но только в экспериментальном режиме. Экспериментальная поддержка в Angular позволяет регистрировать инструменты WebMCP, жизненный цикл которых следует за механизмом внедрения зависимостей (dependency injection) Angular, а также превращать Signal Forms в инструменты без ручного написания JSON Schema. Документация Angular предупреждает, что спецификация WebMCP часто меняется и эти API могут измениться даже вне мажорных версий. Зафиксируйте версию Angular и будьте готовы обновлять код.