Webflow разобрал собственные ошибки при запуске MCP-сервера и показал неприятную для многих команд вещь: старые API плохо подходят для AI-агентов, даже если аккуратно обернуть их в новые инструменты. Для русскоязычных продуктовых и платформенных команд это прямой сигнал: если вы хотите подключить агента к сервису, косметического слоя поверх API, скорее всего, не хватит.
Компания пишет, что главный сбой был не в самом Model Context Protocol, а в устройстве исходных интерфейсов. API, которые нормально работают для разработчика с документацией и пониманием предметной области, для модели часто оказываются слишком дробными, шумными и хрупкими.
Webflow пришёл к этому ещё в 2025 году
По данным блога Webflow, компания начала строить поддержку MCP в начале 2025 года, когда общих правил для agent-ready API ещё не было. Публично MCP-сервер Webflow представила в апреле 2025 года, а в мае подключилась к Demo Day от Cloudflare вместе с первой волной удалённых MCP-серверов.
На старте идея выглядела разумно: взять существующие API и отдать их агенту в виде MCP-инструментов. На бумаге схема аккуратная. На практике модель должна была слишком много помнить между вызовами: какой объект она уже нашла, какой идентификатор нужен дальше, какой шаг можно повторить после ошибки, а какой уже опасно запускать второй раз.
Проблема оказалась в длине цепочки действий
Webflow приводит простой пример: даже правка блока на главной странице может распасться на длинную цепочку. Сначала нужно найти страницу, затем получить её структуру, потом определить нужный элемент, после этого изменить данные и только в конце опубликовать результат.
Для человека это рутинная, но посильная работа. Для модели это уже полоса препятствий: каждый лишний вызов увеличивает задержку, расход токенов и риск потерять состояние по дороге. Иными словами, разработческий API заставляет агента тратить ресурсы не на задачу пользователя, а на навигацию по самому продукту.
Здесь и проходит важная граница. MCP сам по себе проблему не решает: он стандартизует обмен, но не чинит неудачную архитектуру инструмента.
Вместо методов API понадобились действия уровня намерения
Из этого Webflow сделала жёсткий вывод: инструменты для AI-агентов нужно проектировать вокруг намерения пользователя, а не вокруг отдельных методов API. Не «получи страницу» и «обнови узел», а более крупные действия, которые ближе к реальной задаче.
Но и тут есть ловушка. Если под каждый сценарий делать отдельный инструмент, их число быстро уходит в сотни. Тогда агенту трудно выбирать между похожими функциями, а команде трудно поддерживать систему без дублей и конфликтов.
Ответ Webflow состоит из двух частей. Первая — многоуровневая архитектура, где возможности собирают в более широкие доменные инструменты с типизированными действиями внутри. Вторая — переход к файловым и кодоподобным представлениям проекта, чтобы агент работал не только через цепочку вызовов API, но и через более понятную для модели структуру.
Инфраструктура стала не менее важной, чем сами инструменты
По мере роста сценариев выяснилось, что критичны не только сами команды, но и служебный слой: сессии, наблюдаемость, маршрутизация и координация среды выполнения. Для части операций Webflow использует мост по WebSocket к Designer Extension внутри активной пользовательской сессии. При этом компания параллельно переносит больше возможностей Designer в API без браузерного интерфейса, чтобы меньше зависеть от живой сессии в браузере.
Это уже не история про «добавили интеграцию с AI». Это история про переделку платформенного слоя под новый тип клиента, который мыслит иначе, чем разработчик или человек в интерфейсе.
Значение для рынка
Для стартапов это вопрос скорости вывода агентных функций без бесконечной ручной доводки. Для крупных компаний — вопрос стоимости интеграции и устойчивости сценариев в продакшене. Для агентств и сервисных команд вывод ещё проще: если продукт требует помнить пять промежуточных идентификаторов и вручную разбирать состояние, агент рано или поздно ошибётся. Выиграют те платформы, которые сократят число шагов, сделают инструменты крупнее по смыслу и уберут лишнюю хрупкость из API.
Следующий этап рынка выглядит предсказуемо: компании будут соревноваться уже не количеством MCP-серверов, а тем, насколько их инструменты позволяют агенту действительно довести задачу до конца.
Источник: блог Webflow, The New Stack.