MCP спустя год: что прижилось, а что осталось на бумаге

Anthropic представила Model Context Protocol (MCP) в конце ноября 2024 года — открытый стандарт, который описывает, как языковая модель подключается к внешним данным и инструментам: файлам, базам, API, локальным приложениям. Идея простая: вместо того чтобы каждый разработчик писал свою обвязку под каждую интеграцию, есть один протокол — как USB-C для подключения моделей к внешнему миру. За прошедший год к MCP публично присоединились OpenAI и Google DeepMind, а Microsoft встроила поддержку в Windows и свои инструменты для разработчиков. Это редкий случай, когда конкуренты согласились на чужой стандарт. Но история MCP — это не только про принятие, но и про грабли, на которые наступили первыми.

Что такое MCP и зачем он вообще понадобился

До MCP связать модель с, скажем, вашей базой данных или таск-трекером означало написать кастомный коннектор. Другая модель — другой коннектор. Другой инструмент — снова с нуля. MCP вводит единый протокол на базе JSON-RPC: есть MCP-сервер, который отдаёт ресурсы и инструменты, и MCP-клиент (чаще всего это агент^* внутри чат-приложения или IDE), который к серверу подключается.

Разработчик пишет один сервер под свой сервис — и его теоретически можно подключить к любому клиенту, поддерживающему протокол. За год появились серверы под GitHub, Slack, Postgres, файловую систему, браузер и сотни других сервисов. Реестры MCP-серверов исчисляются тысячами записей.

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

Что реально прижилось

За год из громкого анонса MCP превратился в рабочий инструмент как минимум в трёх сценариях.

• Локальные интеграции в редакторах кода. Подключение агента к файловой системе, git-репозиторию и терминалу через MCP — это то, что заработало сразу и без боли. Claude Desktop, Cursor и ряд других инструментов используют MCP-серверы для доступа к проекту разработчика.
• Подключение к внутренним корпоративным сервисам. Компании пишут MCP-серверы к своим API и таск-трекерам, чтобы агент внутри рабочего пространства мог читать тикеты и документацию. Здесь MCP выиграл именно за счёт стандарта: не нужно переписывать интеграцию под смену модели.
• Согласие индустрии на общий формат. OpenAI подтвердила поддержку MCP в своих продуктах для разработчиков в 2025 году, Google DeepMind и Microsoft — тоже. Это перевело MCP из статуса «протокол одной компании» в статус фактического отраслевого стандарта.

Что забуксовало

Безопасность оказалась слабым местом

Исследователи в течение 2025 года описали несколько классов уязвимостей MCP-серверов: prompt injection через содержимое ресурсов, подмену описаний инструментов (tool poisoning), избыточные права доступа. Проблема системная: агент доверяет тому, что отдаёт сервер, а сервер может быть чужим и недоверенным. Устанавливая MCP-сервер из открытого реестра, вы фактически даёте стороннему коду доступ к своим данным и инструментам — с теми же рисками, что и любое расширение из непроверенного источника.

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

Хаос в реестрах и дубли

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

Удалённые серверы взлетели позже, чем ждали

Изначально MCP-серверы запускались в основном локально. Вариант с удалёнными серверами и веб-транспортом (через HTTP и Server-Sent Events) появился позже и потребовал доработки авторизации. Именно удалённые серверы нужны для массовых облачных сценариев, и их зрелость отставала от локальных.

MCP и соседние подходы

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

MCP и function calling не столько конкурируют, сколько дополняют друг друга: MCP описывает, как выставить инструмент наружу единообразно, а вызов инструмента моделью — это уже механика конкретного клиента. RAG решает другую задачу и часто соседствует с MCP в одной системе.

Кому это пригодится, а кому нет

Пригодится:

• Разработчикам, которые хотят дать агенту в IDE доступ к репозиторию, файлам и терминалу — здесь MCP работает надёжнее всего.
• Командам, которые строят внутренние ассистенты поверх собственных API и не хотят переписывать интеграции при смене модели.
• Тем, кто делает продукт-платформу и заинтересован в том, чтобы сторонние разработчики писали интеграции по одному стандарту.

Скорее не пригодится или требует осторожности:

• Тем, кому нужна одна-две простые интеграции с публичным API — прямой function calling внутри выбранного вендора может оказаться проще, чем разворачивать MCP-сервер.
• Организациям с жёсткими требованиями к безопасности, пока не выстроен процесс проверки и изоляции сторонних серверов.
• Тем, кто ищет решение задачи поиска по документам — это зона RAG, а не MCP.

^* Агент — программа на базе языковой модели, которая не просто отвечает текстом, а планирует шаги и вызывает внешние инструменты для выполнения задачи.

^** RAG (retrieval-augmented generation) — подход, при котором перед генерацией ответа система находит релевантные документы и добавляет их в контекст модели.