MCP: стандарт подключения инструментов

MCP (Model Context Protocol) — открытый стандарт, который соединяет LLM-приложения с инструментами и источниками данных: вместо N×M самодельных интеграций — N+M подключений к общему протоколу. Разбираем роли, жизненный цикл, JSON-RPC и риски чужих серверов.

Интуиция: проблема N×M

До стандарта каждое AI-приложение дружило с каждым источником данных отдельно. Чат-ассистент хочет читать файлы — пишем интеграцию. IDE-агент хочет ходить в базу — ещё одну. Появился третий продукт или четвёртый источник — и снова ручная работа: N приложений × M источников = N×M интеграций, каждая со своим форматом описаний тулов, своей авторизацией и своими багами. Количество работы растёт квадратично.

MCP (Model Context Protocol) — открытый стандарт, который Anthropic опубликовала в конце 2024 года, — решает это как USB-C решил проблему зарядок: единый разъём с обеих сторон. Приложение один раз реализует MCP-клиент, источник один раз оборачивается MCP-сервером — и любое приложение работает с любым источником. Вместо N×M интеграций — N+M подключений к общей «шине».

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

Роли в протоколе:

• Хост (host) — приложение с LLM внутри: чат, IDE, ассистент. Внутри хоста живёт MCP-клиент, который держит соединение с сервером.
• MCP-сервер (server) — обёртка над источником возможностей: файловой системой, БД, браузером, Slack. Часто это маленькая программа на сотню строк.

Сервер отдаёт клиенту три вида возможностей:

• Tools — действия («выполнить SQL», «создать issue»); их вызывает сама модель через привычный tool calling.
• Resources — данные для контекста (файл, схема БД); их читает приложение и решает, что показать модели.
• Prompts — готовые шаблоны запросов, которые сервер предлагает пользователю.

Транспорт — JSON-RPC 2.0: сообщения вида {"method": "tools/call", "params": {…}} поверх stdio (сервер запущен локально как процесс) или HTTP/SSE (сервер удалённый). Жизненный цикл соединения:

Сначала рукопожатие (initialize): клиент и сервер сверяют версии протокола и возможности. Потом обнаружение (discovery): клиент запрашивает tools/list и получает описания тулов с JSON-схемами. Дальше — рабочие вызовы tools/call и результаты. Ключевое свойство — динамическое обнаружение: подключил новый сервер — модель узнала о его тулах в рантайме, без перекомпиляции и правок кода приложения.

MCP или «просто tool calling»?

Самый частый вопрос: зачем MCP, если function calling уже есть в API моделей? Ответ — это разные уровни. Tool calling — механика вызова: формат, в котором модель просит выполнить действие, и цикл «вызов → исполнение → результат». MCP — стандарт доставки: откуда приложение берёт список тулов, их схемы и кто их исполняет. Без MCP разработчик хардкодит тулы в своём коде; с MCP приложение получает их от любых подключённых серверов — динамически, через tools/list. Внутри агентного цикла (agent loop) модель разницы не видит: для неё это те же описания инструментов в контексте.

Экосистема выросла быстро: тысячи открытых серверов (GitHub, Postgres, браузеры, поисковики), поддержка в SDK основных провайдеров и в популярных приложениях — от IDE до десктопных ассистентов.

Безопасность: сервер — это чужой код

Установить сторонний MCP-сервер — значит запустить чужой код с реальными полномочиями: доступом к файлам, базам, аккаунтам. Отсюда три класса рисков:

• Риск цепочки поставок (supply chain): вредоносный или скомпрометированный сервер может красть данные или подменять описания тулов.
• Prompt injection через результаты тулов: сервер возвращает текст, который попадает в контекст модели; внедрённая туда инструкция может управлять агентом (подробнее — в теме про guardrails).
• Избыточные полномочия: сервер файловой системы с доступом ко всему диску превращает любую ошибку модели в катастрофу.

Практика: наименьшие привилегии (доступ только к нужной папке/схеме БД), подтверждение опасных действий человеком, доверенные источники серверов и аудит того, что реально уходит по сети.