Яку проблему насправді розв'язує MCP: від N × M інтеграцій до N + M

Запитання за галасом

Команда, яка випускає підтримку MCP (сервер із 16 інструментами плюс клієнт, що під'єднується до інших MCP-серверів), рано чи пізно почує найгостріше заперечення зсередини: якщо MCP просто викликає API і повертає дані, навіщо він узагалі? REST API вже є.

Запитання слушне, і більшість пояснень MCP спотикаються, бо починають із протоколу, а не з проблеми. Тож почнімо з проблеми.

Для якої проблеми існує MCP

Уявіть керівника, який питає ШІ-асистента: які заявки на закупівлю чекають мого погодження? Відповідь є в системі закупівель, і перед нею, найімовірніше, стоїть REST API. Чого ж бракує? Є чотири типові шляхи, і кожен має свою пастку:

1. Скопіювати записи у вікно чату. Спрацює один раз, вручну, і копія одразу почне застарівати.
2. Вбудувати чат-бота просто в застосунок закупівель. Вже краще, але тепер ШІ замкнений у цьому застосунку, а інтеграцію вам підтримувати вічно.
3. Вставити документацію API і сподіватися, що модель обере потрібний ендпоінт. Це може працювати, але легко ламається.
4. Написати окрему інтеграцію для кожного асистента, яким користуються в компанії.

Останній шлях швидко перетворюється на хаос. Компанії з 10 внутрішніми системами і 5 асистентами може знадобитися до 10 × 5 = 50 окремих інтеграцій, і кожна має свій код авторизації, свої дивацтва і свій супровід. MCP створили саме для того, щоб прибрати це множення.

Від N × M до N + M

Замість того щоб пов'язувати кожен ШІ-клієнт із кожною системою, кожна система один раз описує свої можливості через стандартний протокол, а кожен ШІ-клієнт один раз реалізує цей протокол. Без MCP для кожної пари потрібна своя інтеграція:

Without MCP: every pair needs its own integration

System A ──── AI Client 1
System A ──── AI Client 2
System B ──── AI Client 1
System B ──── AI Client 2N × M integrations

З MCP кожну сторону створюють один раз:

With MCP: build once on each side

System A ──┐             ┌── AI Client 1
System B ──┼──── MCP ────┼── AI Client 2
System C ──┘             └── AI Client 3N + M implementations

Для десяти систем і п'яти асистентів кількість реалізацій падає з 50 до 15. Якщо одним рядком: MCP дає асистентові змогу дізнатися, що вміє система, і викликати це за однією спільною домовленістю.

Щоб усе стало на місця, потрібні три ідеї.

1. Усередині MCP-сервера немає жодного ШІ

Це, мабуть, найпоширеніша помилка. Люди уявляють такий ланцюжок:

User → AI → MCP Server → API → AI → Answer

де на іншому боці міркує друга модель. Нічого подібного немає. Сервер — звичайний код, який ніколи не викликає LLM. На практиці все ближче до такого:

User
 ↓
LLM            decides which tool it needs
 ↓
MCP Client     sends the call
 ↓
MCP Server     executes it
 ↓
Your API / business logic
 ↓
Structured data
 ↓
LLM            interprets the result
 ↓
Answer

Сервер — це руки, а модель — мозок.

2. «У нас уже є REST API»

Так, і API ніколи не був тим, чого бракувало. Візьмімо застосунок закупівель із таким ендпоінтом:

GET /api/v1/rtps?view=inbox&page=0

Людина прочитає документацію і зрозуміє. Моделі ж доводиться просто під час роботи з'ясовувати, що означає цей ендпоінт, коли він доречний і які параметри передавати, а сполучного коду, який би їй це пояснив, ніхто не написав.

MCP додає виявлення. Клієнт може запитати сервер, що той уміє, і отримати список можливостей:

list_my_approvals
get_purchase_request
search_suppliers
get_purchase_order
create_rfq

Кожен запис має опис і схему вхідних даних. Перший інструмент доходить до моделі приблизно в такому вигляді:

{
  "name": "list_my_approvals",
  "description": "List purchase requests waiting for the current user's approval.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "page": { "type": "integer", "description": "Zero-based page number" }
    }
  }
}

Поставте поруч GET /api/v1/rtps?view=inbox&page=0 і list_my_approvals. URL називає маршрут, а назва інструмента описує можливість словами, про які модель може міркувати. Цей розрив MCP і закриває.

