Привет, Хабр. Меня зовут Дима, я делаю WebAsk — конструктор опросов и тестов. Четыре года назад я писал тут про тотализатор на коленке, спагетти-код из 5к строк и борьбу с мобильным скроллом.

Но сегодня не про это. Сегодня — как мы дали нейронкам прямой доступ к нашему сервису через MCP, какие грабли собрали по дороге и что из этого получилось.

Для тех, кто пропустил хайп: MCP (Model Context Protocol) — открытый стандарт от Anthropic. Он позволяет ллм аля клод, курсор и другим подключаться к внешним сервисам и управлять ими напрямую — без браузера, без ручных оберток, без гемора (ну как сказать). На Хабре про это уже штук пятнадцать статей, пересказывать не буду, сорян))

Зачем нам это сдалось

Мы долго наблюдали один и тот же сценарий. Человек сидит в ллмке — пишет текст, разбирает код, готовит отчет. И тут ему прилетает задача: «надо собрать обратную связь по конференции» или «создай опрос для сотрудников в отделе HR». Что происходит дальше:

Новая вкладка. Логин в сервис. 15 минут тыканья в конструктор. Копирование ссылки. Возврат к ллмке. Контекст потерян, мысль ушла, кофе остыл, коллега уже написал «ну что там с опросом?», а ты еще даже не проснулся

И так каждый раз

Параллельно мы видели, что весь мировой рынок зашевелился. Typeform выкатил свой MCP-сервер в бету. Atlassian, Google, MongoDB — уже подключились. Anthropic и Cursor добавили нативную поддержку MCP-серверов прямо в свои клиенты. Для SaaS это перестало быть экзотикой — MCP превращается в такой же ожидаемый интеграционный слой, как REST API и вебхуки пять лет назад.

У нас к тому моменту был REST API, ИИ-генерация опросов, вебхуки. Добавить MCP-сервер поверх этого было логичным следующим шагом. Не потому что модно, а потому что задача понятная: дать ассистенту прямой доступ ко всему, что умеет наш сервис, чтобы пользователю не приходилось переключаться между окнами.

«Погоди, а зачем конструктор, если ИИ и так умеет в опросы?»

ChatGPT может сгенерить опрос за тридцать секунд. Claude напишет анкету на React с ветвлениями. Зачем тогда отдельный сервис

Потому что сгенерить вопросы — это 5% работы. Остальные 95% — это инфраструктура:

• Кто захостит опрос? Куда 10 000 респондентов пойдут отвечать?

• Кто соберет ответы? В какую базу? Кто гарантирует, что ничего не потеряется?

• Кто посчитает аналитику? NPS-сегментацию из тысячи ответов? Тепловую карту из двух тысяч кликов по макету?

• Кто экспортирует результаты в Excel для отчета руководителю?

• Кто отправит данные в Bitrix24, в MAX Telegram, в Google Sheets?

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

MCP как раз про это. Он не помогает ИИ придумывать вопросы — с этим ИИ и сам справляется. Он дает ИИ доступ к работающей инфраструктуре: создать опрос, который реально захостится и будет принимать ответы. Собрать данные с живых респондентов, посчитать NPS, построить тепловую карту по клик-тесту, выгрузить в Excel — и все через один диалог.

ИИ — офигительный интерфейс. Но для проведения исследования ему нужна инфраструктура за спиной. Без MCP он может придумать вопросы. С MCP — провести исследование от создания до экспорта результатов.

Как мы это строили

Ладно, к технике;)

Протокол: JSON-RPC 2.0, авторизация через Bearer-токен. Ключ генерируется в личном кабинете и показывается ровно один раз. Если потеряли — генерируете новый. Так что записывайте сразу, второго шанса не будет.

Подключение к Claude Desktop — стандартный конфиг MCP-сервера:

