Мы написали MCP-сервер и подключили Claude к своей CRM. Показываю, как это работает

Каждое утро я открывал CRM, чтобы проверить задачи по десяти проектам, создать новые, посмотреть статус сделок и прочитать обсуждения в клиентских Telegram-группах. Это занимало полчаса-час, и половина этого времени уходила на клики и переключение между экранами. Потом я попробовал объяснить всё это AI на обычном русском языке, и обратно возвращаться уже не захотелось.

Речь о технологии Model Context Protocol (MCP). Если вы слышали этот термин, но не понимали, зачем он нужен бизнесу, а не разработчикам, эта статья для вас.

Я руковожу веб-студией АП-ИМ в Санкт-Петербурге, мы работаем с 2008 года. У нас собственная CRM-система, в которой живут задачи, сделки и встречи. С начала 2026 года мы написали MCP-сервер для этой CRM и подключили его к Claude. Расскажу, что из этого получилось, а что нет.

Что мы хотели получить

Типичный рабочий день руководителя студии выглядит так. Утром нужно пробежаться по задачам в статусе «Тест автором» и проверить, что сделали разработчики. Потом открыть сделки и посмотреть, где клиент уже согласовал цену и пора писать ТЗ. Дальше зайти в три-четыре Telegram-группы, прочитать, что обсуждали за ночь, и по результатам создать задачи. Каждое из этих действий требует нескольких кликов, переходов между разделами, заполнения полей в формах.

Мне хотелось делать то же самое, но текстом:

  • «Покажи мои задачи в работе по проекту IDDIS»
  • «Создай задачу на Иванова: исправить вёрстку каталога на мобильных, срок до пятницы»
  • «Что обсуждают в Telegram-группе клиента? Есть нерешённые вопросы?»
  • «Аванс по сделке 247 пришёл, переведи её в работу»
  • «Назначь встречу с Петровым и Сидоровым на завтра в 15:00»

Все эти запросы сейчас работают. Claude понимает контекст, сам определяет, какие действия нужно выполнить, и делает их в CRM. Причём не просто выполняет одну команду, а выстраивает цепочку. Например, при создании задачи AI сам запрашивает список проектов, находит нужный, получает список сотрудников этого проекта, выбирает ответственного, генерирует заголовок и описание, ставит срок и только потом создаёт задачу. Одна фраза пользователя превращается в три-четыре последовательных вызова к CRM.

MCP-сервер - что это простыми словами

MCP-сервер - это «USB-порт» для AI. Вы втыкаете в него свою программу, и AI получает возможность нажимать в ней кнопки, читать данные и выполнять действия. Не через скриншоты и автокликеры, а через нормальный программный интерфейс.

Model Context Protocol - открытый стандарт от Anthropic, который позволяет AI-моделям работать с внешними системами. Стандарт поддерживается Claude, ChatGPT, Cursor, VS Code Copilot и десятками других инструментов.

Схема работы простая: Claude общается с MCP-сервером, MCP-сервер общается с CRM. Claude не знает, как устроена наша база данных, какие там таблицы и поля. Он знает только список доступных действий и их описания на человеческом языке.

MCP-сервер - это прослойка-переводчик. Он говорит AI: «У тебя есть 18 инструментов, вот что каждый из них делает, вот какие параметры принимает». Дальше AI сам решает, какие инструменты использовать и в каком порядке.

Инструменты сгруппированы по блокам:

  • Задачи: создать, редактировать, искать, получить историю изменений, добавить комментарий
  • Сделки: создать, редактировать, искать с аналитикой по поступлениям и бюджету
  • Встречи: создать, редактировать, удалить, искать (включая повторяющиеся)
  • Справочники: список проектов, список сотрудников по проекту
  • Telegram: список групп, история сообщений с базой знаний, отправка сообщений

Транспорт - Streamable HTTP. MCP-сервер работает через интернет как обычный веб-сервис. Не нужно ставить ничего локально, не нужно запускать Docker. Подключил URL в настройках Claude - и работает. Мы подключили его к Claude.ai, Claude Code и Claude Desktop одновременно.

Важный момент: MCP-сервер не хранит данные и не принимает решения. Он только описывает доступные действия. Все данные остаются в вашей CRM, вся бизнес-логика работает на вашем бэкенде. Это тонкий слой между AI и вашим API.