(Сервери можуть пропонувати ще ресурси й багаторазові промпти, але зазвичай починають з інструментів, і мова тут про них.)

3. Найцікавіше — композиція

Тут MCP стає чимось більшим, ніж обгортка навколо API. Під'єднайте до одного асистента три сервери:

• Сервер моніторингу з get_system_health і get_recent_incidents
• Сервер знань із get_document, search_documents і find_certificate
• Сервер закупівель з інструментами get_purchase_order, get_purchase_request і list_my_approvals

Тепер поставте асистентові складене запитання: перелічи заявки на закупівлю, що очікують, і познач ті, до яких немає підтвердних сертифікатів. Модель викликає інструменти закупівель, запитує в сервера знань сертифікати для кожної заявки, зводить результати й відповідає один раз. Жоден сервер не знає про інші, і це нормально.

Тобто інтеграцію виконує сама модель. Порівняйте з одним роздутим чат-ботом, жорстко прив'язаним до всіх бекендів. Тут нова система з'являється як ще один сервер, а асистент лишається недоторканим.

Модель як шар інтеграції

Традиційна інтеграція має такий вигляд:

System A
   ↕
Integration Layer
   ↕
System B

З агентним ШІ картина стає такою:

               AI Model
             /    |    \
            /     |     \
     MCP Server  MCP Server  MCP Server
          |          |          |
      Procurement  Knowledge  Monitoring

Модель сама вирішує, яка можливість їй потрібна, а це принципово відрізняється від побудови одного шару інтеграції, що розуміє всі системи.

Паралель із LSP

Розробники вже бачили таку схему — у Language Server Protocol. Раніше кожен редактор писав власне автодоповнення, перехід до визначення й підсвічування помилок для кожної мови — той самий клубок N × M. З LSP мова надає ці функції один раз, у вигляді мовного сервера, і їх отримує будь-який редактор, що розмовляє цим протоколом. MCP відкрито запозичує в LSP.

Навряд чи хтось питає, навіщо Java потрібен LSP, якщо в неї є компілятор. Компілятор ніколи не був метою. Так само ваш API описує, що вміє система, а MCP — як ШІ-клієнт дізнається про ці можливості й викликає їх.

Тож порівняння не «REST проти MCP». Це REST унизу і MCP поверх нього для сумісності з ШІ.

Чого MCP не розв'язує

Цю частину галас зазвичай оминає.

Модель не стає розумнішою завдяки MCP. Описи інструментів працюють як промпти, тож недбалий опис дає недбалі виклики.

Безпеку за вас теж ніхто не забезпечить. Опублікувати search_suppliers майже не ризиковано — він лише шукає, а от публікуючи approve_purchase_order, ви віддаєте фінансовий контроль. Закладіть автентифікацію, авторизацію, мінімальні привілеї, журнали аудиту і явне підтвердження перед будь-якою зміною стану.

Пам'ятайте й про те, що все, що повертає інструмент, потрапляє просто в контекст моделі. Отриманий документ може містити інструкції, покликані вплинути на наступний виклик інструмента, тому ставтеся до виводу інструментів як до недовірених вхідних даних. MCP відчиняє двері до можливостей і нічого не каже про те, чи безпечно в них заходити.

Чи потрібен вам MCP узагалі?

Наявність API — хибний критерій. Правильний — чи обирає модель, яку можливість викликати, з ШІ-клієнта, якого ви не контролюєте.

Якщо ні — обійдіться без MCP: звичайні виклики API або function calling у вашому фреймворку простіші. Якщо так — сумісність стає вашою проблемою, і розв'язувати її можна кастомними плагінами, пропрієтарними протоколами та інтеграціями під кожного клієнта або переходом на стандарт. Усе рішення зводиться до цього.

Що показує сервер із 16 інструментами

Коли сервер із 16 інструментами вже є, цікаве не те, що власний ШІ команди може викликати її власний API, — це було можливо й раніше. Цікаве те, що інший ШІ-клієнт може виявити можливості системи, хоча ніхто не писав під нього інтеграцію.

У цьому й виграш. API містить те, що можна зробити; MCP — те, як асистент дізнається про можливе і виконує це. Якщо тримати цю різницю в голові, MCP виглядає вже не модним словом, а звичайною інфраструктурною «сантехнікою».