Что такое MCP и зачем он бизнесу

Зачем это знать

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

Что такое MCP простыми словами

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

MCP — общий разъём для языковых моделей. Расшифровка простая: Model Context Protocol, протокол передачи контекста модели. Он описывает, как приложение с моделью получает данные из внешней системы и запускает в ней действие.

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

Как это работает

1. Систему заворачивают в сервер. Сервер — небольшая программа-переходник поверх CRM, почты или хранилища документов. Внутри он ходит в обычное API, наружу говорит на протоколе.
2. Сервер объявляет список возможностей. Три типа: данные для чтения, действия для запуска, заготовки запросов. Каждое действие описано словами — что делает, какие поля принимает.
3. Приложение подключает сервер. Список возможностей попадает модели вместе с задачей пользователя. Дальше работает вызов инструментов: модель выбирает подходящее действие и заполняет поля.
4. Действие выполняется на стороне сервера. Модель не ходит в базу сама. Она формулирует запрос, сервер проверяет права и возвращает результат.
5. Результат возвращается в диалог. Модель читает ответ и продолжает работу: уточняет, вызывает следующее действие или отвечает человеку.

Подключений становится меньше, чем пар

Разница видна на арифметике связок. Отдельные интеграции растут произведением: приложения умножаются на системы. Подключения по общему формату растут сложением.

Пример из практики

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

Каждая из систем заворачивается в свой сервер. Помощник получает список действий: найти клиента, прочитать переписку, проверить остаток, достать пункт договора. Модель дёргает их по очереди и собирает ответ.

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

Что это даёт бизнесу

• Интеграции переживают проект. Сервер к CRM не привязан к конкретному помощнику. Смена модели или приложения не отправляет подключения в мусор.
• Второй сценарий дешевле первого. Основные деньги уходят на первое подключение системы. Дальше платят за задачу, а не за доступ к данным.
• Права видно в одном месте. Что именно разрешено читать и менять, описано на стороне сервера. Это проверяется службой безопасности отдельно от текста инструкции для модели.
• Подрядчики сравниваются по составу работ. В смете видно, сколько стоит подключение каждой системы и сколько — сама логика. Прикинуть состав работ для своей задачи помогает подбор решения.

Когда без этого можно обойтись

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

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

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

Что важно проверить

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

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

Третье: журнал. Каждый вызов пишется целиком — какое действие, с какими полями, что вернулось. Без журнала разбор спорного случая упирается в догадки, а доля верных действий не считается вовсе.