Model Context Protocol (MCP): как устроен «USB-порт» для ИИ-инструментов

Model Context Protocol (MCP) — открытый протокол, который Anthropic публично представила 25 ноября 2024 года как способ соединять ИИ-приложения с внешними данными и инструментами через общий интерфейс. Идея проста: вместо отдельного коннектора под каждый чат, IDE или корпоративную систему появляется единый слой обмена контекстом, инструментами и подсказками.

Ниже — разбор именно этой идеи и её технического устройства, а не новостного шума вокруг экосистемы. Важно только помнить, что стартовый релиз 2024 года и текущая спецификация 2026-07-28 уже заметно различаются, поэтому исторический замысел и современные детали я буду разделять явно.

Контекст: зачем появился Model Context Protocol

В анонсе Anthropic формулировала исходную проблему так: модели стали сильнее, но остаются отрезанными от «мест, где живут данные» — корпоративных репозиториев, бизнес-инструментов, файловых систем и сред разработки. До MCP каждая такая связка обычно требовала своей отдельной интеграции: свой формат описания инструментов, свои правила подключения, свой UX разрешений.

Отсюда и метафора «USB-C для ИИ-приложений», которую используют и Anthropic, и официальная документация MCP. Это удачная метафора на уровне продукта: один общий «порт» вместо россыпи переходников. Но технически MCP шире, чем просто разъём: он задаёт роли участников, структуру сообщений, способы discovery, формат описания инструментов и, в современных ревизиях, транспортные и авторизационные правила.

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

Метод: как работает Model Context Protocol

Участники и слои

В документации MCP архитектура описана через три роли. Host — это приложение, с которым работает пользователь: например, чат, IDE или desktop-клиент. Client — протокольный компонент внутри host, который держит соединение с конкретным сервером. Server — программа или сервис, который отдаёт контекст и возможности наружу.

Документация также разводит два слоя. Data layer задаёт JSON-RPC-обмен, discovery и сами примитивы протокола. Transport layer задаёт, как этот обмен едет по каналу: локально через stdio или по сети через HTTP-варианты, плюс связанные с этим вопросы framing и авторизации.

Базовый обмен строится на JSON-RPC 2.0. Это важно не только как историческая деталь: за счёт JSON-RPC в MCP уже есть привычные понятия request, response, notification и метод-ориентированный стиль вызова.

Три примитива, вокруг которых всё крутится

Серверная сторона MCP строится вокруг трёх основных примитивов. В документации и спецификации они разведены не только по типу данных, но и по тому, кто ими управляет.

Примитив	Кто управляет	Что даёт	Типовые RPC
Tools	Модель, но host может навесить подтверждение и политики	Действия: вызвать API, записать файл, изменить состояние внешней системы	tools/list, tools/call
Resources	Приложение	Контекст для чтения: файлы, схемы БД, документация, календари, знания	resources/list, resources/read
Prompts	Пользователь	Повторно используемые шаблоны и сценарии работы	prompts/list, prompts/get

Эта тройка — главное, что стоит запомнить практику. MCP не просто «даёт модели доступ к тулзам». Он разделяет активные действия, пассивный контекст и пользовательские шаблоны, а значит позволяет строить более явные границы управления.

Как выглядит поток взаимодействия

1. Host-приложение поднимает MCP-client и подключает его к серверу — локальному или удалённому.
2. Client узнаёт, какую версию протокола и какие возможности поддерживает сервер. В старых ревизиях это делалось через initialize/initialized; в текущей ревизии используется самодостаточный запрос и опциональный server/discover.
3. Приложение понимает, поддерживает ли сервер tools, resources, prompts, уведомления и другие возможности.
4. Дальше либо приложение читает ресурсы и передаёт выбранный контекст модели, либо модель просит вызвать инструмент, либо пользователь запускает prompt-шаблон.
5. Сервер возвращает структурированный результат, а host решает, что показать пользователю, что добавить в контекст модели и где потребовать дополнительное согласие.

Здесь принципиален именно последний шаг. MCP задаёт формат обмена, но окончательное решение о доверии, видимости и применении результата остаётся у host-приложения.

