Протокол Model Context Protocol (MCP) был представлен как конкретный стандарт, превращающий большие языковые модели (LLM) в агентов, способных вызывать внешние инструменты в измеримом и безопасном цикле. Определяя единый «разъем» между любым поддерживающим MCP хостом и любым MCP-сервером, протокол позволяет разработчикам заменить разрозненный код предсказуемым и проверяемым рабочим процессом.

Почему LLM нужен протокол

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

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

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

Двухсоставная анатомия MCP-агента

MCP разделяет агента на определение (definition) — шаблон, описывающий возможности агента, — и экземпляр (instance) — конкретное выполнение пользовательского запроса.

Определение агента (шаблон)

  • Цикл хоста (Host loop) — оркестратор, управляющий циклом «запрос-инструмент-чтение-решение».
  • Системный контекст (System context) — роль (persona) и высокоуровневые инструкции, определяющие поведение модели.
  • Набор MCP-серверов (MCP server set) — каталог доступных источников инструментов, к которым может обращаться хост.
  • Политика использования инструментов (Tool policy) — явный список инструментов, разрешенных для данного агента.
  • Выбор LLM (LLM selection) — конкретная модель, которая будет генерировать текстовые рассуждения.
  • Лимиты завершения (Termination limits) — максимальное количество итераций и бюджет токенов для предотвращения бесконечных циклов.
  • Контракт задачи (Task contract) — формальное описание того, какие входные данные принимает агент и в каком формате он возвращает результат.
  • Стратегия контекста (Context strategy) — правила того, как история диалога обрезается или резюмируется, чтобы оставаться в рамках лимитов токенов.

Экземпляр агента (выполняемая задача)

  • Цель (Goal) — запрос пользователя, инициирующий цикл.
  • Рабочий контекст (Working context) — накопленная история, включая результаты предыдущих вызовов инструментов.
  • Учетные данные (Credentials) — токены или наборы разрешений, необходимые для вызова выбранных инструментов.
  • Израсходованный бюджет (Consumed budget) — учет потраченных токенов и выполненных шагов на данный момент.

Эти элементы показывают как то, что агенту разрешено делать, так и то, что он делает в данный момент.

Как MCP меняет процесс разработки

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

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

Эта прозрачность дает два практических преимущества:

  1. Измерение стоимости — разработчики могут сравнивать более дешевую модель с более крупной на одной и той же задаче, точно видя, сколько токенов потребляет каждая итерация.
  2. Аудит безопасности — проверка политики инструментов и учетных данных происходит вне модели, что предотвращает скрытый вызов моделью неавторизованных сервисов.

Что всё еще не определено

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

На что обратить внимание дальше

  • Наборы метрик (Metric suites) — следующая статья в серии обещает чек-лист показателей, которые разработчики должны отслеживать (расход токенов, количество итераций, задержка на каждый инструмент). Эти метрики станут стандартом проверки работоспособности любого агента на базе MCP.

Итог

Model Context Protocol предоставляет LLM-агентам общую, проверяемую структуру, которая отделяет возможности агента от того, что он делает в любой конкретный момент. Превращая непрозрачные вызовы инструментов в прозрачный цикл, MCP делает возможным точное измерение их работы.