Архитектура MCP: полный технический разбор со схемами

Архитектура MCP — это базовый набор компонентов и правил взаимодействия, благодаря которым работает MCP (Model Context Protocol). MCP — это стандарт с открытым исходным кодом, а архитектура MCP — это инфраструктура, на которой он работает.

Любая архитектура MCP включает три основных компонента и строится вокруг них: хост, клиент и сервер. Коммуникационную модель MCP часто описывают как состоящую из уровня данных и транспортного уровня. Уровень данных — это набор правил форматирования сообщений (запросы MCP отправляются в формате JSON-RPC 2.0). Транспортный уровень доставляет эти сообщения, используя Streaming HTTP для внешних подключений.

Архитектура MCP — это серверная платформа, реализующая Model Context Protocol — открытый стандарт для подключения моделей ИИ к инструментам, ресурсам (например, базам данных) и промптам, расширяющим входной контекст. Все они вместе называются «примитивами». В итоге архитектура MCP позволяет LLM узнавать, какие инструменты доступны, и выполнять рабочие процессы без необходимости регулярно обновлять клиентскую сторону.

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

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

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

В случае инструментов, которые обеспечивают доступ к внешней функциональности, обнаружение заключается в том, что хост выполняет вызов tools/list к серверу MCP, чтобы узнать, какие инструменты доступны. Затем LLM (или в некоторых случаях хост) может прочитать описания доступных инструментов и при необходимости запросить их. Для промптов и ресурсов используется похожий процесс.

Схема компонентов архитектуры MCP: хост, содержащий LLM, оркестратор и клиент, подключается к серверу MCP в два этапа — сначала обнаружение, затем запросы, — а сервер MCP предоставляет инструменты, ресурсы и промпты.

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

Хост-приложение — это центральная платформа оркестрации, которая подключается к LLM. Такие известные инструменты, как Perplexity и Claude Desktop, могут выступать хостами в системе MCP.

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

Клиент — это программный компонент в приложении ИИ. MCP предоставляет клиенту стандартный интерфейс для взаимодействия с внутренними и внешними серверами MCP на основе инструкций хоста или LLM. Его задача — устанавливать подключение, форматировать сообщения JSON-RPC, отправлять запросы и получать ответы.

Термины «хост MCP» и «клиент MCP» иногда используют как взаимозаменяемые. Однако это различие полезно, поскольку хост, такой как Perplexity, может одновременно управлять несколькими клиентами MCP. Сложному рабочему процессу ИИ может потребоваться доступ к десяткам или даже сотням отдельных серверов MCP, и для каждого из них будет использоваться отдельное подключение.

Схема хоста MCP (например, Perplexity), управляющего тремя клиентами MCP, каждый из которых подключен к собственному серверу MCP, например к базе данных, файлам или внешнему API.

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

Серверы MCP могут предоставлять доступ к трем категориям примитивов:

Инструменты: по сути, это внешние программные функции. При традиционном подходе на основе API приложение веб-аналитики может получать данные с помощью отформатированного запроса к внешнему серверу. В архитектуре MCP вся сторонняя функциональность поставщика доступна через одно подключение, а запросы составляются по стандартным правилам форматирования.
Ресурсы: это источники данных, которые предоставляют контекст только для чтения. Хороший пример — схемы баз данных. Сервер MCP открывает хосту доступ к различным источникам информации. Если хост запрашивает данные из базы данных, например с помощью SQL-поиска, сгенерированного LLM, это считается запросом к инструменту.
Промпты: это многоразовые шаблоны промптов, которые помогают LLM выполнять определенные задачи. Пользователь или хост вызывает промпт вместо инструмента, потому что для выполнения задачи нужны готовые инструкции. Часто предустановленные задачи в хост-приложении, например «проверить код» или «проанализировать данные», хранятся в виде промптов, которые пользователь может выбрать.

Также стоит отметить, что MCP и API — не взаимоисключающие технологии. Сервер MCP может предоставлять вызовы API, доступные в ответ на запрос обнаружения. Главное, что поддерживать их должен поставщик MCP, а не клиент.

Уровень данных в архитектуре MCP — это набор правил, определяющих формат запросов, ответов и уведомлений. Стандартный язык сообщений — JSON-RPC.

Любая архитектура MCP следует базовому процессу: (1) инициализация и обнаружение со стороны хоста, (2) ответ сервера MCP и (3) вызов со стороны хоста (иногда решение принимает LLM), причем каждый этап представляет собой отдельное сообщение JSON.

