Архітектура 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: Review the draft і priority: Medium. Хост перевіряє, чи дозволена ця дія, і передає запит клієнту MCP, який надсилає повідомлення JSON-RPC.
Запит: клієнт MCP надсилає запит tools/call до свого сервера MCP.
Виконання інструмента: сервер MCP викликає API застосунку для керування завданнями, щоб створити нове завдання із зазначеними назвою та пріоритетом.
Повернення результату: сервер надсилає результат назад клієнту MCP, який передає його хосту. Хост додає його до інформації, що надається LLM.
Генерація відповіді: LLM використовує результат, щоб згенерувати відповідь для користувача, наприклад: «Завдання переглянути чернетку із середнім пріоритетом створено».

MCP і традиційну архітектуру API часто плутають, але це взаємодоповнювальні технології. MCP був спеціально розроблений для застосунків на основі ШІ. Він усуває значні витрати на обслуговування, пов’язані з реалізацією та керуванням численними жорстко закодованими API-з’єднаннями.

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

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

Безпека MCP є предметом активних дискусій від самої його появи. Хоча загалом цю технологію вважають безпечною, існує низка ризиків безпеки, багато з яких виразніше проявляються в складних реалізаціях архітектури.

Архітектура MCP має такі потенційні слабкі місця:

Ін’єкція промптів: користувач вставляє шкідливий промпт у зовнішні дані, а модель ШІ помилково сприймає його як інструкцію.
Надмірні привілеї доступу: сервери MCP потенційно можуть надавати моделі ШІ доступ до великої кількості інструментів, що може збільшити масштаб можливих проблем із безпекою (радіус ураження).
Випадкові витоки даних: через неправильно налаштовані реалізації конфіденційна інформація, як-от ключі API або облікові дані бази даних, може потрапити до LLM.
Маніпулювання локальною системою: локальні сервери MCP так само вразливі до проблем локальної системи, як-от шкідливих скриптів, як і будь-які інші застосунки, з тією додатковою проблемою, що вони можуть мати шкідливі наслідки для агентних систем ШІ далі в ланцюжку.

Жодна з цих проблем не є нездоланною. Часто для забезпечення безпеки системи достатньо усталених заходів. Такі заходи, як залучення людини до процесу (human in the loop), суворі обмеження щодо конфіденційних даних і захист від атак на сервери, — поширені практики.

MCP довів, що є корисним і популярним відкритим стандартом для розробників. Він усуває багато проблем жорстко закодованих API в застосунках на основі LLM і суттєво зменшує навантаження на розробників, пов’язане з написанням коду.

Надалі базова архітектура хостів і серверів MCP майже напевно залишиться незмінною. Майбутні інновації зосередяться на розширених агентних можливостях у багатокрокових робочих процесах.

Крім того, у міру впровадження цих агентних функцій знадобляться надійніші засоби захисту, а в міру того як системи ШІ ставатимуть масштабнішими та складнішими, — масштабована архітектура, особливо на транспортному рівні.

Що таке архітектура MCP?

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

Хост

Клієнт

Сервер

Що таке рівень даних в архітектурі MCP?

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

Що таке мультитенантна архітектура MCP?

Діаграма архітектури MCP: покроковий розбір

Чим архітектура MCP відрізняється від традиційної архітектури API?

Чи безпечна архітектура MCP?

Що чекає на архітектуру MCP у майбутньому?