WebMCP или обычный API выбирают не как конкурирующие версии одной технологии. Серверный API нужен, когда система должна работать независимо от открытой страницы: синхронизировать каталог, получать заказы, обслуживать приложение. WebMCP рассчитан на действия веб-приложения в контексте текущей страницы и пользовательской сессии. Во многих проектах полезны оба слоя: WebMCP даёт агенту понятный вход, а API или серверная функция выполняет проверенную операцию.
Что умеет обычный API
API публикует контракт на сервере. Клиент передаёт токен, вызывает адрес и получает ответ. Он может работать по расписанию, обрабатывать большие объёмы и не зависит от конкретного интерфейса сайта. Вместе с этим появляются обязательные задачи: аутентификация, лимиты, версии, журналирование и документация.
Если партнёру нужно выгружать десять тысяч товаров или CRM должна принимать заявки, браузерный интерфейс здесь лишний.
Для чего нужен WebMCP
WebMCP объявляет инструменты, принадлежащие веб-документу. Агент видит их, когда работает со страницей. Это удобно, если действие связано с текущим состоянием: пользователь открыл товар, выбрал параметры и просит добавить вариант в свою корзину.
Такой инструмент может использовать авторизованную сессию, но не должен автоматически наследовать все права человека. Он также не обязан открываться внешним системам как публичный API.
Три типовых решения
- Только API. Машинная интеграция выполняется без участия браузера.
- Только WebMCP. Небольшое действие использует логику страницы и не предназначено для внешней синхронизации.
- WebMCP поверх серверного метода. Инструмент страницы принимает параметры, а общая функция проверяет их и выполняет операцию.
Третий вариант часто устойчивее: правила цены, наличия или расчёта существуют в одном месте. Если скопировать формулу в WebMCP-инструмент, она со временем разойдётся с сайтом и API.
Пять вопросов перед выбором
- Должно ли действие работать без открытой страницы?
- Нужен ли массовый обмен данными?
- Есть ли уже надёжный серверный метод?
- Какие права и подтверждения требуются?
- Что произойдёт при повторном вызове или смене версии?
Если ответ «да» на первые два вопроса, почти наверняка нужен API. Если агент помогает человеку внутри страницы, можно рассмотреть WebMCP. Значимые операции всё равно требуют серверной защиты.
Пример с калькулятором
Калькулятор на сайте принимает площадь и материал. Если расчёт нужен только посетителю страницы, WebMCP-инструмент может вызвать общую функцию и вернуть результат с допущениями. Если тот же расчёт используют CRM, мобильное приложение и партнёры, разумно вынести его на сервер и дать всем клиентам единый контракт.
Нельзя позволять браузеру самостоятельно назначать итоговую цену. Результат пересчитывается на сервере перед заказом.
Что выбрать сейчас
WebMCP пока находится в развитии и не имеет универсальной поддержки. Поэтому критичный процесс нельзя делать зависимым только от него. Начинайте с общей бизнес-логики и обычного пути для человека. Новый интерфейс добавляйте как пилот, когда он сокращает конкретный сценарий.
Алиса может помочь разложить действие по слоям и определить, где достаточно формы, где нужен API, а где уместен эксперимент с WebMCP.
Комментарии
Комментариев пока нет. Будьте первым!
Оставить комментарий