MCP-сервер: что это и как дать ИИ доступ к бизнес-системе

MCP-сервер нужен не для того, чтобы дать модели «доступ ко всему», а чтобы представить внешние данные и действия в согласованной форме. Полномочия всё равно задают бизнес-система, сервер и правила конкретного пользователя.

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

Что связывает MCP и чем он отличается от API

MCP — открытый стандарт соединения ИИ-приложений с внешними системами. Он описывает, как клиент и сервер договариваются о доступных возможностях и обмениваются запросами и результатами. MCP не является отдельной моделью, базой данных или универсальным разрешением доступа.

В типовом соединении участвуют четыре стороны:

1. Пользователь ставит задачу в приложении с ИИ-помощником.
2. MCP-клиент внутри приложения поддерживает соединение с MCP-сервером и передаёт ему вызовы.
3. MCP-сервер предоставляет согласованные инструменты или ресурсы и проверяет, можно ли выполнить конкретный запрос.
4. API бизнес-системы читает или меняет данные по собственным правилам доступа.

Допустим, CRM уже позволяет получать заказ по его идентификатору. MCP-сервер может представить эту возможность помощнику как инструмент get_order_status. Но сервер не создаёт отсутствующий метод CRM и не расширяет права технической учётной записи. Если API не возвращает дату доставки или запрещает менять оплату, один лишь MCP это ограничение не отменит.

Разница относится к уровням системы. API определяет, как программа обращается к конкретной бизнес-системе. MCP стандартизирует, как ИИ-приложение видит предоставленные ему инструменты и вызывает их. Между ними остаётся интеграционный код: он преобразует аргументы, обращается к API, фильтрует ответ и возвращает результат клиенту.

Ресурс и инструмент тоже решают разные задачи. Ресурс представляет доступный контекст для чтения, а инструмент выполняет определённую операцию. На практике границу следует закрепить в проекте: название возможности не должно скрывать изменение данных. Например, get_order читается однозначно, а расплывчатый manage_order может объединять слишком разные полномочия.

Какие данные и действия стоит открывать помощнику

Сначала запишите рабочую задачу одним предложением: «Менеджер узнаёт актуальный статус заказа, не открывая служебные и платёжные данные». Затем перечислите минимальные действия, без которых задача не решается.

Для чтения полезно определить:

• какой объект можно искать: заказ, обращение или документ;
• по какому признаку разрешён поиск;
• какие поля возвращает инструмент;
• какие записи доступны этому пользователю;
• что сообщать, если объект не найден или доступ запрещён.

Для изменения требуется отдельное описание:

• какое поле или состояние разрешено менять;
• кто имеет такое право;
• какие исходные значения допустимы;
• нужно ли подтверждение человека;
• как система защищается от повторного вызова;
• что попадает в журнал.

Не стоит открывать целую карточку заказа, если помощнику нужны только order_id, status и updated_at. В ответ не должны случайно попасть стоимость, платёжные реквизиты, внутренний комментарий или данные другого клиента. Ограничение полей снижает последствия ошибочного запроса и упрощает проверку результата.

Чтение и изменение лучше представлять разными инструментами. Тогда сервер может независимо разрешить get_order_status и запретить change_payment_state. Разделение также делает журнал понятнее: видно, пытался ли пользователь получить сведения или изменить запись.

Минимальную матрицу прав можно подготовить до выбора реализации:

Это синтетическая матрица для проектирования, а не описание возможностей определённой CRM. В рабочем проекте названия методов, поля и права сверяют с доступным API и правилами заказчика.

Как устроены подключение и авторизация

Ниже — учебная последовательность по официальной документации MCP версии, опубликованной по адресу с датой 2026-07-28. Это описание стандарта, а не отчёт о выполненном подключении к конкретному клиенту или бизнес-системе.

Сначала клиент устанавливает соединение с выбранным сервером и получает предоставленные сервером возможности. Для проекта важно проверить фактический перечень инструментов, их описания и аргументы: одинаковая поддержка MCP не означает одинаковый набор функций.

Документация различает локальный транспорт STDIO и удалённое подключение по HTTP. Для локального STDIO-сервера возможны учётные данные из окружения или используемой сервером библиотеки. OAuth-поток в документации предназначен для удалённого MCP-сервера с HTTP-транспортом. Поэтому нельзя взять инструкцию для одного варианта и автоматически применить её к другому.

Для защищённого удалённого сервера документированная последовательность выглядит так:

1. Клиент обращается к MCP-серверу.
2. Сервер при необходимости отвечает 401 Unauthorized и указывает метаданные защищённого ресурса.
3. Клиент получает сведения о сервере авторизации и поддерживаемых областях доступа.
4. Клиент использует предварительную регистрацию либо динамическую регистрацию, если её поддерживает сервер авторизации.
5. Пользователь входит в систему и предоставляет запрошенное разрешение.
6. Клиент обращается к MCP-серверу с токеном, а сервер проверяет токен и необходимые права.