{
  "mcpServers": {
    "your-service": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-fetch"],
      "env": {
        "MCP_URL": "https://your-service.example.com/mcp/v1",
        "MCP_AUTH_HEADER": "Authorization",
        "MCP_AUTH_VALUE": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Скопировал, вставил, перезапустил Claude Desktop — все, инструменты появились в списке. Для Cursor и VS Code конфиги чуть другие, но принцип тот же

Что внутри. По спеке MCP умеет три штуки: ресурсы (чтение), инструменты (действия) и промпты (подсказки). На деле оказалось, что Claude Desktop поддерживает только инструменты — ресурсы и промпты просто игнорирует. Claude Code и Cursor поддерживают все, но рассчитывать что все сидят именно там — не вариант.

Поэтому мы обернули все ресурсы в инструменты-обертки. Хочешь прочитать ответы? Вызываешь инструмент-обертку. Сводку? Другой инструмент. Структуру опроса? Третий. 19 таких оберток — по одной на каждый ресурс.

В итоге получилось 40+ инструментов действий плюс 19 инструментов чтения — итого под 60 тулзов. Когда мы посчитали итоговое количество — сами немного офигели.

Интересная табличка 👇

Как это устроено внутри. MCP-сервер написан на Node.js и работает как прослойка между MCP-клиентами (Claude, Cursor) и нашим основным бэкендом. По сути тонкая прослойка: получил JSON-RPC запрос, определил какой инструмент вызвать, провалидировал параметры, дернул API, вернул результат.

Каждый инструмент — отдельный обработчик со своей схемой валидации. Общий роутер разбирает запрос по имени инструмента и перенаправляет в нужный обработчик. Упрощенно это выглядит так:

// описания лежат отдельно от логики
const tools = loadToolDescriptions('./tools/descriptions/')

// роутер
function handleToolCall(name, params) {
  const handler = handlers[name]        // находим обработчик
  const schema = tools[name].params     // берем схему валидации
  validate(params, schema)              // валидируем параметры
  return handler.execute(params)        // вызываем основной API
}

// обработчик - один файл на один инструмент
// tools/handlers/rename_quiz.js
export function execute({ quiz_id, name }) {
  return api.patch(/quizzes/${quiz_id}, { name })
}

Ничего сложного, но когда их под 60 — важно не превратить в кашу:) Один файл = один инструмент, описания отдельно от логики, валидация автоматическая по схеме.

Проблема контекстного окна. Под 60 описаний инструментов — это примерно 6 000 токенов контекста, которые модель получает при каждом обращении. Пробовали отдавать описания группами: сначала только базовые, остальные — по запросу. Не взлетело. Модель не знала о существовании инструментов из непрогруженных групп и даже не пыталась их запросить. Вернулись к полному списку. Дороже по токенам, зато модель видит все и выбирает точнее.

Описания отдельно от кода. Еще одно архитектурное решение, которое себя оправдало: описания инструментов хранятся отдельно от бизнес-логики обработчиков. Итерируем их независимо — можно переписать описание, не трогая код, и наоборот. Звучит очевидно, но когда ты в спешке пишешь все в одном файле — потом это больно разделять.

Окей, это скелет. Дальше интереснее — грабли…(

Его величество описания инструментов

Вот тут мы вообще не ожидали подвоха. На описания инструментов ушло больше времени, чем на саму интеграцию с API. Без шуток

Проблема вот в чем. Когда LLM получает список из 40+ инструментов, она должна по описанию понять, какой из них вызвать и с какими параметрами. Если описание нечеткое или двусмысленное — модель промахивается. Вызывает не тот инструмент. Передает неправильные параметры. Или вообще решает, что нужного инструмента нет, и начинает импровизировать.

Мы сначала пошли по пути экономии. Написали краткие описания — по одному предложению на инструмент. Логика была простая: меньше токенов на контекст — дешевле — быстрее. Красиво на бумаге

На практике: промах в ~30% случаев на сложных цепочках. Модель путала похожие инструменты, не понимала разницу между чтением ответов и чтением сводки. При дублировании опроса забывала передать ID шаблона.

Переписали все описания на подробные — с пояснениями, примерами параметров, типичными сценариями использования. Да, это больше токенов. Да, это немного дороже на каждый запрос. Но точность выросла прям заметно. Экономия на описаниях — ложная экономия.

Конкретный пример: у нас есть два похожих инструмента — один обновляет тексты приветственного и финального экранов, другой — тексты самих вопросов. В первой версии оба были описаны как «обновить тексты опроса». Модель путала их в каждом втором случае. Когда мы явно прописали, что первый работает только с экранами приветствия и благодарности, а для вопросов нужен другой инструмент — путаница прекратилась.

Разница — как между «закрой дверь» и «закрой входную дверь, которая слева, а не дверь в ванную». Для человека и так понятно. Для нейронки — нет

180 запросов в минуту, или Почему агенты — это стихийное бедствие

Отдельная история — лимит запросов. Когда ты делаешь API для людей, 60 запросов в минуту — это с запасом. Человек физически не нажмет кнопку 60 раз за минуту.

С ИИ-агентами все иначе. Агент получает задачу «создай 10 опросов по шаблону с разными параметрами» — и начинает фигачить. Без пауз, без раздумий, без перерыва на кофе. Десять цепочек по 5-7 вызовов = 50-70 запросов за несколько секунд.

60 — безопасно для бэкенда, но агент упрется на любой нетривиальной задаче. 300 — удобно, но один юзер с агрессивным автоматизатором положит сервис остальным. Остановились на 180 — хватает для цепочки из 20+ вызовов, но DDoS от одного агента не устроишь. Ссылки на экспорт живут час

Тестирование, или «Claude, ты что делаешь?»

С юнит-тестами все ок. А потом мы подключили реального Claude и тут началось

Модель — это не детерминированный клиент. Она может вызвать инструменты в рандомном порядке. Додумать параметры. Или просто проигнорить описание и сделать по-своему.

Один из наших любимых багов: мы просили Claude «создай опрос с тремя вопросами и опубликуй». Claude создавал опрос, добавлял три вопроса, потом решал, что неплохо бы еще добавить приветственный экран с мотивирующим текстом (мы не просили), менял тему на «более подходящую» (мы не просили) и только потом публиковал. Инструменты работали корректно. Просто модель решила проявить инициативу :)

Починили жесткими промптами и явными указаниями в описаниях: инструмент делает только то, что написано, и ничего больше. Помогло. Частично

Формальных eval-фреймворков у нас не было. Тестировали руками: ~20 сценариев, прогоняли после каждого изменения описаний. Пишешь промпт, смотришь какие инструменты вызвались, если не те — правишь описание, повторяешь. Описания переписывали по 3-4 раза, некоторые — больше

Больше всего бесили инструменты с похожими названиями и инструменты с кучей необязательных параметров. Тестирование MCP — это, по сути, тестирование промптов. Только промпты — это ваши описания инструментов. Ну вы поняли.

«А где мои ресурсы?», или Сюрприз от Claude Desktop

Это надо знать заранее, серьезно:)

В спецификации MCP три штуки: tools, resources, prompts. Мы сделали ресурсы — для ответов, сводки, структуры опроса, еще полтора десятка. Подключили Claude Desktop. Просим прочитать ответы.

А он не может. Ресурс есть, но Claude Desktop их просто не поддерживает. Только тулзы. Ни ресурсы, ни промпты. Вот так

Claude Code и Cursor — поддерживают все: и ресурсы, и промпты. Но Claude Desktop — самый массовый клиент, и рассчитывать на то, что все пользователи сидят в CLI или Cursor, мы не могли.

Решение: обернули все 19 ресурсов в инструменты-обертки — по одной обертке на каждый ресурс. Тулз вызывает ресурс внутри себя и возвращает данные. Для модели это выглядит как обычный инструмент, для пользователя — разницы ноль.

Мораль: если делаете MCP-сервер и хотите, чтобы он работал не только в CLI — дублируйте ресурсы как тулзы. По спецификации это не нужно. На практике — без этого половина клиентов вас не увидит.

Как этим пользуются на практике

Когда запустились и полезли в логи — оказалось, что мы неправильно понимали вообще все.

Мы думали, что киллер-фича — создание опросов. Ну логично: мы конструктор, значит, люди будут конструировать. Через Claude вместо UI — быстрее, удобнее, контекст не теряется. Пять вызовов — и опрос с вопросами, темой и публичной ссылкой готов. Это и правда работает, и это и правда быстрее

Но самый частый сценарий оказался другим…;)