Что оказалось самым сложным

Писать код MCP-сервера оказалось несложно. Официальный TypeScript SDK хорошо документирован, базовый сервер поднимается за час. У нас уже был Telegram-бот на Gemini 3 Flash с теми же обработчиками, поэтому MCP-сервер просто переиспользовал готовую логику.

Но потом начались настоящие трудности.

Описания инструментов оказались важнее кода. Я потратил примерно 80% времени на то, чтобы сформулировать описания параметров так, чтобы AI их правильно понимал. Это похоже на написание ТЗ для стажёра, который очень старается, но понимает только то, что написано буквально.

Пример. Параметр «ID ответственного» - Claude не понимает, кого имеет в виду пользователь, когда говорит «назначь на меня». Переписываю: «ID ответственного сотрудника. Если пользователь говорит "на меня" или "назначь мне", используй ID текущего пользователя = 20». Теперь работает. Другой пример: текст задачи. Первая версия описания - «Текст задачи». AI генерировал простой текст без форматирования. Финальная версия: «Текст задачи, всегда должен содержать HTML-разметку: абзацы (p), списки (ul, ol, li), выделение (b). Если текст больше 1500 символов, используйте заголовки (h2, h3)». Каждый параметр каждого инструмента пришлось проработать с такой же детальностью.

Поиск по тексту потребовал отдельного решения. Пользователь пишет: «найди задачу про разработку сайта». В базе задача может называться «Создание корпоративного портала». Прямой поиск ничего не даст. Поэтому параметр поиска принимает массив фраз-синонимов. AI подбирает их сам: [«разработка сайта», «создание сайта», «сделать сайт»]. Между фразами работает логическое ИЛИ, внутри фразы - логическое И.

Цепочки вызовов - отдельная головная боль. Чтобы создать задачу, AI должен выполнить три шага: получить список проектов, получить список сотрудников конкретного проекта, и только потом создать задачу с правильными ID. Если описания не объясняют эту последовательность, AI пытается создать задачу сразу и получает ошибку.

Мы написали подробный системный промпт (skill), который описывает порядок вызовов для типичных сценариев. Создание задачи - три инструмента в строгой последовательности. Анализ Telegram-группы - сначала список групп, потом история, потом анализ. Запись аванса по сделке - поиск сделки, потом редактирование с индексом поступления. Без этих инструкций AI ошибался в каждом третьем запросе.

Интеграция с Telegram - неожиданно полезная функция

У нас в CRM интегрирован Telegram-бот, который работает в клиентских группах. Бот сохраняет все сообщения в Redis. Когда я спрашиваю Claude «что обсуждают в группе клиента», происходит следующее: Claude запрашивает список групп, находит нужную, загружает историю сообщений (до 300 последних) вместе со сводкой старых обсуждений и выдаёт структурированный анализ.

Это оказалось одной из самых полезных функций. Раньше я тратил 10-15 минут на чтение переписки в каждой группе, пытаясь вычленить нерешённые вопросы. Теперь говорю: «Разбери обсуждение в группе, создай задачи по нерешённым вопросам». Claude группирует сообщения по темам, предлагает черновики задач с заголовками и описаниями, определяет ответственного и даже ставит автором задачи партнёра-заказчика, если тот участвовал в обсуждении, чтобы партнёр получил доступ к задаче в CRM.

Для самых частых сценариев мы написали готовые инструкции-скиллы, которые Claude подгружает по контексту запроса. «Разбери обсуждение» запускает полный цикл: получить группы, прочитать сообщения, сгруппировать по темам, предложить нерешённые вопросы, после выбора пользователя создать задачи. «Составь смету» находит задачу, разбивает на этапы, оценивает часы, показывает смету и после согласования записывает оценку комментарием. За каждым сценарием стоит детальная инструкция с порядком вызовов, форматом вывода и правилами безопасности.

Результаты: конкретные цифры за 3 месяца

Создание задач. Раньше: открыть форму, выбрать проект из выпадающего списка, найти ответственного, заполнить заголовок, описание, приоритет, срок, нажать сохранить. 2-3 минуты. Сейчас: одно предложение в чате, 15 секунд. Создание задачи с развёрнутым HTML-описанием на основе обсуждения в Telegram-группе - 30 секунд вместо 5-7 минут.