Что изменилось между запуском 2024 года и текущей спецификацией

Если вы читали ранние тексты про MCP в конце 2024 года, легко запутаться: современные docs уже описывают другой протокольный центр тяжести. Ниже — сжатое сравнение.

Аспект	Публичный запуск: анонс 25.11.2024 и спецификация 2024-11-05	Текущая ревизия 2026-07-28	Практический смысл
Установка соединения	Обязательный handshake: initialize, затем notifications/initialized; capabilities согласуются на старте сессии	Handshake убран; каждый запрос несёт версию и client capabilities в _meta, а server/discover стал отдельным RPC	Проще масштабировать удалённые серверы и проксировать трафик без sticky sessions
HTTP-модель	В ранних версиях фигурировал HTTP+SSE как основной сетевой вариант поверх сессионной модели	Документация текущего протокола опирается на Streamable HTTP; старый HTTP+SSE явно считается legacy и deprecated	Меньше протокольной «магии», проще обычная веб-инфраструктура
Клиентские возможности	roots и sampling были нормальными частями жизненного цикла	roots, sampling и logging помечены deprecated; для новых реализаций рекомендуют другие механизмы	Старые примеры кода могут вводить в заблуждение при новой реализации
Авторизация	В базовой спецификации 2024-11-05 auth ещё не входила в core; разрешались custom-стратегии	Есть отдельная transport-level authorization specification для HTTP, основанная на OAuth-подходах и discovery-метаданных	Удалённый MCP-сервер теперь проще проектировать как нормальный защищённый веб-ресурс

Результаты: что стандартизует MCP и что он даёт разработчику

Если убрать маркетинговую метафору, результат MCP — не «умнее модель», а более предсказуемая граница интеграции. Разработчик сервера описывает, какие данные и действия он выставляет наружу, а разработчик host-приложения получает унифицированные механизмы discovery, вызова и обработки результатов.

На практике это даёт несколько инженерных выгод.

• Повторное использование интеграции. Один MCP-сервер можно теоретически подключить к разным host-приложениям, если они говорят на совместимой версии протокола.
• Явное разделение ролей. Контекст можно отдавать как resources, действия — как tools, а типовые сценарии — как prompts, не смешивая всё в одну непрозрачную «plugin API».
• Schema-first подход. Для инструментов и многих структур протокол использует JSON Schema, а значит входы и выходы можно валидировать и документировать машинно.
• Версионирование на уровне протокола. В MCP версии оформлены как строковые идентификаторы формата YYYY-MM-DD, а поддержка согласовывается явно, а не «по умолчанию».

Но важно не додумывать лишнего. MCP не обещает, что любой сервер будет одинаково хорошо работать во всех клиентах. Он стандартизует wire protocol и базовые семантики, а не весь пользовательский опыт вокруг них.

Интерпретация

Наш комментарий

Главный вклад MCP — не в том, что он «добавляет tools к LLM». Это и до него делали десятками несовместимых способов. Важнее другое: протокол выносит интеграцию с внешним миром в отдельный стандартизованный слой, который не обязан совпадать ни с конкретным провайдером моделей, ни с одним-единственным клиентским приложением.

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

Но переносимость будет только частичной. Один host может автоматически подмешивать resources в контекст, другой — требовать ручного выбора. Один клиент может агрессивно спрашивать подтверждение перед tools/call, другой — давать больше автономии. Поэтому «написал один сервер — и он одинаково работает везде» стоит воспринимать как направление движения, а не как гарантированный результат.

Ограничения и критика