Главный сюрприз: никто не хотел создавать. Все хотели читать

Аналитику дергают сильно чаще, чем создание. Типичная ситуация: у человека опрос, который уже неделю собирает ответы. Накопилось 500 текстовых ответов на открытые вопросы. И ему нужно из этой каши вытащить смысл — основные темы, повторяющиеся жалобы, неожиданные инсайты.

Раньше это означало: открыть отчет, начать скроллить, к пятидесятому ответу забыть, что было в десятом, к сотому — потерять волю к жизни. На 500 ответах — это полдня работы и желание никогда больше не делать опросы с открытыми вопросами.

Через MCP — Cursor читает все ответы, группирует по темам, выделяет паттерны, считает метрики и отдает выжимку. Плюс экспорт в Excel — и инфа уже готова для отчета руководителю. Минута вместо трех часов:)))

Оказывается, людям лень читать ответы на собственные опросы. Мы их понимаем, тоже такие :)

Но по-настоящему MCP раскрывается в цепочках. Один вызов на создание — это удобно, но не сильно отличается от клика по кнопке. А вот когда агент выстраивает цепочку из 5-9 вызовов подряд — тут начинается совсем другая история.

Пример: автоматизация онбординг-опросов. Каждому новому пользователю через три дня после регистрации нужно отправить персонализированную анкету — с его именем, с вопросами под его тариф. А потом собрать ответы и выгрузить в дашборд. Вручную это делать — хочется уволиться на третьем пользователе. Через MCP агент сам дублирует шаблон, подставляет имя через скрытую переменную, настраивает логику ветвлений под тариф, публикует, а через три дня сам же собирает ответы и экспортирует в CSV. Девять вызовов, ноль ручного труда.

