Что такое MCP простыми словами и зачем он нужен

Модель сама по себе не читает файлы, не ходит в базу и не отправляет письма. Она получает текст и возвращает текст — в том числе текст, означающий «вызови вот такой инструмент с такими аргументами». Всё остальное делает ваше приложение. Пока инструмент один, это пара десятков строк кода. Когда их десяток, а приложений несколько, начинается комбинаторика: каждый инструмент приходится подключать к каждому клиенту заново. MCP — открытый протокол, который эту комбинаторику убирает: инструмент описывается один раз и работает с любым клиентом, который протокол поддерживает. Разбираем, как это устроено, когда действительно нужно и какие риски приходят вместе с удобством.

Что именно стандартизуется

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

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

Стандартизуется другое — связь между вашим приложением и источниками данных или инструментами. Появляются две роли:

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

Клиент — ваше приложение или агент, который эти возможности подтягивает и передаёт модели их описания.

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

Как модель вообще «вызывает» инструмент

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

Модель не выполняет ничего. Цикл выглядит так:

1. Вы передаёте описания инструментов вместе с запросом: как называется, что делает, какие аргументы принимает.
2. Модель возвращает намерение. Не результат, а структуру вида «нужно вызвать такой-то инструмент с такими аргументами». Это по-прежнему просто текст в оговорённом формате.
3. Ваш код решает, выполнять ли. Здесь и находится единственная точка контроля: можно проверить аргументы, спросить человека, отказать.
4. Вы выполняете и кладёте результат обратно в контекст.
5. Модель продолжает работу, уже видя результат.

Из этой схемы следуют две вещи, которые важнее любых деталей протокола.

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

Второе: описания инструментов — часть промпта. Модель выбирает инструмент по тексту описания, и качество этого текста определяет, попадёт ли она в нужный. Расплывчатое описание даёт неверные вызовы так же надёжно, как расплывчатая инструкция даёт расплывчатый ответ.

Практический чек-лист перед подключением

Шесть вопросов, которые стоит задать про каждый сервер.

Что он читает? Область доступа должна быть минимальной: не «файловая система», а конкретный каталог.

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

Куда он может отправить данные? Инструмент с сетевым доступом превращает любое чтение в потенциальную утечку.

Чей это код? Свой, вендорский или найденный в сети — три разных уровня доверия.

Что он кладёт в контекст? Объём результата влияет на счёт, а содержимое — на поведение модели.

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

В чём выигрыш

Три следствия, ради которых это делается.

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

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

Инструменты переносимы между моделями. Это следствие того, что MCP живёт на стороне приложения: сменив модель, вы не трогаете подключённые инструменты. Заодно это ещё один довод держать идентификатор модели в конфигурации — зачем это нужно при переносе.

Показательно, что поддержка протокола стала обычным пунктом в описании агентских инструментов. Тот же кодинг-агент fx от Vercel Labs выступает MCP-клиентом наравне с прочими механизмами расширения — это уже не отличительная черта, а базовое свойство.

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

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

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

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

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

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

Чем это опасно

Здесь самое важное, и об этом в описаниях протокола говорят реже, чем стоило бы.

Всё, что возвращает инструмент, попадает в контекст модели. А модель не отличает данные от инструкций. Если сервер отдал содержимое веб-страницы, письма или документа, любая формулировка внутри может быть воспринята как указание. Мы разбирали случай, когда инъекцию спрятали в судебном документе белым шрифтом по белому фону — с инструментом, читающим документы, это ровно тот же сценарий.

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

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

Практический минимум: подключать только то, что нужно задаче; давать инструментам минимальные права; не держать в одном контексте чувствительные данные и возможность отправить что-то наружу. Подробный разбор — в своде по правам агента.

Что это значит для расхода

Про деньги, потому что этот эффект недооценивают.

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

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

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

Чего мы не утверждаем

Мы не описываем техническую спецификацию. Статья объясняет назначение и риски; за деталями реализации нужно идти в саму спецификацию протокола.

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

MCP не имеет отношения к нашему API. Мы передаём запросы к моделям; подключение инструментов — слой вашего приложения, и на стороне KeyDealer его нет. Что мы храним из запросов, перечислено в llms.txt.

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

Что держать в голове

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

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

Как мы отделяем проверенное от предполагаемого — на странице о проекте. Отдельный ключ с собственным лимитом под каждого агента: keydealer.ru/login.