MCP: объяснение — что он подключает, чего не делает и где ему место

Протокол контекста модели (MCP) — это открытый протокол для подключения ИИ-приложений к внешним возможностям и информации через стандартизированные контракты клиент-сервер. Сервер MCP может предоставлять инструменты, ресурсы и подсказки; хост или клиент, совместимый с MCP, обнаруживает и использует эти возможности от имени ИИ-приложения. MCP не требует, чтобы сервер запускал собственную языковую модель, и не заменяет среду выполнения агента, бизнес-авторизацию, изоляцию арендаторов, API приложений или доменную архитектуру, стоящую за предоставляемыми возможностями.

Что на самом деле стандартизирует MCP

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

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

Протокол не стандартизирует всё приложение. Он стандартизирует то, как возможности описываются, обнаруживаются и вызываются через эту границу.

Простейший пример

Предположим, ИИ-приложению для программирования нужен доступ к локальному каталогу проекта. Без MCP приложение могло бы реализовать собственную интеграцию с файловой системой напрямую.

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

Серверу не нужно понимать запрос пользователя на естественном языке. Хост/модель решает, какая возможность полезна; сервер MCP выполняет структурированный запрос в соответствии со своими правилами безопасности.

Где заканчивается простой пример

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

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

Центральная граница такова: MCP стандартизирует семантику интеграции, а не истинность приложения или корректность бизнес-логики.

Архитектура MCP: хост, клиент и сервер

Хост может подключаться к нескольким MCP-серверам, а один MCP-сервер может обслуживать одну или несколько базовых систем. Хост остаётся ответственным за интеграцию результатов MCP в более широкое AI-приложение.

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

Три основных примитива сервера

Инструменты: вызываемые возможности

Инструменты — это структурированные операции, которые MCP-сервер предоставляет хосту. Инструмент имеет имя, описание и входную схему; современные реализации также могут предоставлять структурированный вывод.

Примеры включают поиск по репозиторию, чтение записи клиента, создание тикета, запуск сборки или отправку сообщения. Инструменты могут быть только для чтения или иметь побочные эффекты.

Хорошая поверхность инструментов MCP должна представлять связные цели пользователя или агента, а не механически отражать каждую конечную точку внутреннего API. Операции с разными разрешениями, требованиями к подтверждению или радиусом поражения обычно должны быть отдельными инструментами.

Ресурсы: читаемый контекст и данные

Ресурсы предоставляют данные или контент, которые клиент может перечислить или прочитать. Они естественно подходят, когда семантическая операция — «дай мне этот артефакт или информацию», а не «выполни это действие».

URI ресурса не является предоставлением авторизации. Сервер по-прежнему владеет контролем доступа и должен проверять, какой субъект может читать базовый объект.

Ревизия протокола от 2026-07-28 добавляет семантику кэширования для ответов на список и чтение ресурсов, включая свежесть и область кэша, делая поведение кэширования более явным.

Промпты: многоразовые шаблоны

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

Промпт, предоставленный MCP-сервером, не получает автоматически более высокий приоритет, чем системные или защитные инструкции хоста. Хост решает, как материал промпта входит в его иерархию контекста.

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

Инструмент или ресурс?

Где находится модель ИИ?

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

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

Если сам сервер MCP внутренне вызывает LLM, эта модель является частью реализации сервера за границей протокола; MCP её не требует.

MCP не заменяет API

Сервер MCP часто оборачивает существующие API или сервисы. REST, GraphQL, SQL, вызовы SDK и внутренние сервисные контракты могут оставаться точно там, где они есть.

MCP добавляет уровень взаимодействия, ориентированный на ИИ. Базовый доменный API может оставаться авторитетным контрактом приложения для обычных детерминированных клиентов.

Поэтому обычная архитектура — сначала API/сервис, затем выбранные возможности, ориентированные на ИИ, — а не «заменить каждый API на MCP».

MCP против вызова функций

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

MCP не создаёт цикл агента

Агенту ИИ нужна среда выполнения, которая может принимать решения, вызывать инструменты, наблюдать результаты, обновлять состояние и продолжать или останавливаться. MCP может предоставить некоторые из инструментов и данных, используемых этим циклом.

Сервер MCP не становится автоматически планировщиком, системой памяти или оркестратором. Эти обязанности обычно остаются в хосте или среде выполнения агента.

Неагентное приложение также может использовать MCP. Один детерминированный вызов инструмента MCP не требует автономного многошагового агента.

MCP против A2A

MCP в первую очередь подключает ИИ-хост или агента к таким возможностям, как инструменты, ресурсы и данные. A2A нацелен на сотрудничество между независимыми агентными системами.

