Model Context Protocol: как ИИ подключают к вашим данным

В ноябре 2024 года Anthropic выложила в открытый доступ спецификацию Model Context Protocol — протокола, который описывает, как языковая модель обращается к внешним данным и инструментам. К весне 2025 года собственные MCP-серверы или их поддержку заявили OpenAI, Google DeepMind и десятки инструментов вроде Cursor, Zed и Windsurf. Если раньше каждая интеграция «модель плюс база данных» или «модель плюс Slack» писалась вручную под конкретный продукт, MCP предлагает один общий разъём вместо зоопарка переходников.

Зачем вообще понадобился отдельный протокол

Языковая модель сама по себе знает только то, что попало в обучающую выборку. Она не видит вашу базу заказов, не читает переписку в корпоративном мессенджере и не знает, что лежит в файле на диске. Чтобы дать ей доступ, разработчики годами писали кастомные интеграции: свой коннектор к Postgres, свой — к GitHub, свой — к Google Drive. Каждый под свой формат вызова функций конкретной модели.

Проблема в комбинаторике. Если у вас M моделей и N источников данных, без стандарта вам нужно M × N интеграций. MCP превращает это в M + N: модель умеет говорить на языке протокола, источник умеет отвечать на этом же языке, и они стыкуются без переписывания.

MCP для ИИ-приложений — примерно то же, чем стал USB-C для периферии: не новая функция, а согласие всех сторон использовать один разъём вместо десятка.

Три роли в схеме

Протокол описывает общение между тремя участниками. Разобраться в них — половина понимания MCP.

• Host — приложение, в котором живёт модель: десктопный клиент Claude, IDE вроде Cursor, ваш собственный чат-бот. Host запускает модель и управляет соединениями.
• Client — компонент внутри host, который держит одно соединение с одним сервером. Клиентов может быть несколько, по одному на каждый подключённый сервер.
• Server — отдельная программа, которая выставляет наружу конкретные возможности: доступ к файловой системе, запросы к базе, вызов API погоды. Сервер не знает, какая модель к нему обращается, и его можно переиспользовать между разными host.

Ключевая мысль: сервер пишется один раз и подходит любому клиенту, поддерживающему MCP. Написали MCP-сервер для своей CRM — и он одинаково работает и в Claude Desktop, и в вашем внутреннем боте.

Что сервер умеет отдавать

Спецификация выделяет три основных типа примитивов, которые сервер предоставляет клиенту:

• Tools — действия, которые модель может вызвать: «создай задачу в трекере», «выполни SQL-запрос», «отправь письмо». Их инициирует модель.
• Resources — данные для чтения: содержимое файла, запись из базы, страница документации. Это контекст, а не действие.
• Prompts — заготовленные шаблоны запросов, которые сервер предлагает пользователю как готовые сценарии.

Есть и обратное направление — sampling*, когда сервер сам просит модель что-то сгенерировать. Но большинство практических интеграций строится на tools и resources.

Как это выглядит в работе

Под капотом MCP использует формат сообщений JSON-RPC 2.0. Транспортов два: стандартный ввод-вывод (stdio), когда сервер запущен локально как дочерний процесс, и HTTP с потоковой передачей — для удалённых серверов. Диалог упрощённо выглядит так:

1. Host запускает сервер и через клиента устанавливает соединение, обмениваясь версиями протокола и списком поддерживаемых возможностей.
2. Клиент запрашивает у сервера список доступных tools и resources.
3. Модель, получив запрос пользователя, решает вызвать нужный tool — клиент передаёт вызов серверу.
4. Сервер выполняет действие (например, лезет в базу) и возвращает результат.
5. Модель встраивает результат в ответ пользователю.

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

MCP против function calling: не замена, а слой выше

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

По сути MCP использует механику function calling внутри себя, но добавляет над ней общий язык обнаружения и подключения. Одно не отменяет другое.

Где подвох

Открытый стандарт не значит беспроблемный. Три момента, о которых стоит подумать до внедрения:

• Безопасность. MCP-сервер получает доступ к вашим данным и действиям. Сторонний сервер из непроверенного источника — это программа с правами читать файлы или дёргать API. Исследователи уже описывали атаки через подмену описаний инструментов (tool poisoning), когда вредоносное описание меняет поведение модели. Запускайте только те серверы, которым доверяете.
• Зрелость. Спецификация активно меняется: транспорт, авторизация и модель разрешений дорабатывались уже после первого релиза. То, что работало полгода назад, может требовать обновления.
• Не любую задачу это упрощает. Для единственной интеграции внутри одного приложения function calling напрямую нередко проще, чем поднимать отдельный сервер.

Кому это уже полезно

Если вы разрабатываете ИИ-агента, который должен работать с несколькими системами, MCP экономит время на интеграциях и делает их переносимыми между моделями. Если вы вендор SaaS-продукта, официальный MCP-сервер к вашему API — способ автоматически стать доступным во всех host, поддерживающих протокол. А если вы просто пользуетесь готовым клиентом вроде Claude Desktop, подключение MCP-серверов открывает модели доступ к вашим локальным файлам и сервисам без написания кода.

* Sampling — механизм, при котором MCP-сервер отправляет запрос обратно модели через клиента, чтобы получить сгенерированный текст. Позволяет серверу использовать возможности модели, не имея собственного доступа к ней и не зная ключей API.