Документация связывает этот поток с соглашениями OAuth 2.1 и Authorization Code с PKCE. При этом MCP не навязывает единственного поставщика идентификации. Конкретные адреса, области доступа, способ регистрации клиента и правила проверки токена зависят от выбранной инфраструктуры.

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

Секреты не передают в запросе пользователя, ответе модели или статье. Для рабочего подключения заранее определяют место хранения учётных данных, порядок ротации и отзыва, а также владельца доступа.

Как ограничить риск вызова инструмента

Описание инструмента помогает модели выбрать действие, но не является средством защиты. Даже если клиент показывает помощнику только разрешённые функции, MCP-сервер должен заново проверить каждый вызов.

Проверять пользователя и область данных

Сервер связывает запрос с установленным пользователем или служебной учётной записью. Затем он проверяет предметную область: подразделение, проект, клиента или конкретный заказ. Проверки только идентификатора недостаточно. Пользователь может передать существующий номер чужого заказа.

Если сервер работает через общую техническую учётную запись API, это не повод доверять всем запросам клиента. Интеграционный слой должен наложить более узкие правила и передать в журнал сведения об инициаторе.

Проверять параметры до обращения к API

Сервер принимает только ожидаемые аргументы, проверяет их тип, длину и допустимые значения. Для чтения статуса это может быть один идентификатор заказа. Не следует принимать произвольный фильтр или фрагмент запроса к базе данных, если бизнес-задача этого не требует.

После ответа API сервер формирует новый ограниченный результат. Он не возвращает клиенту весь объект с расчётом на то, что модель сама выберет безопасные поля.

Запрашивать подтверждение для чувствительного действия

Подтверждение должно относиться к понятному действию: какой объект изменится, что произойдёт и кто это подтвердит. Общая кнопка «разрешить агенту работать» не заменяет подтверждение конкретной операции.

Для необратимого или финансово значимого действия безопаснее остановить выполнение до решения человека. Если действие можно подготовить как черновик, помощник сначала показывает итог, а сотрудник решает, выполнять ли его.

Подтверждение нельзя переносить с одного вызова на другой. Изменились объект, параметры или пользователь — нужно новое решение. Сервер также проверяет права после подтверждения: за время ожидания доступ могли отозвать.

Считать ответы инструментов недоверенными

Текст из документа, CRM или другого инструмента может содержать ошибку либо указание обойти правила. Такой ответ служит данными, а не новой инструкцией для расширения полномочий. Клиент и сервер не должны исполнять содержащиеся в нём команды только потому, что они пришли из подключённой системы.

Сервер ограничивает размер и состав ответа, а приложение отделяет данные инструмента от управляющих инструкций. Если результат требует следующего действия, оно проходит обычную проверку прав и параметров.

Вести журнал без секретов

Для разбора полезно сохранять инициатора, название инструмента, идентификатор объекта, время, итог проверки, факт подтверждения и результат вызова. Токены, пароли и лишние персональные данные в журнал не записывают.

Журнал не заменяет запрет. Он помогает восстановить последовательность событий после отказа или спорного действия. Формат, срок хранения и доступ к журналу согласуют с владельцем процесса и требованиями к данным.

Учебный доступ к статусу заказа

Рассмотрим синтетический пример. Он показывает ожидаемое поведение и границы полномочий, но не является результатом клиента Switch On AI или живым тестом CRM.

Условный пользователь — менеджер Анна. Ей доступен заказ ORD-1042 её подразделения. Инструмент чтения возвращает только три поля:

order_id: ORD-1042
status: Передан в доставку
updated_at: 2026-10-03 14:20 UTC

Разрешённый запрос

Анна спрашивает: «Какой статус у заказа ORD-1042?» Клиент предлагает вызвать get_order_status с номером заказа. Сервер проверяет личность Анны, доступ к подразделению и разрешённые поля, затем обращается к API бизнес-системы.

Ожидаемое сообщение пользователю:

Заказ ORD-1042 передан в доставку. Статус обновлён 3 октября 2026 года в 14:20 UTC.

В журнале остаются пользователь, инструмент, номер заказа, время и успешный итог. Платёжные поля и внутренние комментарии в ответ не входят.

Отказ в изменении оплаты

Затем Анна просит: «Отметь этот заказ как оплаченный». Учебному помощнику не выдано разрешение на change_payment_state. Клиент может распознать недоступное действие заранее, но окончательный запрет обеспечивает сервер.

Ожидаемое сообщение:

Я могу прочитать статус заказа, но не имею права менять сведения об оплате. Обратитесь к сотруднику с соответствующими полномочиями.

Сервер не вызывает метод изменения в API. В журнале фиксируется отказ по правам. Пользователю не показывают токен, внутреннюю политику авторизации или техническую трассировку.

