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

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

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

Какую задачу он решает

Не «дать модели инструменты» — это умели и до него, через описание функций в запросе. Он решает задачу единообразия.

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

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

Полезнее считать его границей доверия

Из «протокол подключения инструментов» не следует, какие серверы подключать. Из другой рамки — следует.

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

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

Развёрнуто эту мысль я разбирал в заметке «MCP удобно рассматривать как границу доверия».

Что протокол не решает

Не решает, что модель сделает. Он описывает, что она может. Набор прав — необходимое условие безопасности, но не достаточное.

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

Не делает описания хорошими. Модель по-прежнему выбирает инструмент по тексту описания, и плохое описание остаётся дефектом — описание инструмента и есть интерфейс.

Когда он не нужен

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

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

Условие несогласия

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

Чего я делать не стал бы

Не стал бы подключать чужой сервер, не посмотрев список его инструментов и их права. «Популярный» — не характеристика безопасности.

Не стал бы давать одному серверу и чтение, и запись, если задача требует только чтения. Разделение здесь стоит одной строки настройки и снимает целый класс последствий.

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

Открытый вопрос

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

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