Привет, Хабр. Меня зовут Дима, я создаю WebAsk — конструктор опросов, исследований и тестов. Четыре года назад я писал здесь про тотализатор на коленке, спагетти-код из 5000 строк и борьбу с мобильным скроллом. С тех пор сервис вырос из пет-проекта в рабочий инструмент для более чем 50 000 пользователей.
Как мы дали ИИ-ассистентам доступ к WebAsk через MCP
Сегодня — не про рост, а про то, как мы подключили ИИ-ассистенты к WebAsk через MCP, какие ошибки допустили и к чему это привело.
Для тех, кто в теме: MCP (Model Context Protocol) — открытый стандарт от Anthropic. Он позволяет ИИ-ассистентам вроде Claude, Cursor и Copilot напрямую подключаться к внешним сервисам — без браузера, ручных обёрток и копипасты. На Хабре уже много статей про протокол, так что подробности опускаем.
Зачем нам это понадобилось
Мы часто видели одну и ту же картину. Пользователь работает в Claude: пишет текст, разбирает код, готовит отчёт. И вдруг — задача: «Собери обратную связь по конференции» или «Создай опрос для HR-отдела».
Что происходит дальше? Открывается новая вкладка. Логин в WebAsk. 15 минут тыканья по интерфейсу. Копирование ссылки. Возврат в Claude. Контекст потерян, мысль ушла, кофе остыл, коллега уже спрашивает: «Ну что там с опросом?» — а тема ещё не выбрана.
Параллельно весь рынок начал двигаться. Typeform запустил MCP-сервер в бету. Atlassian, Google, MongoDB — уже подключились. Anthropic и Cursor добавили нативную поддержку MCP. Для SaaS-продуктов это перестало быть экзотикой. MCP становится таким же ожидаемым интеграционным слоем, как REST API и вебхуки пять лет назад.
Мы посмотрели на российский рынок. Сколько сервисов опросов в России поддерживают MCP?
Anketolog — нет. Testograf — нет. Survio — нет. Ни один. Мы проверили всех, кого могли вспомнить.
У нас уже был REST API v3, работала ИИ-генерация опросов, были вебхуки. Добавить MCP-сервер было логичным шагом. Не потому что модно, а потому что задача ясна: дать ассистенту прямой доступ ко всему функционалу WebAsk, чтобы пользователю не приходилось переключаться между окнами.
«Зачем конструктор, если ИИ и так генерирует опросы?»
Да, ChatGPT создаст опрос за 30 секунд. Claude напишет анкету на React с ветвлениями. Но сгенерировать вопросы — это 5% работы. Остальные 95% — инфраструктура:
- Кто захостит опрос? Куда пойдут 10 000 респондентов?
- Кто соберёт ответы? В какую базу? Кто гарантирует, что ничего не потеряется?
- Кто посчитает аналитику? NPS-сегментацию по тысяче ответов? Тепловую карту по двум тысячам кликов?
- Кто экспортирует результаты в Excel для отчёта?
- Кто отправит данные в Bitrix24, MAX, Telegram или Google Sheets?
Это как сказать: «Зачем Stripe, если ИИ может написать платёжную страницу». Страницу — может. Обработать платежи — нет.
Генерация вопросов — это фронтенд. А за ним нужен бэкенд: хостинг, сбор данных, аналитика, интеграции, экспорт.
MCP как раз про это. Он не помогает ИИ придумывать вопросы — с этим ИИ справляется сам. Он даёт ИИ доступ к работающей инфраструктуре: создать опрос, который реально захостится и будет принимать ответы, собрать данные, посчитать NPS, построить тепловую карту, выгрузить всё в Excel — через один диалог.
ИИ — отличный интерфейс. Но для исследования ему нужна инфраструктура. Без MCP он может придумать вопросы. С MCP — провести исследование от создания до экспорта результатов.
Как мы это построили
Эндпоинт: POST https://mcp.webask.io/mcp/v1. Протокол — JSON-RPC 2.0, авторизация через Bearer-токен. Ключ генерируется в личном кабинете (Настройки → API/MCP) и показывается один раз.
Подключение к Claude Desktop простое: скопировал, вставил, перезапустил — и инструменты WebAsk появляются в списке. Для Cursor и VS Code конфиги другие, всё есть в документации.
По спецификации MCP поддерживает три типа возможностей: ресурсы (чтение), инструменты (действия) и промпты (подсказки). На практике выяснилось, что Claude Desktop поддерживает только инструменты — ресурсы и промпты игнорируются. Cursor и Claude CLI поддерживают всё, но рассчитывать только на них нельзя.
Поэтому мы обернули все ресурсы в инструменты-обёртки. Хотите прочитать ответы? Вызываете get_quiz_answers. Сводку? get_quiz_summary. Структуру опроса? get_quiz_structure. Всего — 19 таких обёрток.
В итоге получилось более 40 инструментов действий и 19 — чтения. Всего около 60 тулзов. Когда посчитали — сами удивились.
Группы инструментов:
- Жизненный цикл: создать, переименовать, дублировать, архивировать, удалить, опубликовать
- Редактирование: вопросы, тексты, настройки, логика ветвлений, загрузка медиа
- Оформление: применить тему, создать свою, настройка под бренд
- Аналитика: сводка, фильтрованные отчёты, теги ответов, ссылки для шеринга
- Экспорт: CSV, XLSX, PDF, Word
- Управление респондентами: создание групп, коды доступа, списки
MCP-сервер написан на Node.js. Это прослойка между MCP-клиентами (Claude, Cursor) и основным бэкендом WebAsk. Он принимает JSON-RPC запрос, определяет нужный инструмент, валидирует параметры, вызывает API и возвращает результат.
Каждый инструмент — отдельный обработчик со своей схемой валидации. Общий роутер направляет запрос по имени инструмента. Архитектура простая: один файл — один инструмент, описания отдельно от логики, валидация по схеме.
Проблема контекстного окна. Описания 60 инструментов — это около 6000 токенов на каждый запрос. Мы пробовали ленивую загрузку: сначала базовые инструменты, остальные — по запросу. Не сработало. Модель просто не знала о существовании незагруженных инструментов. Вернулись к полному списку — дороже, но точнее.
Описания отдельно от кода. Важное архитектурное решение: описания хранятся отдельно от бизнес-логики. Можно менять текст без переписывания кода и наоборот. Звучит очевидно, но на практике — легко запутаться, если всё в одном файле.
Главная грабля: описания инструментов
Мы потратили на описания больше времени, чем на техническую интеграцию. Почему? Когда LLM получает список из 40+ инструментов, она должна по описанию понять, какой вызвать и с какими параметрами. Если описание нечёткое — модель ошибается.
Сначала мы экономили токены: краткие описания — по одному предложению. Результат: промахи в 30% случаев. Модель путала update_widgets и update_texts, не понимала разницу между quiz://{id}/answers и quiz://{id}/summary, при дублировании забывала ID шаблона.
Переписали все описания подробно — с примерами, пояснениями, сценариями. Да, больше токенов. Да, дороже. Но точность выросла радикально. Экономия на описаниях — ложная.
Пример: два инструмента — один обновляет тексты приветствия и финала, другой — тексты вопросов. Сначала оба описаны как «обновить тексты опроса». Модель путала их в каждом втором случае. После уточнения — всё стало работать.
Разница — как между «закрой дверь» и «закрой входную дверь слева, а не в ванную». Для человека понятно. Для LLM — нет.
180 запросов в минуту: агенты — это стихийное бедствие
Для людей 60 запросов в минуту — запас с избытком. Человек не нажмёт 60 раз за минуту. Агенты — могут.
Задача: «Создай 10 опросов по шаблону» — и агент запускает 10 цепочек по 5–7 вызовов. За несколько секунд — 50–70 запросов.
Выбор: 60 — безопасно, но агент упирается в лимит. 300 — удобно, но риск DDoS. Остановились на 180. Хватает для цепочек из 20+ вызовов, но не даёт одному пользователю перегрузить систему. Ссылки на файлы живут час — компромисс между удобством и нагрузкой.
Тестирование: «Claude, ты что делаешь?»
Юнит-тесты — это хорошо. Но реальный Claude — непредсказуем. Он может вызывать инструменты в неожиданном порядке, творчески интерпретировать параметры или вежливо проигнорировать половину описания.
Баг: просим «создай опрос с тремя вопросами и опубликуй». Claude создаёт, добавляет вопросы, решает, что нужно приветствие с мотивирующим текстом (не просили), меняет тему (не просили), потом публикует. Инструменты работают. Модель просто проявила инициативу.
Решение: жёсткие промпты + явные указания в описаниях, что инструмент делает только то, что сказано. Добавили серверные подсказки для типовых сценариев.
Тестирование: собрали 20 типовых сценариев — «создай опрос с тремя вопросами», «покажи аналитику», «продублируй шаблон». После каждого изменения — прогоняли вручную.
Цикл: промпт → смотрим, какие инструменты вызвались → если не те — правим описание → повторяем. Описания переписывались в среднем 3–4 раза, некоторые — больше.
Самые проблемные — инструменты с похожими названиями и кучей необязательных параметров. Тестирование MCP-сервера — это по сути тестирование промптов. Только промпты — это описания инструментов.
Сюрприз от Claude: ресурсы не работают
По спецификации MCP поддерживает ресурсы, инструменты и промпты. Мы честно реализовали ресурсы: quiz://{id}/answers, quiz://{id}/summary и другие. Подключили к Claude, просим прочитать ответы.
Claude отвечает: «Не могу. Ресурс есть, но читать не умею». Поддерживает только инструменты. Cursor и Claude CLI — поддерживают всё. Но Claude — самый массовый клиент.
Решение: обернули все 19 ресурсов в инструменты-обёртки. Для модели — обычный тулз. Для пользователя — разницы нет.
Мораль: если хотите, чтобы MCP-сервер работал не только в CLI — дублируйте ресурсы как инструменты. По спецификации не нужно. На практике — без этого половина клиентов вас не увидит.
Как этим пользуются на практике
Мы думали, что главная фича — создание опросов. Логично: мы конструктор, значит, люди будут конструировать. Через Claude — быстрее, без переключений. Пять вызовов — и опрос готов.
Но самый частый сценарий оказался другим.
Главный сюрприз: никто не хотел создавать. Все хотели читать
Инструменты аналитики вызываются чаще, чем инструменты создания. Типичная ситуация: опрос собирает ответы неделю. Накопилось 500 текстовых ответов. Нужно вытащить смысл — темы, жалобы, странности.
Раньше — скролл, потеря контекста, усталость. На 500 ответах — полдня и желание больше не делать открытые вопросы.
Через MCP — Cursor читает все ответы, группирует по темам, выделяет паттерны, считает метрики, отдаёт структурированную выжимку. Плюс экспорт в Excel — и данные готовы к отчёту. Минута вместо трёх часов.
Оказывается, людям лень читать ответы на собственные опросы. Мы их понимаем — мы тоже такие.
Но MCP раскрывается в цепочках. Один вызов — удобно, но не сильно отличается от клика. А вот цепочка из 5–9 вызовов — это уже другая история.
Пример: автоматизация онбординг-опросов. Каждому новому пользователю через три дня нужно отправить персонализированную анкету — с именем, под тариф. Потом собрать ответы и выгрузить в дашборд. Вручную — хочется уволиться на третьем пользователе.
Через MCP агент сам дублирует шаблон, подставляет имя через скрытую переменную, настраивает логику под тариф, публикует. Через три дня — сам собирает ответы и экспортирует в CSV. Девять вызовов, ноль ручного труда.
Скрытые переменные работают отлично. Привязали имя к приветствию — и каждый респондент видит «Привет, Маша!», хотя опрос из одного шаблона.
Итерации из IDE. Мы подключили MCP к Cursor — и для UX-исследователей это открыло новый мир. Прочитал структуру, поправил логику, проверил ответы, выгрузил PDF — и всё не выходя из редактора. Кажется мелочью, но экономит не время — а нервы.
Что ещё удивило
Модель помнит контекст между вызовами. Пользователь говорит: «Создай опрос». Потом: «Добавь вопрос про бюджет». Потом: «Покажи, что получилось». Claude помнит ID, структуру, не теряет нить. Ощущается как разговор с живым ассистентом.
Экспорт завершает каждую цепочку. Создал → настроил → собрал → выгрузил в CSV, Excel, PDF или Word. Без экспорта результат остаётся в сервисе. С экспортом — попадает в отчёт, письмо, дашборд. Мы чуть не сделали экспорт в последнюю очередь. Это было бы как построить дом и забыть про двери.
MCP vs REST API: зачем два интерфейса?
У нас есть полноценный REST API v3. Зачем MCP?
Потому что у них разные потребители.
API — для разработчиков. Вы знаете, какой эндпоинт вызвать, какие параметры передать. Всё детерминировано.
MCP — для ИИ-агентов. Вы даёте модельке ~60 инструментов с описаниями. Она сама решает, что и когда вызвать. Пользователь говорит: «Создай анкету с NPS и ветвлениями» — и агент сам разбирает это на шаги. Разработчик не писал ни строчки кода.
Это не замена. Это параллельный слой. REST API, вебхуки, MCP — три интерфейса для трёх задач. API — для интеграций. Вебхуки — для событий. MCP — для ИИ-агентов.
Что дальше
Мы расширяем MCP-сервер. В планах:
- Больше инструментов, особенно для логики ветвлений
- Потоковая передача данных для быстрого взаимодействия
- Умный отчёт с ИИ-аналитикой: анализ тональности, группировка по темам, выявление аномалий
Цель — превратить сырые данные в осмысленные выводы.
На момент публикации WebAsk — единственный российский сервис опросов с MCP-сервером. Констатируем факт. Надеемся, что другие подтянутся. Конкуренция на пользу.
Метрики пока не публикуем — запустились в марте, данных мало. Первые наблюдения:
- Аналитика популярнее создания
- Цепочки ценнее одиночных вызовов
- Описания инструментов — самая итерируемая часть
Когда накопим статистику — расскажем отдельно.