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

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

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

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

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

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

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

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

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

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

Хост

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

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

Клиент

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

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

Сервер

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

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

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

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

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

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

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

Давайте посмотрим, как работает обнаружение инструментов на двух примерах (они могут применяться к ресурсам или промптам):

• Обнаружение инструментов перед генерацией 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 имеет два транспортных пути:

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

Что такое многопользовательская (multi-tenant) архитектура MCP?

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

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

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

Схема архитектуры MCP: пошаговое руководство

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

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

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

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

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

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

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

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

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

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

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

Ни одна из этих проблем не является непреодолимой. Часто для обеспечения безопасности системы достаточно установленных мер. Такие меры, как участие человека в процессе (human in the loop), обеспечение строгого контроля над конфиденциальными данными и защита от атак на сервер, являются общепринятыми практиками.

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

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

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

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