• MCP не является границей безопасности. Официальная документация по roots прямо уточняет, что это механизм координации, а не enforcement. Если серверу нельзя доверять, один лишь протокол не остановит его: нужны системные права, sandboxing, файловые ограничения и сетевые политики.
• Prompt injection никуда не исчезает. Anthropic в инженерной статье о containment пишет, что внешний контент для агента — это одновременно риск обычной supply-chain-атаки и риск prompt injection. Даже «доверенный» коннектор может принести отравленный README, документ или веб-результат в контекст модели.
• Удалённые и локальные серверы — это разные trust-модели. Локальный сервер можно прочитать, закрепить по версии и аудировать как обычный софт. Удалённый сервер может изменить поведение после того, как вы уже дали ему доступ, поэтому для production-сценариев придётся отдельно проектировать доверие, ревизию и blast radius.
• Версионная миграция — часть работы. Примеры под ревизии 2024-11-05, 2025-11-25 и 2026-07-28 отличаются достаточно сильно, чтобы ломать интуицию. Если вы берёте старый tutorial с initialize или sampling, не предполагается автоматически, что он соответствует текущей спецификации.
• MCP не заменяет retrieval-логику. Документация по resources прямо оставляет приложению выбор: передавать весь ресурс, отбирать релевантные куски, искать по embeddings или делать что-то ещё. То есть протокол даёт доступ к контексту, но не определяет качество этого контекста.
• Даже с auth-спецификацией интероперабельность не бесплатна. В текущем протоколе авторизация для HTTP формализована, но она остаётся optional, transport-specific и требует аккуратного соблюдения OAuth-метаданных, discovery и принципа least privilege.

Вывод

Model Context Protocol полезно понимать не как «ещё одну агентную моду», а как инфраструктурный договор о том, как ИИ-приложения получают контекст и совершают действия во внешнем мире. В историческом виде 2024 года это был способ уйти от хаоса кастомных коннекторов; в текущем виде 2026-07-28 это уже более зрелый, versioned и заметно более веб-ориентированный протокол.

Если вам нужен переносимый интерфейс к данным и инструментам — MCP стоит рассматривать всерьёз. Если вам нужна безопасность, качественный retrieval, policy engine и управляемая автономность агента — поверх MCP всё равно придётся строить отдельную систему.

Источники

• Introducing the Model Context Protocol — исходный анонс Anthropic от 25 ноября 2024 года.
• AI research and products that put safety at the frontier — главная страница Anthropic с датированным featured-упоминанием анонса MCP.
• What is the Model Context Protocol (MCP)? — официальное введение и продуктовая рамка протокола.
• Architecture overview — роли host/client/server, слои протокола и текущий discovery-подход.
• Specification (2024-11-05) — стартовая публичная спецификация с stateful-моделью.
• Lifecycle (2024-11-05) — handshake initialize/initialized и capability negotiation в ранней версии.
• Versioning — текущая логика ревизий MCP и согласования версий.
• The 2026-07-28 Specification — официальный разбор текущей ревизии: stateless core, deprecations, auth hardening.
• Understanding MCP servers — документация по tools, resources, prompts и их ролям.
• Understanding MCP clients — elicitation, advisory nature of roots и статус deprecated для sampling/roots.
• Authorization (2026-07-28) — transport-level auth для HTTP и его OAuth-основание.
• How we contain Claude across products — практические замечания Anthropic о prompt injection, local vs remote trust и blast radius.
• JSON-RPC 2.0 Specification — базовая RPC-спецификация, на которой построен обмен сообщениями MCP.

FAQ

Чем MCP отличается от function calling?

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

Когда выбирать MCP, а когда достаточно обычного REST API?

Если у вас один клиент и жёстко контролируемая интеграция, REST API часто достаточно. MCP имеет смысл, когда вы хотите стандартно публиковать инструменты, ресурсы и prompt-шаблоны для нескольких ИИ-клиентов и не изобретать discovery и capability-слой заново.

MCP заменяет RAG?

Нет. MCP может дать доступ к ресурсам и инструментам retrieval, но не определяет, как именно искать, ранжировать, чанковать и подмешивать контекст. Это отдельный уровень системы.

Безопасен ли MCP сам по себе?

Нет. Протокол помогает стандартизовать подключение, но безопасность зависит от sandboxing, прав доступа, политики подтверждений, inspection tool output и аккуратной авторизации, особенно для remote MCP servers.

Читайте также

• Длинный контекст против RAG: кто побеждает на практике
• GraphRAG: граф знаний вместо плоского поиска — разбор работы Microsoft
• Computer Use от Anthropic: как Claude 3.5 Sonnet управляет экраном
• Test-time compute: почему вычисление во время ответа стало новой осью масштабирования