MCP для CRM и Bitrix24: tools, approvals и безопасная запись

Раздел

MCP-серверы

Сложность

средняя

Обновлено

2026-05-29

Короткий ответ

MCP для CRM нужен не для того, чтобы дать агенту “админку Bitrix24”, а чтобы открыть маленький набор проверяемых tools: прочитать сделку, найти похожие лиды, получить последние активности, подготовить комментарий, создать черновик задачи после approval. Прямые admin-права опасны: агент может массово менять стадии, писать клиентам, портить воронку и скрывать источник ошибки.

MCP описывает client-server архитектуру, где host подключает один или несколько MCP servers и получает tools/resources/prompts через protocol boundary: Model Context Protocol architecture. В CRM этот boundary должен быть жестким: каждое действие имеет имя, input schema, права, лимит и audit log.

Статья объединяет вопросы о готовом Bitrix24 MCP Server и о собственном ограниченном MCP-сервере. Отличие от общего Битрикс24 ИИ такое: там выбор встроенного или кастомного AI-сценария, здесь сервный контур tools, approvals и журнала.

Важное уточнение по состоянию на 29 мая 2026 года: у Bitrix24 уже есть официальный Bitrix24 MCP Server и инструкция по подключению external AI systems через OAuth или connection token к https://mcp.bitrix24.com/mcp/. Это отдельный готовый путь для подключения внешнего ассистента к Bitrix24. Кастомный MCP-сервер из этой статьи нужен, когда команде требуется более узкий контур CRM/task tools, собственные approvals, audit log, eval и запрет широких write-действий поверх REST API.

Материал продолжает разборы ИИ-агента для Bitrix24, Битрикс24 ИИ и MCP сервера для бизнеса.

Что вы сможете спроектировать

К концу статьи у вас будет схема безопасного слоя tools между AI-агентом и CRM/задачами Bitrix24: какие операции оставить только для чтения, где требовать подтверждение человека и что записывать в audit log.

Перед реализацией проверьте границы чтения, записи и ручного подтверждения в Agent preflight.

Почему не прямой API-ключ

У CRM уже есть API и роли. Bitrix24 REST API документирует CRM-раздел с сущностями и методами: Bitrix24 CRM API overview. Но API-ключ или OAuth-токен с широкими правами не должен попадать в LLM-agent runtime. Он должен оставаться на вашем сервере, который проверяет каждую операцию.

Официальный Bitrix24 MCP Server не отменяет эту границу. Встроенный путь удобен, когда достаточно подключить внешний AI-инструмент к Bitrix24 через настройки администратора, OAuth или connection token и работать в рамках пользовательских прав. Кастомный путь нужен, когда нельзя отдавать ассистенту общий набор действий и требуется свой allowlist tools: например, только чтение сделок, черновик внутреннего комментария и предложение задачи после approval.

В документации Bitrix24, актуальной на 29 мая 2026 года, отдельно показаны CRM entities, timeline/activities, automation and tasks relationships, а task API остается отдельным разделом. Поэтому битрикс24 mcp лучше проектировать не как один gateway ко всему порталу, а как набор ограниченных CRM и task tools.

Если действие нельзя объяснить рекрутеру, sales lead или руководителю CRM одной строкой, оно не должно быть отдельным tool в первом релизе.

Набор tools для пилота

MCP server tools specification описывает tools как функции, которые модель может discover и вызвать с input schema: MCP tools specification. Для CRM важно делать tools узкими.

{
  "tools": [
    {
      "name": "crm_get_deal_summary",
      "mode": "read",
      "input": { "deal_id": "required" }
    },
    {
      "name": "crm_find_duplicate_leads",
      "mode": "read",
      "input": { "phone_hash": "required" }
    },
    {
      "name": "crm_draft_internal_comment",
      "mode": "write_after_approval",
      "input": { "deal_id": "required", "comment": "required" }
    }
  ]
}

Начальный набор:

• get_deal_summary - читать только поля пилота;
• list_recent_activities - последние касания с лимитом;
• find_related_deals - поиск дублей по нормализованным ключам;
• draft_internal_comment - черновик без публикации клиенту;
• propose_next_task - предложение задачи, не создание без approval;
• explain_recommendation - почему агент предлагает next step.

Read/write границы

