Как подключить AI-агента к CRM через MCP: сценарии и проверка
AI-агенту можно дать доступ к CRM, чтобы он находил сделки, собирал сводки и готовил задачи по запросу сотрудника. Для подключения через MCP нужен сервер, который описывает доступные операции и связывает их с CRM. У готовой платформы такой сервер может быть встроенным; для собственной CRM его можно сделать поверх существующего API.
24 сентября 2026 года Google анонсировал поддержку MCP в API Gateway: шлюз умеет открывать операции REST API как инструменты агента. На 2 октября функция находится в Public Preview. Это один из вариантов подключения, который стоит рассматривать вместе с готовыми CRM-коннекторами и собственным адаптером.
Для руководителя отдела продаж и команды разработки первый вопрос — какие действия поручить агенту и как подтвердить их результат. Начните с одного сценария чтения, например сводки по доступной сотруднику сделке. Затем добавляйте изменения с проверкой прав и подтверждением конкретной операции. Ниже — порядок выбора подключения и приемки такого пилота.
Что MCP добавляет к API вашей CRM
В архитектуре MCP AI-приложение подключается к серверу через MCP-клиент. Сервер предоставляет инструменты: функции с названиями, описаниями и параметрами. Например, get_deal_summary может вернуть краткую карточку сделки, а create_followup_task — поставить задачу менеджеру.
Операции CRM выполняет ее API или отдельный бизнес-сервис за сервером MCP. Там должны сохраняться правила доступа, валидация и ограничения на изменение данных. Схема подключения для собственного проекта выглядит так:
- Сотрудник задает вопрос или просит выполнить действие в AI-приложении.
- Приложение получает список разрешенных инструментов и выбирает подходящий.
- MCP-сервер проверяет запрос и обращается к CRM от имени допустимого пользователя или технической учетной записи.
- CRM проверяет доступ к записи и возвращает результат.
- Агент показывает ответ со ссылкой на карточку либо предлагает конкретное изменение для подтверждения.
Если API CRM пока не документирован, начните с контракта: какие сущности существуют, кто владеет данными, какие ошибки возвращаются и как обрабатываются повторы. Эти решения подробно разобраны в материале про архитектуру CRM и интеграции.
Как выбрать способ подключения
Выбор зависит от текущей CRM, инфраструктуры и состава операций. Перед разработкой проверьте, существует ли официальный сервер для вашей системы и покрывает ли он нужный сценарий.
| Вариант | Когда рассматривать | Что проверить до выбора |
|---|---|---|
| Официальный MCP-сервер CRM | Платформа уже предлагает нужные инструменты | Доступность в аккаунте, права сотрудника, отключение подключения, состав действий |
| Приложение из маркетплейса | Официального сценария недостаточно, подходящий коннектор есть у партнера | Владельца сервиса, место обработки данных, разрешения, журналирование и поддержку |
| Собственный MCP-сервер поверх API | CRM собственная или нужны узкие бизнес-операции | Качество API, авторизацию, тестовый контур, владельца эксплуатации |
| API-шлюз с поддержкой MCP | API уже управляются через шлюз и есть подходящий контракт | Совместимость клиента, ограничения продукта, сетевой доступ и поведение при сбоях |
Для одного ассистента с небольшим набором операций собственный адаптер может быть проще внедрения отдельной платформы управления API. Если шлюз уже используется, проверьте его возможности: повторять в другом сервисе авторизацию и маршрутизацию без необходимости неудобно для сопровождения.
Решение о размещении принимайте по реальному пути данных. Зафиксируйте, где находятся MCP-сервер и CRM, какой поставщик обрабатывает запрос к модели, какие поля получает модель и сколько времени хранится история. Локальный адаптер сам по себе не означает, что данные остаются внутри компании.
Что доступно для Битрикс24 и собственного REST API
По официальной справке Битрикс24, внешний AI-ассистент может обращаться к CRM и другим инструментам через MCP-сервер. Администратор включает разрешение в настройках MCP; действия учитывают права сотрудника. Для подключения предусмотрены OAuth и токен, адрес сервера — https://mcp.bitrix24.tech/mcp/.
В справке отдельно указаны условия доступа: для доменной зоны ru нужна подписка BitrixGPT + Маркетплейс, для других зон — коммерческий тариф. Обновления появляются постепенно. Перед пилотом проверьте условия именно своего аккаунта и поддержку выбранного AI-клиента: наличие адреса сервера еще не подтверждает, что все нужные операции доступны вашей команде.
Для собственного REST API Google предлагает вариант на базе API Gateway. Конфигурация использует OpenAPI 3.x, а шлюз переводит MCP-вызов в HTTP-запрос к backend. На дату проверки Preview не поддерживает ресурсы и промпты MCP, stdio-транспорт, потоковые или долгие вызовы инструментов. Для многошаговой CRM-операции заранее проверьте, укладывается ли она в возможности шлюза и клиента.
Оба примера показывают способы подключения. Приемка вашей интеграции должна проверять конкретные записи, роли и действия, независимо от выбранного продукта.
Какие сценарии поручить агенту в первом пилоте
Выберите задачу, которую сотрудник выполняет регулярно и результат которой можно проверить в CRM. Формулировка «помощник отдела продаж» слишком широка для приемки. «Показать просроченные задачи по моим открытым сделкам» уже задает понятные границы.
| Сценарий | Данные и действия | Проверяемый результат |
|---|---|---|
| Сводка по одной сделке | Чтение стадии, ответственного и последних разрешенных событий | Сведения совпадают с карточкой, закрытые поля отсутствуют |
| Список сделок без следующего шага | Чтение ограниченного списка и связанных задач | У каждой строки есть ID, причина включения и ссылка |
| Подготовка задачи после разговора | Предложение названия, срока и исполнителя | Сотрудник видит параметры до записи, задача создается один раз |
| Черновик письма клиенту | Чтение разрешенного контекста, генерация текста | Письмо доступно для проверки и не отправлено автоматически |
Для пилота достаточно одного или двух сценариев из таблицы. Массовое обновление стадий, рассылку и удаление записей лучше добавлять после проверки узких операций: у них другой масштаб возможной ошибки и другие требования к подтверждению.
Разделяйте текущие данные CRM и знания о процессе. Стадию сделки нужно получать из CRM на момент запроса. Порядок согласования скидки может храниться в регламенте и находиться через RAG. Для такой части используйте чек-лист подготовки базы знаний: версия документа и права на него должны быть известны до ответа.
Как описать инструмент, который агент сможет правильно выбрать
Спецификация MCP предусматривает описание инструмента и схему входных параметров. Клиент получает инструменты через tools/list, вызывает выбранный через tools/call. На уровне проекта важно сделать назначение каждой функции однозначным.
Удобнее проектировать инструменты вокруг пользовательских задач: «получить сводку сделки», «предложить следующую задачу», «добавить внутренний комментарий». Универсальная функция с произвольным адресом API и телом запроса затрудняет и выбор операции, и проверку допустимых действий.
Ниже — пример описания одного инструмента для собственной CRM. Имя и поля условные; это схема контракта, для работы которой потребуется backend-обработчик.
{
"name": "get_deal_summary",
"description": "Get the current stage, owner and next task for one deal accessible to the employee. Use for questions about a specific deal.",
"inputSchema": {
"type": "object",
"properties": {
"deal_id": {
"type": "string",
"minLength": 1,
"description": "CRM deal identifier"
}
},
"required": ["deal_id"],
"additionalProperties": false
}
}В этом варианте модель передает ID сделки. Пользователь, компания и набор прав определяются из проверенного контекста авторизации. Обработчик самостоятельно решает, можно ли читать запись, и возвращает только согласованные поля. Запрос чужого ID должен закончиться отказом без раскрытия содержимого карточки.
К каждому инструменту полезно приложить примеры правильного использования, неоднозначный запрос, допустимый отказ и ожидаемые поля ответа. Если сотрудник просит «покажи сделку Иванова», а найдено несколько карточек, агент должен запросить уточнение до действия.
Как разрешать изменения в CRM
В собственном адаптере удобно отделить подготовку изменения от исполнения. Сначала агент предлагает новую задачу или стадию. Интерфейс показывает запись, текущие и новые значения. После подтверждения сервер повторно проверяет права и состояние карточки и выполняет согласованную операцию.
Например, менеджер разрешил поставить задачу по сделке A. Между предложением и подтверждением карточку передали другому отделу. Обработчик должен проверить новое состояние и при необходимости отказать. Старое подтверждение не должно давать доступ к записи после изменения прав.
Для каждой операции зафиксируйте правила:
- какие поля разрешено менять;
- какие переходы между стадиями допустимы;
- кто может подтвердить действие;
- как долго действует подтверждение;
- как система распознает повтор одного запроса;
- какое состояние показывать при неизвестном результате;
- как отменить изменение, если бизнес-процесс допускает отмену.
Защиту от дублей реализуйте в обработчике. Если задача записана, а ответ потерялся из-за сетевого сбоя, повторный запрос с тем же идентификатором операции должен вернуть прежний результат. Без этого повтор со стороны клиента может поставить вторую задачу.
Токены храните в контуре интеграции и исключайте из текста, который получает модель. Рекомендации MCP по безопасности запрещают слепо принимать токен, выпущенный для другого ресурса, и передавать его дальше без проверки назначения. Схему авторизации между клиентом, MCP-сервером и CRM нужно проектировать явно.
Для более широкого контура с несколькими инструментами пригодится руководство по изоляции AI-агента, правам и аварийной остановке.
Как проверить интеграцию до запуска
Проверяйте действия в тестовой CRM с отдельными пользователями и заранее подготовленными записями. Один администратор не позволит увидеть ошибки разграничения доступа. Нужны хотя бы две роли с разными правами и карточки, доступные только одной из них.
| Тест | Ожидаемый результат |
|---|---|
| Сотрудник запрашивает доступную сделку | Ответ совпадает с CRM и содержит ссылку на запись |
| Сотрудник запрашивает карточку другого отдела | Данные не раскрываются, причина отказа понятна |
| Название подходит нескольким сделкам | Агент просит уточнить карточку |
| В комментарии клиента записана команда изменить права | Комментарий остается данными, запрещенный инструмент не выполняется |
| Сотрудник отклоняет создание задачи | Новая задача не появляется |
| Подтвержденный запрос повторяется после timeout | Создается одна задача, повтор возвращает ее результат |
| Между предложением и подтверждением меняются права | Сервер повторно проверяет доступ и блокирует недопустимое действие |
| CRM недоступна | Агент сообщает о сбое и не выдает старый результат за актуальный |
| Подключение отозвано | Новые обращения к CRM не проходят |
Сохраните для каждого теста входной запрос, роль, исходную карточку, фактический ответ и состояние CRM после выполнения. Причину ошибки так легче отделить от качества текста: неверный выбор инструмента, неправильные параметры, недостаточная проверка доступа или сбой API требуют разных исправлений.
В журнале эксплуатации связывайте пользователя, вызов инструмента, решение проверки прав и ID измененной записи. Ограничьте доступ к журналу и состав сохраняемых полей: полная переписка или карточка клиента не всегда нужна для расследования.
Что подготовить для оценки внедрения
Срок и бюджет зависят от качества API, числа сценариев и требований к эксплуатации. До оценки передайте команде короткое описание:
- Какая CRM используется, где она размещена и есть ли тестовый контур.
- Кто будет работать с агентом и как различаются права сотрудников.
- Какие конкретные операции входят в первый релиз.
- Какие поля можно передавать модели и какие поставщики допустимы.
- Какие действия требуют подтверждения и как обрабатывается повтор.
- Какие примеры запросов, отказов и ошибок входят в приемку.
- Кто отвечает за доступ, журнал, поддержку и отключение интеграции.
Если API уже есть, работу можно начать с проверки выбранного сценария в рамках внедрения ИИ в бизнес-процессы. Если CRM предстоит разработать или существенно изменить, инструменты агента стоит заложить в контракт при проектировании CRM-системы.
После пилота оцените долю правильно выполненных задач, время до проверенного результата, количество ручных исправлений и ошибки доступа. Расширяйте каталог операций по результатам этих проверок. Сам факт подключения MCP еще не показывает, что агент помогает сотрудникам.
FAQ
Можно ли подключить собственную CRM без готового MCP-сервера?
Да, через адаптер к ее API или шлюз с подходящей поддержкой MCP. Если у CRM нет стабильного API, сначала потребуется создать ограниченный интерфейс бизнес-операций и определить его владельца.
Нужно ли обучать модель на всей базе клиентов?
Для получения текущей карточки через инструмент это не требуется. Данные можно запрашивать по разрешенной операции в момент обращения. Состав ответа и передачу полей поставщику модели нужно согласовать отдельно.
Можно ли использовать MCP с Битрикс24?
В официальной справке есть такое подключение. Проверьте доступность в своем аккаунте, условия подписки, разрешение администратора и права сотрудника. Набор операций и способ подключения также зависят от AI-клиента.
Когда достаточно обычной автоматизации без агента?
Если событие всегда приводит к одному заранее известному действию, подойдет робот CRM, webhook или фоновый обработчик. Агент полезен там, где нужно понять запрос сотрудника, выбрать данные и подготовить решение, сохраняя проверку бизнес-правил вне модели.