Bitrix24 MCP Hub позволяет выбрать внешний сервис в агентном чате и обратиться к его инструментам через подключение с заданной областью доступа. Команда сверяет фактический набор вызовов, права аккаунта и результат учебного запроса, прежде чем обсуждать действие с изменением данных. Этот маршрут касается внешних сервисов, а поиск методов REST для кода относится к отдельному серверу документации.
Задача хаба
Bitrix24 MCP Hub подключает внешние сервисы к чату с Агентом BitrixGPT или другим агентом. Набор действий задают подключённый сервис и права аккаунта; команда проверяет их на учебной задаче до допуска к рабочим данным.
Официальная справка Битрикс24 разделяет несколько направлений MCP. Hub нужен, когда сотрудник выбирает внешний сервис прямо в агентном чате и обращается к нему через доступные инструменты. Например, сценарий может запросить сведения у подключённого справочного сервиса. Это отличается от собственного MCP-сервера Битрикс24, который открывает функции портала внешней системе, и от отдельного сервера документации REST для разработчика.
Практическая граница особенно важна при обсуждении CRM. Появление внешнего сервиса в Hub подтверждает его подключение. Доступ к карточкам CRM проверяют отдельно. Встроенные инструменты портала, подключённый внешний сервер и его аккаунт имеют разные правила. Перед задачей владелец процесса записывает, откуда ожидается ответ и какое действие допустимо. В противном случае сотрудник может принять ответ из внешнего каталога за проверенный факт собственной CRM.
| Маршрут | Источник действия | Предмет проверки |
|---|---|---|
| MCP Hub | Внешний подключённый сервис | Его инструменты и права аккаунта |
| Инструменты портала | Сам Битрикс24 | Роль сотрудника в портале |
| MCP документации REST | Справка для разработчика | Метод и параметры будущего кода |
Общий принцип инструментов MCP разобран в отдельном материале. Здесь предмет уже: какие инструменты реально доступны после подключения внешнего сервиса, кто разрешил их применение и как получить подтверждённый результат в чате. Статья о поиске методов Bitrix REST относится к разработке интеграции и отвечает на другой вопрос.
Подключение и область
По руководству MCP Hub настройка внешнего сервиса проводится в компьютерной версии Битрикс24 через чат агента и меню «Подключения». Сотрудник выбирает сервис, вводит запрошенные им данные, определяет область доступности и подтверждает предупреждение о внешнем сервере. При отдельной авторизации он выбирает аккаунт сервиса и видит запрос разрешений. Набор полей зависит от интеграции, поэтому готового универсального шаблона для любого сервера нет.
Владелец портала сначала проверяет, доступен ли Hub в его экземпляре и подходят ли действующие условия подписки. Официальная справка предупреждает о постепенном появлении обновлений и связывает внешние интеграции с отдельной подпиской. Точные тарифы и состав возможностей уточняют в интерфейсе и официальных условиях. После проверки выбирают область подключения: личную, для отдела или более широкую. При учебном сценарии достаточно узкой области, которую согласовал администратор.
В настройках Битрикс24 администратор может ограничить подключение внешних сервисов конкретным сотрудникам или отделам, а также отключить использование подключений. По официальному описанию возможность подключения по умолчанию открыта сотрудникам, поэтому проверку ограничения включают в приёмку. Затем смотрят доступ отдельного пользователя с разрешённой ролью и пользователя вне выбранной области. Статус «подключено» показывает состояние связи, а разрешение на конкретную операцию подтверждается отдельным тестом.
Пароли, токены и клиентские сведения вводят только через предусмотренный интерфейс сервиса по внутреннему регламенту. Значения остаются в штатном интерфейсе сервиса; в статье, журнале проверки и промпте указывают только роль подключения. Владелец подключения фиксирует название сервиса, рабочую роль и лицо, способное отозвать доступ. Если в организации уже есть правила для подключения нейросети к Битрикс24, их используют как основу разделения данных и полномочий.
Инструменты и вызовы
После подключения команда выясняет фактический список инструментов выбранного внешнего сервера. Протокол MCP предусматривает запрос tools/list; технический специалист может проверить его в совместимом клиенте или диагностическом контуре, если такой доступ разрешён. Интерфейс Hub в справке показывает список сервисов и их статусы, поэтому статус подключения нельзя превращать в утверждение о конкретном наборе вызовов. При изменении аккаунта или разрешений перечень сверяют повторно.
- Запишите учебную задачу и ожидаемый источник ответа. Выберите один внешний сервис и согласуйте область доступа.
- Проверьте подключение в чате агента, затем получите доступный перечень инструментов техническим способом, который поддерживает выбранный сервер. Сохраните названия и назначение без секретов.
- Попросите агента выполнить только чтение учебных данных. Сверьте ответ с исходным сервисом и журналом вызова.
- Предложите действие с изменением данных как отдельный сценарий. До запуска запросите ручное подтверждение и проверьте права на стороне внешнего сервера.
- Повторите запрос от роли без разрешения. Зафиксируйте отказ и отсутствие внешней записи.
Справка уточняет особенность чата Агента BitrixGPT: сотрудник выбирает внешний сервис для разговора, а смену делает через «Подключения». Другие агентные чаты могут поддерживать иной набор одновременно выбранных сервисов. Для пилота команда удерживает маршрут простым и записывает, какой сервис был выбран в момент вызова. Это помогает разобрать ответ, когда одинаковое поручение может относиться к разным источникам.
Языковая модель способна объяснить найденные сведения и предложить следующее действие, однако факты сотрудник сверяет с внешним источником. Если полная выгрузка содержит расчёты, их обрабатывает скрипт или парсер; модель получает разрешённую выборку и объясняет исключения. Результат проверки служит основанием для обсуждения допуска.
Хотите проверить права внешних инструментов в чате Bitrix24?
Подтверждение и отказ
Действие во внешнем сервисе отделяют от запроса на поиск. Чтение справочной записи и изменение карточки имеют разные последствия ошибки, поэтому в проектной схеме запись проходит явное решение сотрудника. Перед подтверждением показывают целевой объект, предлагаемые поля и источник сведений. Сервер внешнего сервиса проверяет роль, актуальное состояние объекта и возможность операции. Формулировка в промпте помогает человеку понять намерение, но технические права задают настройки подключения и целевой системы.
Для учебного примера можно выбрать вымышленную организацию в тестовом справочнике. Агенту предлагают найти запись, показать ссылку на источник и подготовить черновик обновления отдельного учебного объекта. Ответственный сверяет сведения, затем утверждает или отклоняет действие. Положительное подтверждение проверяют по факту во внешней системе. Отказ оставляет объект без изменений и записывает причину в журнал испытания.
Отдельно проверяют неподходящую роль, отозванное подключение и подмену инструкции текстом из внешнего ответа. Система должна возвращать контролируемый отказ на операции за пределами прав, выданных сервером. Модель может сформулировать причину для сотрудника, но её объяснение сверяют с техническим ответом. При неопределённом результате инженер запрашивает фактическое состояние объекта до повтора вызова: повтор способен создать лишнюю запись.
Назначьте владельца внешнего подключения и человека, который подтверждает изменение. Запишите разрешённые инструменты, условия отказа, способ отзыва доступа и место журнала. Каждое правило проверьте на учебных данных в конкретном портале.
Внутренние CRM-данные в этом сценарии остаются отдельным контуром. Доступ к CRM регулируют собственные права и инструменты портала; Hub отвечает за внешние подключения. Такое разделение позволяет честно оценить результат подключения и избежать обещания универсальной безопасности.
Пилот и условия
Будущий пилот предлагается на одном внешнем сервисе и синтетических данных. Владелец портала проверяет доступность Hub и область подключения, специалист получает список инструментов, затем сотрудник выполняет разрешённое чтение. После этого команда воспроизводит действие, требующее ручного подтверждения, и запрос от роли без права. Этот порядок описывает критерии предстоящего испытания; проведённый кейс и полученный эффект здесь отсутствуют.
Приёмку подтверждают наблюдаемыми следами: сотрудник с доступом видит сервис, сотрудник без права подключения получает отказ, ответ чтения совпадает с исходным объектом, запись создаётся только после решения сотрудника и проверки сервера. В журнале остаются выбранный сервис, тип операции, статус, подтверждение и ссылка на результат. Если интерфейс портала или набор прав отличаются от описанных в справке, инженер фиксирует расхождение и обновляет план испытания по фактической версии.
Стоимость зависит от условий подписки на внешние интеграции, сервиса назначения, числа подключений и состава проверки. Точные условия уточняют на официальных страницах и в доступном интерфейсе; проектную оценку обсуждают после карты прав и учебного сценария. Предмет оценки включает владельца подключения, область доступа и проверяемый отказ при ошибочном действии.
Для следующего шага подготовьте описание внешнего сервиса, разрешённого чтения, возможной записи и владельца допуска. В разделе об ИИ-агентах для бизнеса можно обсудить маршрут под конкретный процесс и критерии проверки. Это помогает связать агентный чат с реальными правами и обязанностями команды без обещания автоматического решения каждой задачи.