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

Раздел

MCP-серверы

Сложность

средняя

Обновлено

2026-05-20

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

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, Битрикс24 ИИ и MCP сервера для бизнеса.

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

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

Если действие нельзя объяснить рекрутеру, 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 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.

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

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

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

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

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

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

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

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