Анализ Telegram-групп. 8 клиентских групп, в каждой 50-200 сообщений в день. Раньше я читал их все руками, выцепляя нерешённые вопросы. 30-60 минут ежедневно. Сейчас: «Покажи нерешённые вопросы по всем активным группам». 2-3 минуты на чтение + подтверждение задач.

Работа со сделками. У нас воронка из 10 статусов. При получении аванса раньше нужно было: открыть сделку, найти нужное поступление, отметить оплату, сменить статус на «В работе». CRM автоматически переводит все задачи сделки из «Согласование» в «В работе» и обновляет сроки. Теперь вся эта цепочка запускается одной фразой: «Аванс по сделке 247 пришёл».

Оценка задач. Claude анализирует текст задачи, разбивает на подзадачи, оценивает трудозатраты в часах с учётом нашего стека (Next.js + Express.js + TypeScript) и записывает смету в CRM. Это не замена живой оценке от разработчика, но хорошая отправная точка: в 70% случаев оценка Claude отличается от финальной не более чем на 20%.

Общая картина. Около 60% рутинных CRM-операций теперь проходят через чат. Экономия - примерно 1,5-2 часа в день. При этом ни одна сложная операция (аналитика с графиками, массовое редактирование, визуальное планирование) не ушла из обычного интерфейса. Чат и CRM работают параллельно.

Разработчики тоже подключились. Тот же MCP-сервер подключен к Claude Code, и теперь разработчик прямо из терминала может посмотреть текст задачи, прочитать комментарии коллег, отметить задачу как выполненную. Без переключения из IDE в браузер. За день это десятки сэкономленных переключений контекста.

Что бы сделали иначе

Начинать с 3-5 инструментов, не с 18. Мы запустили весь набор и потом неделю правили описания, потому что AI путался между похожими инструментами. Лучше сначала отладить задачи (создание + поиск + редактирование), убедиться, что цепочки работают стабильно, и только потом добавлять сделки и встречи.

Версионировать описания отдельно от кода. Мы поменяли описание параметра поиска шесть раз, пока не добились стабильных результатов. Каждое изменение в описании - это изменение в поведении AI. Нужно отслеживать, какая формулировка работает лучше.

Писать тесты сразу. Автоматические тесты на типичные сценарии («создай задачу на Иванова по проекту CRM с высоким приоритетом») помогли бы поймать регрессии при изменении описаний. Мы написали их позже, чем стоило.

В длинных диалогах AI забывает инструкции. Если разговор тянется на десятки сообщений, Claude может пропустить шаг в цепочке вызовов. Решение - разделить документацию на модули (skills), которые подгружаются только при релевантном запросе. Основной модуль - общие правила, задачи. Отдельный модуль - воронка сделок, каскадная логика. AI загружает в контекст только то, что нужно для конкретного запроса.

Кому это подходит

Если у вас есть внутренняя система с API, подключить AI к CRM через MCP-сервер реально за 1-2 недели. Неделя на базовый сервер с основными инструментами, неделя на отладку описаний и тестирование. Нужен бэкенд-разработчик, знакомый с TypeScript или Python.

Не подходит, если: у вас коробочная CRM без API, нет IT-команды для поддержки, или система полностью закрытая. MCP-сервер - это код, который нужно писать и поддерживать. Причём поддерживать придётся не столько сам код (он простой), сколько описания инструментов. При изменении бизнес-логики CRM нужно обновлять и описания, иначе AI начнёт ошибаться.

Model Context Protocol активно развивается. За последний год запрос «MCP сервер» в Яндексе вырос на 800%. Anthropic опубликовала открытую спецификацию и SDK на нескольких языках.

Главное, что я понял за три месяца: MCP-сервер меняет не то, что вы делаете в CRM, а то, как вы это делаете. Действия те же - создать задачу, проверить сделку, прочитать обсуждение. Но вместо десятка кликов вы пишете одно предложение. А AI сам разбирается, что нажать и куда зайти. Это не автоматизация ради автоматизации. Это 1,5 часа в день, которые возвращаются на работу, а не на работу в CRM.

3
4 комментария