webhook - duplicate - create_hidden_variables - update_texts - update_logic - publish - [3 дня] - answers - export_csv

Скрытые переменные — отдельная штука, которая тут работает на ура. Создаете переменную с именем пользователя, привязываете к полю приветствия — и каждый респондент видит «Привет, Маша!», хотя опрос создан из одного шаблона.

Итерации прямо из IDE. Мы подключили MCP к Cursor, и оказалось, что для UX-ресерчеров это вообще отдельный мир. Прочитал структуру опроса, поправил логику ветвлений, проверил сколько ответов набралось, выгрузил PDF-отчет для стейкхолдеров — и все это не выходя из редактора. Мелочь, но в потоке это экономит не время, а нервы.

Что еще нас удивило

Модель помнит контекст между вызовами — казалось бы очевидно, но на практике прям впечатляет. Человек говорит: «Создай опрос». Потом: «Добавь вопрос про бюджет». Потом: «А покажи, что получилось». Claude помнит айдишник опроса, знает текущую структуру и не теряет нить. Для юзера это выглядит как разговор, а не дерганье API.

Экспорт завершает каждую цепочку. Создал — настроил — собрал — выгрузил в CSV, Excel, PDF или Word. Без экспорта результат остается внутри сервиса. С экспортом — попадает в дашборд, в отчет, в письмо руководителю. Мы чуть не сделали экспорт в последнюю очередь. Это было бы примерно как построить дом и забыть про двери.

MCP vs REST API — зачем два интерфейса

У нас есть полноценный REST API, который покрывает всю функциональность. Зачем тогда MCP?

Потому что потребители разные.

API — для разработчиков. Вы пишете код, точно знаете, какой эндпоинт вызвать, какие параметры передать, как обработать ответ. Все детерминировано, все предсказуемо

MCP — для ИИ-агентов. Вы даете модели набор из ~60 инструментов с описаниями, а она сама решает, что и когда вызвать. Пользователь говорит «создай анкету для оценки сотрудников с NPS-шкалой и логикой ветвлений» — и агент сам разбирает это на шаги, сам выбирает инструменты, сам склеивает результат. Разработчик не писал ни строчки кода

Это не замена. Это параллельный слой. REST API, вебхуки, MCP — три разных интерфейса для трех разных задач. API — для интеграций. Вебхуки — для событий. MCP — для ИИ-агентов.

Короче

Самое неожиданное во всей этой истории — что главная работа оказалась не в коде. Архитектура простая, роутер примитивный, обработчики — обертки над API. А вот тексты описаний инструментов мы переписывали раз пять и до сих пор не уверены, что они идеальные.

Еще мы не ожидали, что люди будут больше читать через MCP, чем создавать. И что Клод в 2026 году все еще не поддерживает ресурсы MCP — пришлось городить обертки

И предвкушаю вопрос “есть ли метрики” — сразу отвечу, что рано, тк запустили недавно. Когда будет что показать — напишу, ну или пните меня)

А если вы делали свой MCP-сервер — расскажите в комментах, как решали проблему описаний. У нас ощущение, что можно лучше, но пока не понимаем как

Респект всем, кто дочитал ❤️