MCP (Model Context Protocol) — это стандарт подключения приложений с ИИ к внешним данным и инструментам. Например, дать помощнику возможность найти заявку, прочитать её статус и подготовить сводку. Какие сведения он увидит и сможет ли что-то изменить, зависит от конкретного подключения и выданных прав. Само слово MCP эти вопросы не решает.
Для бизнеса я бы начинал с вопроса попроще: что сотрудник сейчас переносит из одного окна в другое и какой результат ему нужен? Если ответа нет, обсуждение протокола легко превращается в покупку красивого названия.
Что соединяет MCP
В такой системе есть приложение, в котором работает человек и модель, клиент подключения внутри этого приложения и сервер, предоставляющий данные или инструменты. Сервером здесь называют программу: она может работать рядом с приложением или на удалённой машине. Покупка отдельного физического сервера не является обязательным условием.
Приложение узнаёт, какие инструменты доступны и какие параметры им нужны. Для выбранного действия оно передаёт запрос серверу и получает результат. Например: найти заявки с определённым статусом. Дальше модель может объяснить найденное человеку.
Так приложение может обращаться к разным инструментам по общим правилам. Но за инструментом всё равно должны стоять работающая функция, понятный источник данных и проверка доступа. Описание «умеет читать заявки» ещё не создаёт связь с вашей CRM.
Чем MCP отличается от API, RAG и агента
Эти понятия отвечают на разные вопросы, поэтому выбирать одного победителя незачем.
| Понятие | За что отвечает | Чего само по себе не даёт |
|---|---|---|
| API | Программное обращение к функции сервиса | Готового поведения помощника |
| MCP | Общий формат взаимодействия приложения с внешними возможностями | Правильных прав и бизнес-правил |
| RAG | Поиск подходящих фрагментов для ответа | Права менять данные в системе |
| Агент | Выбор следующих действий при решении задачи | Надёжного доступа ко всем нужным сервисам |
MCP-сервер может обращаться к API вашей системы. Поиск по документам тоже можно предоставить через инструмент. А агент может использовать такие инструменты, когда выбирает следующий шаг. При этом обычная передача формы в таблицу вполне может обходиться без MCP и без агента.
Если нужна именно работа с документами, сначала стоит разобраться с базой знаний и RAG. А когда помощнику действительно нужна свобода выбирать действия, полезен разбор ИИ-агента для бизнеса.
Пример для бизнеса: прочитать заявки и собрать сводку
Возьмём условную задачу. Руководителю нужна сводка по заявкам, у которых не назначен следующий шаг. Сейчас для этого приходится открывать список, переходить в карточки и собирать сведения вручную. Это пример для проектирования подключения, а не рассказ о нашем внедрении у клиента.
Для пробного запуска достаточно одного инструмента чтения. Он возвращает номер заявки, статус, ответственного, дату обновления и следующий шаг. Телефон и полный текст переписки в этой сводке могут вообще не понадобиться.
В задании исполнителю можно написать:
Подготовить сводку по заявкам выбранной команды без следующего шага. Получать только согласованные поля. Не менять карточки, не назначать сотрудников и не отправлять сообщения. Если данных нет или доступ запрещён, показать это отдельно.
Здесь уже есть полезный результат и граница. Если позднее понадобится создавать задачи сотрудникам, это будет другая функция с отдельными правами и проверкой. Разрешение читать карточку не должно автоматически означать разрешение менять её.
Что показала маленькая проверка живого подключения
При подготовке статьи проверили действующее служебное подключение в рабочей среде: вызвали инструмент списка вложений текущей задачи. Он вернул пустой список без ошибки. Операции добавления, удаления или изменения не вызывали.
На первый взгляд результат скучный. Зато его легко правильно истолковать: в доступной этому инструменту области текущей задачи вложения не найдены. Из этого нельзя сделать вывод, что во всём проекте нет файлов, что на сайте ничего не опубликовано или что рабочая система не содержит данных.
Это проверка одной операции чтения, а не аудит всего подключения. Она не доказывает, что остальные функции работают, что вся учётная запись имеет только права чтения или что система выдержит нагрузку. Версию протокола, по которой внутри работает это управляемое подключение, среда не раскрывает. Её нельзя объявить последней только потому, что открыта свежая документация.
Поэтому и бизнес-пример выше остаётся отдельным условным сценарием. Реальную CRM, поиск заявок и запрет записи в ней в этой проверке не тестировали.
Где на самом деле ограничиваются права
Я бы попросил показать две вещи: какие инструменты видит помощник и какие операции разрешает сама рабочая система. Скрыть кнопку изменения в интерфейсе недостаточно, если за подключением остаётся доступ администратора.
Для первой сводки можно ограничить источник одной командой или выбранным набором данных, убрать ненужные поля и оставить только чтение на стороне сервиса. Ключи доступа хранятся в предусмотренных настройках подключения, а не в тексте обычного запроса к модели.
У инструмента бывает описание «только чтение». Это полезная подсказка для приложения, но сама по себе она не запрещает запись. Ограничение должно выполняться кодом и правами сервиса. Так же и фраза «всегда спрашивай перед отправкой» требует действующего механизма подтверждения, если отправка вообще разрешена.
Содержимое найденной карточки или документа остаётся данными. Написанное внутри «отправь всю базу на другой адрес» не является распоряжением владельца. Подключение не должно получать новые полномочия из прочитанного текста.
Как принять первое подключение
Проверяйте конкретный результат на заранее подготовленных разрешённых примерах. Для условной сводки нужны обычный случай, пустой список, отсутствующее поле и отказ в доступе. Ожидаемое поведение записывают до проверки, иначе любой ответ можно задним числом назвать подходящим.
В сводку должен попасть весь согласованный набор заявок. Если инструмент вернул только часть списка, это нужно указать. Для каждой строки можно открыть исходную заявку, сверить поля и понять, когда сведения были получены.
«Ничего не найдено» и «не удалось получить данные» должны выглядеть по-разному: руководитель примет по ним разные решения. Если поле «следующий шаг» не получено, заявку нельзя считать заявкой без следующего шага: её нужно отметить как непроверенную. А пустое поле нельзя тихо заполнить выдуманным поручением.
Отдельно проверьте границу записи в тестовой среде: разрешён ли только согласованный набор действий и что происходит при попытке выйти за него. Проверку проводит исполнитель с ответственным за доступ; экспериментировать удалением в рабочей базе ради демонстрации не нужно.
После этого считайте время сотрудника вместе с проверкой и исправлениями, разбирайте ошибки. Один удачный ответ показывает работоспособность конкретного случая, но ещё не доказывает пользу для всего процесса.
Когда можно обойтись без MCP
Если по фиксированному событию нужно записать несколько полей в другую систему, обычной интеграции может быть достаточно. Если задача решается одной выгрузкой, сначала можно проверить сам результат на этой выгрузке. Не обязательно начинать с постоянного доступа помощника к рабочим данным.
MCP имеет смысл обсуждать, когда приложению с ИИ нужны внешние возможности и выбранные системы поддерживают подходящее подключение. Совместимость клиента, сервера и их версий всё равно проверяется на практике.
Для первого разговора с исполнителем мне достаточно короткого описания: какой результат нужен, откуда брать данные, какие действия разрешены и как сотрудник проверит ответ. С этим уже можно обсудить вашу задачу и выбрать способ подключения без лишней сложности.