WebMCP, MCP на уровне сервиса или простое использование браузера: к какой категории относятся инструменты агентов.
Критический анализ WebMCP: инструменты страницы против MCP на уровне сервиса и обычных агентов браузера, с упором на сессии, OAuth CIMD, обнаружение, локальное состояние и права собственности.
Источники: WebMCP: My Architectural Uneasiness and Where I Think It May Fit
На первый взгляд WebMCP кажется разумным решением. Пользователь уже вошел в систему, агент работает внутри браузера, и сайт может указать, какие действия доступны, так что агенту не нужно догадываться о полях и кнопках. Однако проблема заключается в том, где должен находиться этот интерфейс. Если прилагаются усилия для того, чтобы приложение было удобным для использования агентами, должны ли функции предоставляться непосредственно страницей или сервисами, находящимися под ней? И что добавляет интерфейс инструментов на уровне страницы к общим инструментам браузера?
Эти два вопроса лежат в основе нижеследующей оценки.
Что такое WebMCP
С помощью WebMCP сайт регистрирует структурированные инструменты, которые совместимый агент может вызывать через браузер. Каждый инструмент указывает, что он делает, какие входные данные принимает и какой код его запускает. Регистрация происходит с помощью JavaScript или через аннотированные HTML-формы. Chrome описывает эту концепцию как предлагаемый стандарт, пробный этап внедрения которого начинается с версии Chrome 149, причем API может измениться.
Представьте страницу поиска рейсов. Без WebMCP агент читает страницу, находит поле с пунктом назначения, устанавливает даты и нажимает «Поиск». С его помощью сайт может опубликовать инструмент search_flights, принимающий пункт назначения и даты. Агент лишь вводит аргументы, а приложение выполняет поиск.
Следует сохранять различие между тремя подходами: MCP на уровне сервисов, WebMCP и использование в обычных браузерах. Ничто не обязывает выбирать один из них, и один агент может вызывать инструмент сервиса для одного продукта, инструмент страницы для другого и напрямую управлять браузером для третьего.
Архитектурные проблемы
Первая реакция заключается в том, что WebMCP переносит проблемы сервисов в слой представления. Поиск запасов, изменение бронирования или оформление заказа в типичном бизнес-приложении происходит через бэкенд-сервис, а браузер уже вызывает соответствующий конечный пункт для выполнения этих действий. Так зачем же определять контракт, предназначенный для агента, внутри страницы, а не рядом с этим сервисом?
Естественная альтернатива начинается с существующего контракта обслуживания, такого как спецификация OpenAPI или определение gRPC, и на его основе создаётся интерфейс MCP. Преимущество заключается в возможности контроля. Команда, ответственная за бизнес-операции, может управлять версиями, тестировать и регулировать контракт, предназначенный для агентов, причём интерактивные агенты, пакетные задачи и запланированные рабочие процессы могут все использовать его.
Защита внутреннего конца точки входа с помощью инструмента страницы также не делает контракт менее обязывающим. Агенты получают операцию с определёнными ожидаемыми входными данными и поведением, и рабочие процессы нарушаются, если это поведение меняется. Везде, где предоставляется этот инструмент, команда должна определять, какую совместимость и поддержку он обещает, и размещение интерфейса на веб-уровне само по себе не снижает этих обязанностей.
Более внимательный анализ ослабляет некоторые из первоначальных предположений.
- Браузер хранит состояние в реальном времени. В редакторе может находиться несохраненный черновик, активный фрагмент текста или локальные операции, не имеющие аналогов на сервере; называть клиентскую часть пустой оболочкой означает игнорировать всё это.
- Логику не обязательно дублировать. Инструмент может вызывать ту же клиентскую функцию, что и кнопка, и через неё — тот же серверный конечный пункт. Настоящая проблема заключается в дополнительном контракте с инструментом с собственным жизненным циклом, а также в том, что со временем вокруг него могут накапливаться бизнес-правила.
Важна также степень зрелости решения. Некоторые эксперименты неизбежны, но интерфейс, построенный на меняющемся API браузера, добавляет ещё один источник работ по техническому обслуживанию.
Следовательно, более точная позиция заключается в том, что долгосрочная бизнес-операция лучше всего находиться в ведении и управлении непосредственно там, где реализуется соответствующий сервис, и для размещения его контракта на странице требуется конкретная причина.
Повторное использование сессий против делегированного доступа
Преимущество аутентификации заключается в работе в залогиненном браузере, и оно характерно как для WebMCP, так и для обычного использования браузера. Здесь происходит сравнение этого удобства с делегированным доступом к сервису. То, что добавляют специальные инструменты WebMCP по сравнению с обычным взаимодействием с браузером, — это отдельный вопрос, который рассматривается далее.
Когда агент нажимает на элемент управления на защищенном сайте, приложение отправляет свой запрос в рамках существующей сессии, и инструмент WebMCP, запущенный напрямую, может использовать ту же сессию. Ни одной из сторон не требуется отдельное разрешение, передаваемое между хостом агента и сервисом.
Эта преимущественность проявляется в различных приложениях. Рабочий процесс, включающий пять сервисов, может потребовать пяти разрешений, пяти циклов жизни токенов и пяти наборов требований к интеграции, плюс процедуру регистрации клиента, зависящую от каждого сервиса. Если пользователь уже вошел во все пять сайтов, повторное использование этих сессий позволяет избежать большей части этих настроек.
Называть это бесплатной аутентификацией было бы преувеличением. У активной сессии есть свой собственный цикл жизни безопасности, и наличие учетной записи не означает согласия на всё, что может попытаться сделать агент. Тем не менее экономия на работе по интеграции действительно существует. Проблемы с вставкой команд и нежелательными действиями нельзя решить простым выбором уровня безопасности, поскольку обе траектории требуют мер защиты, таких как подтверждение при выполнении значимых операций, с различной степенью уязвимости и контроля; поэтому каждый дизайн должен самостоятельно оценивать эти риски.
Как CIMD сокращает разрыв
Уровень доступа на уровне сервиса также улучшается. Документы метаданных клиента (CIMD) решают одну из проблем, связанных с OAuth: как совершенно новый клиент идентифицирует себя у сервера авторизации, который ранее с ним не встречался. Клиент использует URL по протоколу HTTPS в качестве своего идентификатора, и этот URL предоставляет документ метаданных, в котором перечислены такие элементы, как разрешенные URI перенаправления. Вспомогательный сервер загружает и проверяет этот документ, что исключает необходимость заранее регистрировать каждую пару клиент-сервер. Спецификация авторизации MCP от ноября 2025 года рекомендует поддержку CIMD и предпочитает её динамической регистрации клиентов в тех случаях, когда нет заранее зарегистрированных данных о клиенте.
В случае использования пяти сервисов поддержка CIMD на всех пяти серверах авторизации устраняет необходимость предварительной регистрации. Требования к авторизации и сроки действия токенов для каждого сервиса остаются прежними, хотя существующие разрешения или сессии могут уменьшить количество запросов, поэтому не обязательно потребуется пять новых входов. Сами решения по авторизации не меняются под влиянием CIMD.
Контекст, жизненный цикл и обнаружение
Несохраненный документ демонстрирует важность локального состояния браузера. Инструмент, предназначенный для редактирования выбранного абзаца незавершенного черновика, работает с состоянием, которое сервис ранее не видел, что является более конкретной причиной для предоставления инструмента на странице, чем передача операции на сервере.
Проблема заключается в том, что локальное состояние привязывает инструменты к странице. После того как пользователь уходит или закрывает страницу, агенту может потребоваться сначала снова открыть приложение и воссоздать контекст. Сессия входа может сохраняться даже после закрытия страницы, а исчезает несохраненное состояние или инструменты, находившиеся там.
Определение возможностей сайта — это отдельная задача: как агенту узнать, что предлагает сайт? В документации Chrome указано, что сайт необходимо посетить, прежде чем станут известны его инструменты WebMCP. Известный конечный пункт MCP можно запросить напрямую без участия человека, но нахождение такого пункта по простому веб-адресу представляет собой отдельную сложность; к тому же метаданные OAuth позволяют найти сервер авторизации только для уже известного защищенного ресурса, без универсального списка возможностей MCP.
SEP-2127, озаглавленный MCP Server Cards, предлагает стандартный способ публикации структурированных метаданных сервера по протоколу HTTP, чтобы клиенты могли обнаруживать интерфейсы сервисов до установления соединения MCP и без необходимости работы с веб-страницами для пользователей. Это многообещающее направление. На момент написания этого текста петиция по внесению изменений всё ещё открыта, поэтому это лишь предложение по устранению недостатков, а не принятое решение, которое можно было бы применять везде.
Ни у одной из сторон пока нет явного преимущества в процессе обнаружения, поскольку инструменты для работы с веб-страницами требуют посещения сайта, тогда как обнаружение сервисов с произвольного адреса пока не имеет универсальных правил. Ни один из подходов также не гарантирует эффективного управления, поскольку инструменты WebMCP могут быть хорошо протестированы и обслуживаться, в то время как инструменты для сервисов могут быть плохо спроектированы. Настоящий вопрос заключается в ответственности за развитие и в том, какие рабочие процессы должен поддерживать интерфейс.
Агенты браузеров уже работают без этого
Стоит проверить, что может определить агент браузера без WebMCP. В рамках одной сессии на рабочем столе кодинг-агента предпочтение отдавалось действиям с элементами, основанным на принципах доступности, где это возможно; для визуального контекста использовались скриншоты в качестве альтернативы, а информация об уровне доступности, возвращаемая для страницы документации, оказалась полезной. Это наблюдение касается конкретной сессии, а не утверждение, применимое ко всем версиям или по умолчанию.
Благодаря интеграции агент получал структурированный описание отрендеренного интерфейса, включающее текстовые поля, кнопки, метки, значения и состояния, а также инструменты, ориентированные на DOM, для выполнения соответствующих задач. Большая часть содержимого страницы поступала в виде структурированного текста, в отличие от того, что можно было бы ожидать при акценте на скриншотах. Для простой формы поиска агент может получить что-то вроде этого.
1 textbox “Destination”, value: “Tokyo”
2 button “Search flights”, enabled
На основе этого агент может определить поле назначения, нажать кнопку «Поиск рейсов» и проверить обновленное состояние. Семантика HTML и метки доступности уже содержат большую часть информации об интерфейсе. То, какой вид страницы получает модель, зависит от способа интеграции, а не от её названия; документация OpenAI по использованию компьютеров показывает примеры интеграций, при которых скриншоты передаются модели, а действия возвращаются с помощью инструментов, предоставленных приложением.
В итоге агенты могут работать с сайтом без WebMCP, что сокращает объем работы, необходимой разработчикам сайтов. Однако это не определяет, стоит ли использовать WebMCP. Дерево доступности перечисляет элементы управления, тогда как хорошо спроектированный инструмент может описать всю операцию вместе с её входными данными, сокращая количество взаимодействий и неопределенностей. Если браузерный агент использует десять элементов управления, приложение может предложить для этой задачи один инструмент. Chrome рассматривает WebMCP как средство постепенного улучшения функционала и включает инспектор для тестирования инструментов.
Для этой оценки не проводилось контролируемое сравнение с использованием и без использования инструментов WebMCP, поэтому это архитектурное суждение, а не результат тестирования производительности. Справедливый вердикт должен учитывать скорость выполнения задач, количество взаимодействий и время, затраченное на выполнение различных рабочих процессов. Успешная демонстрация — хорошая отправная точка, но она не отвечает на более общий вопрос.
То, что можно развернуть, также зависит от того, какие интерфейсы контролирует команда. WebMCP требует сотрудничества сайта, а интеграция сервисов нуждается в доступном и авторизованном интерфейсе сервиса. Если сторонняя приложение не предоставляет ни того, ни другого, единственным работоспособным решением может быть обычное использование браузера.
Каковы итоги
Основные выводы из всего этого следующие:
- Инструменты на уровне сервисов подходят для стабильной бизнес-деятельности, особенно для автономных или долгосрочно работающих процессов.
- WebMCP эффективен, когда важен локальный состояние приложения или когда повторное использование аутентифицированного клиентского рабочего процесса существенно сокращает объем работ по интеграции.
- Обычное использование браузера применимо в случаях, когда отсутствуют специализированные инструменты, особенно в отношении приложений, находящихся вне контроля команды.
Остается беспокойство по поводу того, что WebMCP станет стандартным инструментом для функций, у которых уже существуют четкие границы обслуживания. Удобство работы в сессии является веским аргументом в пользу такого подхода, но оно не должно определять архитектуру в долгосрочной перспективе.
Доказательства, способные изменить это мнение, покажут, что для конкретного приложения инструменты, определенные на уровне страницы, значительно превосходят обычное использование браузера за счет более низких общих затрат по сравнению с созданием и поддержкой интерфейса сервиса, включающих авторизацию, техническое обслуживание, управление и рабочие процессы, которые интерфейс не может обеспечить.
WebMCP проявляет наибольшую эффективность там, где совпадают три фактора: активная аутентифицированная сессия, ценное локальное состояние и рабочие процессы клиента, пригодные для повторного использования. Обычное использование браузера также позволяет повторно использовать сессии, поэтому остается открытым вопрос о том, какие конкретные инструменты способствуют этому. Инструмент страницы, который лишь перенаправляет операцию на сервис, всё равно нуждается в обосновании для сохранения интерфейса, ориентированного на агента, на странице.