Удалённый агент может внутренне использовать MCP для доступа к базам данных и инструментам, одновременно предоставляя интерфейс A2A другим агентам. Таким образом, протоколы могут быть многоуровневыми, а не взаимозаменяемыми.

Существующая статья о стеке протоколов содержит более широкое сравнение MCP/A2A/UCP/AP2/A2UI; G02 остаётся каноническим определением MCP.

Локальное и удалённое использование MCP имеют разные транспортные реалии

MCP может подключаться к локальным и удалённым серверам. Локальные настольные интеграции обычно используют транспорты на уровне процессов, такие как stdio; удалённые серверы используют транспорт на основе HTTP.

Ревизия от 2026-07-28 делает ядро протокола не имеющим состояния. Запросы несут информацию, необходимую для обработки протокола, вместо того чтобы зависеть от более ранней модели сеанса на уровне протокола.

Текущая ревизия также помещает имена методов и возможностей в HTTP-заголовки, чтобы шлюзы, WAF, ограничители скорости и балансировщики нагрузки могли более естественно маршрутизировать и измерять трафик MCP.

Почему важно учитывать версию MCP

Версия SDK и версия протокола — это также разные вещи. Текущий TypeScript SDK v2 — это стабильная линия для ревизии 2026-07-28, тогда как более старый v1.x остаётся линией поддержки для поведения эпохи 2025 года.

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

Что изменилось в MCP 2026-07-28

Roots, sampling и logging больше не являются направлением для новых реализаций

Выпуск 2026-07-28 помечает roots, sampling и logging как устаревшие возможности протокола с определённым окном совместимости.

Старые руководства могут по-прежнему описывать эти возможности как центральные примитивы. При новой реализации следует опираться на текущую спецификацию, а не слепо копировать старые диаграммы жизненного цикла.

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

Длительная работа — это не то же самое, что обычный вызов инструмента MCP

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

Это подкрепляет полезный принцип проектирования: базовому протоколу не нужно вбирать в себя все аспекты среды выполнения агента.

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

MCP Apps расширяют возможности пользовательского интерфейса, не переопределяя ядро протокола

MCP Apps связывают более насыщенный интерактивный пользовательский интерфейс с инструментами MCP через модель расширений.

Хост по-прежнему контролирует, как этот интерфейс встраивается, изолируется в песочнице и защищается.

Поэтому обмен базовыми возможностями и отрисовка пользовательского интерфейса должны оставаться отдельными архитектурными обязанностями.

Авторизация MCP — это не ваша полная модель авторизации

Удалённому MCP нужны механизмы аутентификации и авторизации на уровне протокола, чтобы клиенты и серверы могли устанавливать доверенный доступ. Текущая спецификация продолжает усиливать поведение, связанное с OAuth/OIDC.

Этот уровень отвечает на вопрос, разрешено ли клиенту подключаться или запрашивать области действия протокола. Он не отвечает автоматически на вопрос, может ли Алиса вернуть заказ 123, может ли агент записывать производственную конфигурацию или может ли арендатор A читать данные арендатора B.

Эти доменные решения относятся к модели авторизации сервера/приложения и должны применяться до вызова базовой операции.

Идентичность может пересекать несколько границ

Запрос MCP может включать клиентское приложение MCP, вошедшего в систему человека, идентичность агента/сессии и учётную запись нижестоящего сервиса.

Серверу нужна явная политика того, от имени какого субъекта выполняется операция. В противном случае мощные учётные данные сервиса могут стать путём для атаки «сбитый с толку заместитель».

Для корпоративного использования корреляция между идентичностью пользователя, идентичностью агента, MCP-соединением и последующей авторизацией так же важна, как и совместимость протоколов.

Изоляция арендаторов остаётся за пределами обнаружения возможностей MCP

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

Область арендатора должна определяться на основе доверенной идентичности или членства и передаваться в базы данных, кэши, векторный поиск, объектное хранилище и нижестоящие API.

Получение контента другого арендатора и просьба к модели не использовать его — это уже нарушение изоляции.

MCP не определяет источник истины

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

Правила источника истины относятся к архитектуре приложения/предметной области. Хост или сервер может закодировать авторитетность через дизайн инструментов, метаданные, политику доступа или валидацию, но сам MCP не делает одну возможность «истинной».

Таким образом, инструмент может быть полностью вызываемым через MCP и при этом возвращать устаревшую, второстепенную или неавторитетную информацию.

MCP и контекстная инженерия

MCP может увеличить возможности и информацию, доступные ИИ-приложению, но контекстная инженерия по-прежнему определяет, что доходит до модели.

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

Поэтому доступность возможностей и видимый модели контекст следует рассматривать как отдельные слои.

Проектируйте инструменты MCP вокруг результатов и границ риска