Разделите действия на четыре класса.

Запреты должны жить на сервере, а не только в prompt. Если tool называется crm_update_deal, модель когда-нибудь попробует передать туда stage, price или responsible. Лучше не создавать такой широкий tool.

Правило CRM: AI может предложить изменение, но сервер решает, разрешено ли оно, а человек подтверждает risky write.

Approvals и audit log

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

Минимальный audit event:

event: crm_tool_call
tool: crm_draft_internal_comment
actor_user_id: "u-123"
deal_id: "d-456"
mode: write_after_approval
approval: approved
source_fields:
  - deal.stage
  - activities.last_5
  - lead.source
model_output_hash: "sha256:..."
result: success

Лог нужен для разбора ошибок. Если менеджер пожаловался, что агент предложил странный follow-up, команда должна восстановить поля, prompt version, tool input и принятое решение.

Bitrix24-специфика

Bitrix24 часто используется не только как CRM, но и как задачи, телефония, чаты, документы и автоматизация. Для MCP это значит: не подключайте все сразу. Первый сервер может работать только с CRM-сущностями и задачами, а телефонию или клиентские сообщения оставить вне scope.

Сначала выберите путь: официальный Bitrix24 MCP Server или свой ограниченный MCP/proxy-контур.

Если используете официальный путь, не называйте это своим MCP-сервером для CRM. Это managed integration Bitrix24: полезно для быстрых сценариев с задачами и CRM из внешнего чата, но контроль схем tools, логов качества, preview перед записью и бизнес-ограничений зависит от вашей операционной настройки. Если строите свой сервер, не конкурируйте с официальным endpoint по широте функций; выигрывайте безопасной узостью и проверяемостью.

Практическая граница для первого MCP-сервера: лиды, сделки, контакты, компании, последние активности, stage/source справочники и связанные внутренние задачи. Bitrix24 API связывает tasks с CRM через CRM-поля; для агента это полезно только как controlled action после approval. Автоматическая смена стадии, создание клиентского письма, массовая обработка дублей и изменение суммы сделки остаются вне пилота.

Практический пилот:

Bitrix24 CRM API
  -> service role with scoped permissions
  -> MCP server with narrow tools
  -> agent suggests next step
  -> manager approval
  -> internal comment/task only
  -> audit log

Если в портале нет нормальной CRM-гигиены, MCP не исправит процесс. Он только быстрее покажет пустые источники, просроченные задачи и конфликтующие стадии. Тогда first milestone - clean-up и правила обязательных полей, а не запись AI-комментариев.

Чеклист

• MCP server работает через серверную роль, а не через admin token агента.
• Каждый tool узкий и имеет input schema.
• Нет универсального crm_request.
• Read-only действия отделены от write.
• Write требует approval и показывает preview.
• Смена стадии, скидки, счета и клиентские сообщения запрещены на пилоте.
• Все tool calls пишутся в audit log.
• Права проверяются сервером до вызова Bitrix24 API.
• Есть лимиты по количеству сущностей и времени.
• Ошибочный tool можно отключить без остановки всей CRM.

FAQ

MCP обязателен для Bitrix24-агента?

Нет. Для простого сценария хватит REST API и backend-сервиса. MCP полезен, когда агенту нужен набор tools с явным контрактом и discovery.

Нужна ли отдельная статья про битрикс24 mcp?

Пока нет. Эта статья уже показывает, как безопасно открыть CRM и task tools агенту. Бизнес-сценарии отдельно разобраны в статьях Битрикс24 ИИ и ИИ-агент для Bitrix24.

Можно ли дать агенту право менять стадию сделки?

Не в первом релизе. Смена стадии влияет на отчетность, SLA и работу менеджеров. Начинайте с черновиков и внутренней задачи после approval.

Чем MCP лучше одного backend endpoint?

MCP удобен для агентного приложения: tools имеют schema, description и могут быть discoverable. Но безопасность все равно должна быть на сервере.

Что делать с дублями лидов?

Разрешите read-only поиск дублей и рекомендацию. Объединение карточек, удаление и перенос коммуникаций оставьте человеку.

Как проверить качество?

На 30-50 реальных сделках: корректность summary, полезность next step, доля ручных правок, отсутствие запрещенных действий и полнота audit log.