Представьте, что вы просите ИИ-агента найти поездку в Казань на выходные в пределах 20 тысяч рублей с хорошим отелем. В обычном сценарии агент либо полагается на свои обучающие данные, либо пытается парсить веб-страницы, что чревато неточностями. Чтобы гарантировать поиск по реальным ценам и наличию, требуется прямой доступ к базам данных сервиса. Именно такую задачу решили разработчики из Туту вместе с Александром Поляковым, выпустив MCP-сервер, реализующий протокол Model Context Protocol. Этот открытый протокол позволяет агенту узнавать о доступных инструментах сервиса и вызывать их напрямую, минуя разбор HTML. По оценке McKinsey, к 2030 году ИИ-агенты могут участвовать в продажах товаров на сумму от 3 до 5 трлн долларов по всему миру, что делает подобные интеграции стратегически важными.

Первая версия сервера столкнулась с неожиданной проблемой: обычные пользователи, переходя по ссылке на MCP-сервер в браузере, видели белую страницу с ошибкой «Method Not Allowed». Поскольку человек первым делом нажимает на ссылку, такое поведение создаёт впечатление, что всё сломано, и отталкивает потенциальных пользователей. Решение оказалось простым: сервер научился различать агента и браузер по методу запроса и заголовку Accept. Для браузера теперь отображается лендинг с инструкцией по подключению и описанием сценариев, а агенты получают технический ответ. Нюанс заключается в том, что некоторые агенты приходят с неопределённым заголовком Accept, поэтому по умолчанию безопаснее отвечать как агенту, а лендинг показывать только при точном распознавании браузера. Это позволило объединить удобство для людей и корректную работу для агентов.

Следующий важный аспект — самодокументирование инструментов. MCP позволяет передавать агенту общие инструкции, но длинный гайд быстро расходует контекстное окно. Поэтому каждый инструмент в сервере снабжён собственным описанием, которое сообщает, что он умеет, какие параметры принимает и как с ним обращаться. Например, в описании функции поиска отелей указывается, что инструмент только читает данные (readOnlyHint), повторный вызов безопасен (idempotentHint) и он обращается во внешний сервис (openWorldHint). Это избавляет от дублирования инструкций в общем гайде, которое могло бы привести к расхождению источников и непредсказуемости поведения агента. Подробные руководства для сложных доменов вынесены в отдельные методы, которые агент вызывает по необходимости, что дополнительно экономит контекст.

Особого внимания потребовала оптимизация расхода контекстного окна — главный вызов при работе с MCP. Первая версия сервера успешно тестировалась на GPT-5.4, но при запуске на модели Qwen3-30B-A3B с окном около 130 тысяч токенов начались проблемы: некоторые инструменты возвращали слишком объёмные ответы, например схемы вагонов занимали до 140 КБ, что быстро переполняло контекст и запускало компактизацию — автоматическое сокращение истории диалога. В результате агент терял важные детали об инструментах. Разработчики применили постраничную выдачу: подробно показывать первые вагоны, а остальные заменить краткими блоками с пометкой «продолжение по запросу». Аналогично в карточках отелей из 20–35 ссылок на фото оставили только обложку и общее количество снимков. Благодаря этим мерам на типовых сценариях объём занятого контекста сократился на 74%, и даже локальная Qwen3-30B-A3B стала проходить все тесты при небольшом окне.

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

Контекст развития MCP-протокола показывает, что такие серверы становятся мостом между традиционными веб-сервисами и новой волной ИИ-интерфейсов. В отличие от прямой интеграции через API, MCP не требует от сервиса предоставлять отдельные конечные точки для каждого агента — протокол унифицирует взаимодействие, что снижает порог входа для разработчиков. Конкуренты в этой области, например протокол A2A от Google, пока менее распространены, а MCP уже поддерживается многими популярными платформами, включая Claude и GPT. Для российского рынка, где активно развиваются отечественные ИИ-модели, такие как YandexGPT и GigaChat, наличие открытого протокола с готовыми реализациями может ускорить внедрение агентной коммерции в электронной торговле, бронировании и логистике.

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