Одобрения относятся к архитектуре исполнения

Хост может требовать одобрения пользователя перед вызовом выбранных инструментов MCP. Текущая интеграция MCP от OpenAI поддерживает автоматический режим исполнения или режим с явным одобрением.

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

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

Наблюдаемость MCP должна связывать вызовы протокола с действиями в предметной области

Трассировка MCP наиболее полезна, когда ее можно сопоставить с вызовом приложения, изменением базы данных или бизнес-транзакцией.

Экосистема 2026-07-28 стандартизирует соглашения о распространении W3C Trace Context, что упрощает отслеживание запроса через хост, клиент, сервер и нижестоящие сервисы.

Одних логов протокола недостаточно для значимых операций. Аудиторские доказательства должны также фиксировать соответствующего субъекта, арендатора, целевой ресурс, одобрение и результирующее изменение состояния.

Что MCP не может исправить

Доказательства оригинальной реализации: Aaasaasa AI Client

Приложение может запускать аутентифицированную конечную точку Streamable HTTP MCP на loopback. Конечная точка предоставляет только каталоги, выбранные через центральный брокер разрешений рабочей области.

Локальная конечная точка и удаленный маршрут — это отдельные вопросы: локальный коннектор может привязываться только к loopback, в то время как Secure MCP Tunnel может сделать одобренный сервис MCP доступным для разрешенного внешнего AI-клиента, не открывая всю локальную машину.

Центральная модель разрешений различает профили только для чата, только для чтения, записи в проект и пользовательских каталогов. Direct Chat не имеет доступа к файловой системе или оболочке; среды выполнения агентов с поддержкой инструментов используют выбранный профиль разрешений.

Это прямая реализация границы G02: MCP обеспечивает стандартизированное подключение возможностей, в то время как принадлежащий приложению брокер разрешений решает, какие каталоги сервер может предоставлять.

Когда MCP хорошо подходит

Когда MCP не нужен

Не добавляйте MCP только потому, что приложение использует ИИ. Если ваш бэкенд уже вызывает один внутренний API и никакому независимому MCP-клиенту эта возможность не нужна, обычный вызов функции или сервиса может оказаться понятнее.

MCP приносит пользу на границе совместимости. Без такой границы протокол может превратиться в ненужный слой адаптера.

Архитектурный вопрос не в том, «есть ли в этом проекте ИИ?», а в том, «получают ли независимо развивающиеся ИИ-хосты и поставщики возможностей выгоду от стандартного контракта?»

Контрольный список безопасности MCP

Распространённые заблуждения

Практическая последовательность проектирования MCP

Контрольный список архитектуры MCP

Краевые случаи и ограничения

Локальный stdio MCP-сервер может иметь небольшую сетевую доступность, но всё равно быть опасным, если сам процесс обладает чрезмерными правами доступа к файловой системе или оболочке.

Удалённый MCP-сервер может предоставлять только публичную документацию или особо чувствительные корпоративные действия. «Удалённый MCP» мало говорит о риске без контекста возможностей и авторизации.

Некоторые серверы могут использовать только инструменты и игнорировать ресурсы/подсказки. Совместимость с MCP не требует, чтобы каждый необязательный примитив был одинаково важен.

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

MCP продолжает быстро развиваться. Расширения, шаблоны авторизации, API SDK и соглашения экосистемы могут меняться быстрее, чем основное архитектурное различие.

Что могло бы изменить этот ответ?

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

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

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

Связанные канонические знания

MCP находится ниже уровня Agentic AI: сначала поймите границу агента/среды выполнения/инструмента, затем используйте MCP, когда внешним возможностям нужен переносимый протокольный контракт.

MCP также зависит от RBAC и изоляции арендаторов, поскольку предоставление возможностей на уровне протокола не определяет авторизацию приложения.

Более широкая статья о стеке протоколов объясняет, где MCP находится рядом с A2A, UCP, AP2 и A2UI. G02 остаётся каноническим источником для самого MCP.

Часто задаваемые вопросы

Глоссарий

Заключение

MCP проще всего понять, когда его граница остаётся узкой: он соединяет AI-приложения с внешними возможностями через стандартный протокол.

Модель не обязана находиться на MCP-сервере. Сервер не становится средой выполнения агента. Перечисленный инструмент не становится авторизованным бизнес-действием. И MCP не заменяет базовый API, источник истины, изоляцию арендаторов или доменную архитектуру.

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

Первичные источники и текущая документация

MCP быстро развивается, поэтому утверждения, чувствительные к версии, в этой статье привязаны к состоянию на 8 октября 2026 года. Раздел Aaasaasa AI Client является оригинальным доказательством реализации и явно ограничен проверенным MCP-коннектором и областью брокера разрешений.