Схема уровня данных MCP: пользователь отправляет промпт хост-приложению, где LLM взаимодействует с клиентом MCP; клиент отправляет запрос серверу MCP (инструменты, ресурсы, промпты) и получает результат, а хост возвращает пользователю ответ.

Рассмотрим, как работает обнаружение инструментов, на двух примерах (они также применимы к ресурсам и промптам):

Обнаружение инструментов до генерации LLM: хост запускает клиент MCP, который отправляет запрос tools/list (список доступных инструментов сервера MCP). LLM изучает его в процессе генерации и определяет, нужен ли определенный инструмент, ресурс или промпт.
Предоставление LLM возможности выполнить поиск: в агентной системе хост добавляет во входной контекст вариант обнаружения, например search-tools, и LLM может при необходимости запросить поиск.

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

Вот как выглядит запрос tools/list к серверу MCP из вымышленного приложения для заметок:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

В этом примере “id”:101 идентифицирует запрос с помощью ID, чтобы клиент мог сопоставлять ответы, а поле “params” содержит дополнительную информацию о клиенте, например имя клиента (notes-app-client) и его возможности.

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

Вот как может выглядеть запрос:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Поле “method” сообщает серверу MCP, что это вызов инструмента, “name” указывает, какой инструмент вызвать, а “arguments” передает необходимые входные данные.

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

В MCP есть два транспортных механизма:

Стандартный ввод/вывод: используется, когда сервер MCP работает в той же локальной среде, что и хост-приложение. Клиент записывает запрос JSON в стандартный ввод сервера. Сервер считывает его, выполняет запрошенную операцию и записывает ответ в стандартный вывод.
Streamable HTTP: когда сервер MCP работает вне хост-приложения, клиент MCP отправляет запросы серверу с помощью HTTP POST. Сервер отвечает либо одним сообщением JSON, либо потоком Server-Sent Events (SSE) — постоянным каналом «прослушивания», который позволяет ему возвращать несколько сообщений с течением времени.

Мультитенантная архитектура MCP — это тип реализации, который может одновременно обслуживать нескольких пользователей (тенантов).

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

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

Как на практике выглядит сквозной запрос MCP? Он проходит восемь основных этапов, в каждом из которых задействован отдельный компонент архитектуры.

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

Вот как на практике выглядит вызов инструмента MCP на уже знакомом примере приложения для заметок, подключенного к сервису управления задачами:

Обнаружение инструментов: приложение для заметок (хост) с помощью своего клиента MCP запрашивает доступные инструменты сервера через запрос tools/list. Сервер возвращает их названия, описания и ожидаемые входные данные, в том числе для инструмента add-task. Это может произойти еще до того, как вы отправите промпт.
Ввод пользователя: вы отправляете запрос приложению для заметок на основе LLM через встроенный чат-бот, например: «Создай в моем календаре задачу проверить мой новый черновик со средним приоритетом».
Обработка моделью: хост отправляет LLM ваш запрос и соответствующие определения инструментов.
Выбор инструмента: LLM генерирует структурированный запрос к инструменту, указывая инструмент и его входные данные: add-task с title: Проверить черновик и priority: Medium. Хост проверяет, разрешено ли это действие, и передает запрос клиенту MCP, который отправляет сообщение JSON-RPC.
Запрос: клиент MCP отправляет своему серверу MCP запрос tools/call.
Выполнение инструмента: сервер MCP вызывает API приложения для управления задачами, чтобы создать новую задачу с указанными названием и приоритетом.
Возврат результата: сервер отправляет результат обратно клиенту MCP, который передает его хосту. Хост добавляет его к информации, передаваемой LLM.
Генерация ответа: LLM использует результат, чтобы сгенерировать ответ для пользователя, например: «Я создал задачу проверить черновик со средним приоритетом».

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

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

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

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

Архитектура MCP имеет следующие потенциальные слабые места:

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

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

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

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

Кроме того, по мере внедрения этих агентных функций потребуются более надежные меры защиты, а по мере того как системы ИИ становятся все масштабнее и сложнее, — масштабируемая архитектура, особенно на транспортном уровне.

Что такое архитектура MCP?

Компоненты архитектуры MCP: хосты, клиенты и серверы

Хост

Клиент

Сервер

Что такое уровень данных в архитектуре MCP?

Что такое транспортный уровень в архитектуре MCP?

Что такое мультитенантная архитектура MCP?

Схема архитектуры MCP: пошаговый разбор

Чем архитектура MCP отличается от традиционной архитектуры на основе API?

Безопасна ли архитектура MCP?

Что ждет архитектуру MCP в будущем?