WebAsk launched an MCP server for surveys and found that AI reads more than it creates

WebAsk подключил свой конструктор опросов и тестов к MCP, чтобы Claude, Cursor и другие LLM-клиенты могли работать с сервисом без переходов в браузер. После запуска команда выяснила, что главный спрос пришёл не на генерацию новых анкет, а на чтение, разбор и экспорт уже собранных ответов.

Зачем

WebAsk MCP Команда WebAsk описывает знакомый сценарий: пользователь пишет в LLM отчёт или разбирает код, а потом ему нужно срочно собрать опрос для HR, конференции или онбординга. Без интеграции это означает новый таб, логин в сервис, ручную настройку формы и потерю контекста. На этом фоне MCP стал для продукта не модной надстройкой, а способом оставить пользователя в одном диалоге с ассистентом и отдать модели доступ к уже существующей инфраструктуре сервиса.

При этом в WebAsk подчёркивают: LLM умеют быстро придумать вопросы, но сама анкета — только малая часть работы. Для реального исследования нужны сервисные функции, которые не решаются одним промптом: публикация и хостинг опроса для тысяч респондентов сбор ответов без потерь и хранение данных аналитика вроде NPS, сегментации и тепловых карт экспорт результатов в CSV, Excel, PDF и Word * интеграции с внешними системами и вебхуками ## Как устроили сервер Сам MCP-сервер команда сделала как тонкую Node.js-прослойку между клиентами вроде Claude и Cursor и основным бэкендом WebAsk.

Снаружи это JSON-RPC 2.0 с авторизацией через Bearer-токен, внутри — роутер, схемы валидации и отдельный обработчик на каждый инструмент. Архитектура получилась прямолинейной: запрос приходит по имени тулзы, параметры валидируются по схеме, после чего сервер вызывает соответствующий метод REST API и возвращает ответ модели.

Главная практическая проблема оказалась не в коде, а в совместимости клиентов. По спецификации MCP умеет работать с tools, resources и prompts, но в Claude Desktop команда увидела поддержку только tools. Поэтому WebAsk завернул 19 ресурсов — например, чтение ответов, структуры опроса и сводки — в отдельные инструменты-обёртки.

В итоге сервер вырос до примерно 60 тулзов, разбитых по группам: жизненный цикл опроса, контент, оформление, аналитика, экспорт и промокоды.

Где были грабли Самый болезненный урок касался описаний инструментов.

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

«Экономия на описаниях — ложная экономия».

Параллельно пришлось пересмотреть лимиты и сам подход к тестированию. Если человеку хватает 60 запросов в минуту, то агент легко делает 50–70 вызовов за несколько секунд, поэтому WebAsk остановился на пороге 180 запросов в минуту. А тестирование превратилось в ручной прогон примерно 20 сценариев: модель могла менять порядок действий, додумывать приветственный экран или тему оформления и проявлять лишнюю инициативу. На практике самым частым кейсом вообще стал не конструктор, а аналитика: Cursor читает сотни текстовых ответов, группирует их по темам и готовит выжимку для отчёта быстрее, чем человек успеет открыть нужный дашборд.

Что это значит

История WebAsk хорошо показывает, что MCP для SaaS — это уже не игрушка для демо, а новый интерфейс поверх существующего продукта. Но выигрывает не тот, кто просто открыл доступ к API для LLM, а тот, кто продумал описания инструментов, ограничения клиентов и реальные пользовательские цепочки, где ИИ экономит не клики, а часы ручной работы.