Подтверждение отдельного действия

Предположим, в проекте отдельно предусмотрено уведомление клиента о задержке. Анна просит подготовить уведомление по тому же заказу. Помощник показывает получателя, основание и текст, но не отправляет сообщение сразу:

Подготовлено уведомление для контакта, связанного с ORD-1042: «Статус заказа обновлён. Уточните удобное время для связи». Отправить?

Только после явного подтверждения сервер повторно проверяет пользователя, заказ и право на этот тип уведомления. Затем он либо выполняет действие, либо возвращает понятный отказ. Разрешение на уведомление не даёт права менять оплату.

Граница полномочий в этом примере проходит не вокруг всего заказа, а вокруг каждой операции. Чтение трёх полей разрешено. Изменение оплаты запрещено. Отправка уведомления выделена в отдельный инструмент и требует подтверждения. Именно такую разницу следует зафиксировать в требованиях и проверках.

Как выбрать сервер и подключить клиент

Готовый MCP-сервер уместен, если его происхождение известно, необходимые инструменты документированы, а способ подключения соответствует вашей среде. Собственный сервер нужен, когда готового решения нет, его полномочия слишком широки или бизнес-правила требуют отдельной фильтрации полей и действий.

Перед подключением готового сервера проверьте:

• кто выпускает и поддерживает сервер;
• где опубликованы код, пакет или документация;
• какая версия рассматривается;
• какой транспорт поддерживается;
• какие инструменты и ресурсы сервер предоставляет;
• какие данные он получает и куда обращается;
• как хранятся учётные данные;
• какие разрешения просит подключение;
• как остановить сервер и отозвать доступ;
• что и в каком виде попадает в журнал.

Неизвестный сервер нельзя подключать автоматически только из-за подходящего названия. Название инструмента также не доказывает его безопасность: нужно проверить параметры, реализацию и фактические обращения к API.

При собственной интеграции команда проектирует узкий MCP-слой над существующим API. Например, вместо универсального метода работы с заказами сервер предоставляет только get_order_status. Такой вариант требует разработки и сопровождения, зато позволяет явно ограничить поля, область данных и проверки.

Чтобы подключить MCP-сервер к клиенту, определите транспорт и используйте документацию конкретной версии клиента. Для локального варианта обычно требуется конфигурация запуска STDIO-сервера и безопасная передача необходимых учётных данных. Для удалённого HTTP-сервера — адрес подключения и поддерживаемый поток авторизации. Конкретные названия экранов, кнопок и файлов здесь не приводятся: они зависят от выбранного клиента и должны сверяться по его актуальной документации.

После подключения не соглашайтесь с разрешениями вслепую. Сопоставьте каждый доступный инструмент с матрицей бизнес-задачи. Если клиент показывает больше возможностей, чем требуется сотруднику, ограничение нужно исправить на сервере или в конфигурации доступа до работы с реальными данными.

Как проверить подключение и заказать интеграцию

Проверка должна охватывать не только успешное чтение. До запуска подготовьте входные данные, ожидаемое поведение и критерий остановки для каждого сценария.

Минимальный набор проверок:

1. Разрешённое чтение. Пользователь получает только согласованные поля доступного ему заказа.
2. Чужая область данных. Существующий заказ другого подразделения не раскрывается.
3. Запрещённое изменение. Попытка изменить оплату завершается отказом до вызова операции записи.
4. Подтверждаемое действие. Без подтверждения ничего не происходит; после него сервер повторно проверяет право и параметры.
5. Отозванный доступ. Истёкший или отозванный доступ не принимается, даже если клиент сохранил старое соединение.
6. Недоступный сервис. При отказе API пользователь не получает ложное сообщение об успехе; журнал отличает сбой сервиса от запрета по правам.
7. Повторный вызов. Повтор чтения допустим, а повтор изменяющей операции обрабатывается по заранее согласованному правилу и не создаёт незаметное двойное действие.
8. Недоверенный ответ. Текст из подключённой системы не расширяет права и не запускает следующий инструмент без обычной проверки.
9. Состав журнала. Записи позволяют восстановить ход события, но не содержат токены и лишние чувствительные данные.

Для каждого результата полезно сохранить четыре части: входной запрос, ожидаемое решение, фактическое решение и причину расхождения. Один успешный диалог не подтверждает готовность интеграции к эксплуатации.

Если требуется подключить конкретного помощника к CRM, базе документов или другой бизнес-системе, Switch On AI может разработать ИИ-помощника или интеграцию после проверки данных и доступного API. Иногда для фиксированной передачи данных достаточно обычной интеграции; ИИ-агент нужен, когда решение должно выбирать следующий разрешённый инструмент по контексту.

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

Чтобы начать, опишите задачу и используемые системы. Пароли и реальные токены для первичного обращения не нужны.