MCP сервер отдаёт ИИ-агенту описанные инструменты компании через единый протокол: поиск в базе знаний, чтение карточки CRM или подготовку записи в 1С. Агент выбирает действие, сервер проверяет аргументы и обращается к целевой системе с выданными ему правами. Ценность появляется там, где нужны разные корпоративные источники и понятная граница доступа.
Роль сервера
MCP-сервер публикует инструменты, а MCP-клиент вызывает их по запросу агента; для старта хватит одного безопасного действия чтения.
Запрос «mcp сервер что это» часто смешивает две роли. Сервер описывает доступные операции и принимает вызовы, клиент показывает их модели и передаёт выбранные аргументы. Разницу на стороне клиента разбирает материал про MCP-клиент. Здесь речь о собственной службе компании: какие данные она отдаёт, как ограничивает действие и что возвращает после работы. Сам протокол описан в обзоре MCP для бизнеса.
Допустим, менеджер просит агента найти просроченный счёт. Инструмент CRM принимает идентификатор сделки, читает разрешённые поля и возвращает сумму, дату и ссылку на карточку. Модель формулирует ответ, но источник факта остаётся CRM. Если операция меняет статус сделки, серверу нужен отдельный инструмент и отдельное право. Так бизнес видит, какие сведения ушли в ответ, и сохраняет контроль над изменениями.
Удобно начинать с поисковых операций. Они показывают, насколько точно модель подбирает аргументы и понимает ответ, без риска случайной записи. Успех измеряют долей верных карточек в контрольном наборе запросов, а спорные результаты разбирают по журналу вызовов.
При выборе первой операции полезно спросить пользователей, какой ответ им сейчас приходится искать вручную и где хранится его эталон. Если владельца данных определить трудно, сервер только ускорит распространение противоречивой информации. Такой вопрос лучше решить до разработки интерфейса инструмента.
Контракт инструмента
Имя функции должно сообщать конкретное действие: найти договор по номеру, получить остаток товара, прочитать статус заказа. Описание задаёт входные поля, обязательные значения и формат ответа. Слишком общий инструмент вроде «выполни запрос к базе» оставляет модели чрезмерную свободу. Полезнее дать узкие операции, которые легко проверить и ограничить по ролям.
| Операция | Вход | Граница |
|---|---|---|
| Поиск сделки | Номер или клиент | Только разрешённые карточки |
| Статус заказа | Идентификатор заказа | Без адресов доставки |
| Черновик записи | Поля документа | Подтверждение сотрудника |
Сервер проверяет аргументы до обращения к Битрикс24, amoCRM или внутреннему API. Идентификатор должен иметь ожидаемый формат; список полей задаётся заранее; диапазон дат ограничивается разумным рабочим периодом. Ошибка возвращается структурированным ответом, понятным клиенту и человеку. Секреты и техническую трассировку сохраняйте только в журнале сервера; агенту отдавайте короткое деловое объяснение отказа.
Описание инструментов подробно разобрано в разборе MCP tools. Для собственного сервера составьте карточку каждой операции: кто вызывает, какие поля получает, какой системе доверяет и какие ошибки возможны. Это станет основой приёмки до подключения модели.
Набор обязательных полей согласуют с владельцем целевой системы. Если CRM разрешает искать клиента по фамилии, сервер всё равно может требовать уточнение по телефону или идентификатору. Так одинаковые фамилии реже превращаются в ошибочно выбранную карточку.
Сервер для 1С
Запрос «mcp сервер для 1с» обычно означает доступ агента к справочникам и документам учётной системы. Прямой доступ к таблицам базы здесь лишний. Сначала выделяют бизнес-операции в штатном интерфейсе обмена 1С: поиск контрагента, чтение остатка, получение статуса документа. Сервер MCP превращает эти операции в инструменты с понятным для модели описанием и переводит ответы в компактные поля.
- Выберите сценарий чтения, например поиск документа по номеру и дате; согласуйте список возвращаемых полей с владельцем процесса.
- Создайте техническую учётную запись с минимальными правами, настройте соединение сервера с тестовым контуром 1С.
- Опишите схему аргументов и ошибки; проверьте вызовы с пустым номером, чужой организацией и устаревшим документом.
- Добавьте журнал: инициатор, инструмент, время, результат и идентификатор записи без содержимого закрытых полей.
Если требуется создание документа, модель готовит черновик, а сотрудник подтверждает данные и запускает запись. Правило особенно важно для сумм, реквизитов и складских остатков: языковая модель может правдоподобно заполнить пробелы. Подробный обзор предметной связи есть в материале про MCP и 1С. Для полного маршрута агента с несколькими системами полезна страница про ИИ-агентов под бизнес-процесс.
Проверка контрольных документов покажет, где схема теряет поля или путает организацию. Именно такой разбор определяет следующий инструмент для учётной системы.
Нужен агенту безопасный доступ к вашей 1С?
Права и журнал
Права сервера зависят от бизнес-операции и уровня риска действия. Отдельная техническая учётная запись для чтения и отдельная для записи помогают отделить безопасные ответы от действий с последствиями. Секреты хранятся на сервере, в тексте диалога остаются только деловые данные, нужные для ответа. Администратор периодически сверяет список инструментов с рабочими ролями.
На границе клиента и сервера фиксируют инициатора вызова. Если один агент обслуживает несколько сотрудников, сервер должен учитывать их права: общий ключ с доступом ко всем сделкам разрушает разграничение CRM. Важно также ограничить объём возвращаемого текста. Большая выгрузка карточек ухудшит точность ответа и откроет лишние сведения; точечный запрос по идентификатору даёт проверяемый след.
- Для чтения проверяйте корректность найденной карточки и полноту нужных полей.
- Для записи запрашивайте подтверждение конкретного изменения у сотрудника.
- Для ошибок сохраняйте причину в журнале и короткое сообщение для агента.
Отдельно проверяют инъекции в данных. Комментарий клиента в CRM может содержать команду для модели; сервер считает его данными, без права указывать действие. Человек определяет правила доступа и допустимые изменения, модель помогает выбрать инструмент и подготовить аргументы.
При отзыве доступа сотрудника меняется и доступ к инструментам. Проверьте этот сценарий отдельно: старый диалог агента лишится возможности открыть данные после блокировки учётной записи. Для этого сервер каждый раз получает актуальную роль, без доверия сохранённому разговору.
Проверка запуска
Начните с перечня реальных вопросов сотрудников и соберите контрольный набор: обычные запросы, похожие номера, пустые поля и случаи без права доступа. Прогоните их сначала через сам сервер, затем через MCP-клиент с моделью. Это разделит ошибки интеграции и ошибки выбора инструмента. Сравнивайте ответ с исходной записью; убедительная формулировка агента сама по себе оставляет точность ответа открытой.
Возьмите один частый запрос к CRM или 1С. Опишите поля ответа, владельца права и ожидаемый отказ; после проверки чтения открывайте следующий инструмент.
Сборка сервера своими руками описана в техническом руководстве, а подключение конкретного клиента — в инструкции для Claude. Вариант с Claude через сервис вендора требует прямого доступа; оплата напрямую российскими картами недоступна. Для моделей с открытыми весами возможен запуск на своём или арендованном сервере, если конкретная карточка модели допускает такой сценарий. Сервер инструментов сохраняет ту же схему прав независимо от выбранной модели.
После запуска смотрите долю верных вызовов, количество отказов по правам и время ответа целевой системы. Ошибку исправляют в конкретном слое: описание функции, проверка аргументов, полномочия или данные CRM. Стоимость проекта зависит от числа систем, качества их интерфейсов и требований к безопасности; напишите нам и опишите системы, к которым нужен доступ.