Когда Anthropic в конце 2024 года представил Model Context Protocol (MCP), реакция сообщества колебалась между «ещё один проприетарный стандарт» и «наконец-то кто-то решил проблему». Спустя несколько месяцев стало ясно: MCP действительно закрывает брешь, которая мешала LLM-агентам работать с реальными данными, а не только с текстом из контекстного окна.
Проблема была известна давно. Любая языковая модель — будь то GPT-4o, Claude 3.5 Sonnet или Llama 3 — отлично генерирует текст, но не может сама прочитать файл, выполнить SQL-запрос или отправить HTTP-запрос без внешней обвязки. Разработчики писали кастомные интеграции для каждого кейса: один плагин для базы данных, другой для Slack, третий для файловой системы. MCP предлагает единый протокол, по которому LLM общается с «серверами инструментов» — и это меняет правила сборки агентов.
Что такое MCP и почему это не очередной плагин
Model Context Protocol — это открытый протокол, который определяет, как LLM-клиент (например, Claude Desktop или любой кастомный агент) запрашивает и использует внешние инструменты и источники данных. Вместо того чтобы вшивать каждый инструмент в код агента, MCP вводит слой серверов: каждый сервер предоставляет набор инструментов, ресурсов и промптов.
Архитектура напоминает Language Server Protocol (LSP) из мира IDE — и это не случайно. Anthropic явно ориентировалась на опыт унификации разработческих инструментов. Клиент (агент) подключается к MCP-серверу, сервер сообщает, какие инструменты доступны, и клиент может вызывать их по мере необходимости.
Ключевое отличие от плагинов OpenAI или инструментов LangChain в том, что MCP не привязан к конкретному провайдеру. Протокол открыт, спецификация доступна на GitHub, и любой может написать свой сервер — для PostgreSQL, для Google Drive, для локальной файловой системы или для Figma.
Что изменилось для разработчиков агентов
До MCP каждый агент был монолитом: разработчик вручную описывал функции, которые модель может вызывать, привязывал их к API, настраивал аутентификацию и обработку ошибок. При смене модели или провайдера интеграции приходилось переписывать.
MCP разделяет логику агента и реализацию инструментов. Теперь можно собрать набор MCP-серверов для типовых задач — работа с базой данных, чтение файлов, поиск в вебе — и подключать их к любому MCP-совместимому клиенту. Это сокращает время разработки типового агента с недель до дней.
Например, агент для анализа логов может использовать MCP-сервер для чтения файлов, сервер для выполнения shell-команд и сервер для отправки результатов в Slack. Каждый сервер разрабатывается и тестируется независимо. Если нужно заменить модель с Claude на GPT-4o, достаточно сменить клиент — серверы остаются теми же.
Практический сценарий: агент для работы с базой данных
Один из самых востребованных кейсов — агент, который может выполнять SQL-запросы по текстовому описанию. Без MCP это требовало написания middleware, экранирования запросов, обработки ошибок и явного указания схемы базы данных.
С MCP разработчик создаёт сервер, который подключается к PostgreSQL и предоставляет инструменты: execute_query, get_schema, list_tables. Агент получает описание этих инструментов через протокол и может вызывать их в диалоге. Пользователь пишет «покажи топ-10 продаж за последний месяц», агент вызывает get_schema, чтобы понять структуру таблиц, затем execute_query с соответствующим SQL.
Важный нюанс: MCP не решает проблему безопасности SQL-инъекций или случайного удаления данных. Протокол лишь передаёт вызовы — ответственность за ограничения лежит на сервере. В продакшене стоит добавлять read-only режим и валидацию запросов на стороне сервера.
Ограничения, о которых молчат в анонсах
MCP решает задачу унификации, но не является серебряной пулей. Первое ограничение — производительность. Каждый вызов инструмента проходит через протокол, что добавляет latency. Для задач, где важна скорость ответа (например, модерация контента в реальном времени), накладные расходы MCP могут быть критичны.
Второе — безопасность. MCP-серверы выполняются на стороне клиента или на удалённом сервере, и протокол не предусматривает встроенной аутентификации или шифрования на уровне транспорта. Разработчику придётся реализовывать это самостоятельно, например, через SSH-туннели или API-ключи.
Третье — экосистема пока мала. На начало 2025 года существует около сотни публичных MCP-серверов, большинство из них экспериментальные. Для корпоративных систем (SAP, Oracle, 1С) готовых серверов нет — их придётся писать с нуля.
Четвёртое — MCP не решает проблему качества модели. Если LLM неправильно выбирает инструмент или формирует некорректный вызов, протокол лишь передаёт ошибку обратно. Агент может бесконечно вызывать неправильные инструменты, пока не исчерпает лимит токенов.
Таблица: сравнение подходов к интеграции инструментов
| Подход | Время разработки | Гибкость | Безопасность | Зависимость от провайдера |
|---|---|---|---|---|
| Кастомные функции (OpenAI) | Высокое | Низкая | Высокая | Полная |
| LangChain инструменты | Среднее | Средняя | Средняя | Частичная |
| MCP (Model Context Protocol) | Низкое | Высокая | Зависит от реализации | Нет |
Что тестировать уже сейчас
Если вы хотите попробовать MCP в деле, вот минимальный набор действий.
Во-первых, установите Claude Desktop — это самый зрелый MCP-клиент на данный момент. В конфигурации можно прописать путь к MCP-серверу, и Claude автоматически подхватит его инструменты.
Во-вторых, попробуйте готовый сервер для работы с файловой системой. Он позволяет модели читать, создавать и редактировать файлы — полезно для генерации кода или документации прямо в проекте.
В-третьих, соберите простой сервер для вашего API. MCP SDK доступен для Python, TypeScript и Java. За час можно написать сервер, который предоставляет модели доступ к трём-четырём эндпоинтам.
В-четвёртых, проверьте, как агент справляется с ошибками. Намеренно верните сервером некорректный ответ и посмотрите, как модель обрабатывает ситуацию. Это покажет, насколько ваша конфигурация готова к реальной эксплуатации.
Выводы
MCP — не революция, а эволюция. Протокол решает конкретную инженерную проблему: как сделать LLM-агентов модульными и переносимыми. Он не исправляет слабости самих моделей и не гарантирует безопасность, но даёт разработчикам единый стандарт, которого давно не хватало.
Пока рано говорить, что MCP станет «USB для AI-агентов», как его иногда называют. Экосистема слишком молода, а production-кейсов мало. Но направление верное: унификация интерфейсов между моделями и инструментами — это то, что превращает агентов из демок в рабочий софт.