Основи MCP: хости, клієнти, сервери та формат передачі даних JSON-RPC
Дізнайтеся, чому існує Model Context Protocol, як хости, клієнти та сервери ділять роботу, як виглядають повідомлення JSON-RPC та чим відрізняються протоколи передачі даних stdio та HTTP.
Джерела: Beyond the Noise: How MCP Unlocks the Real Value of LLMs
Моделі мови стали справді корисними для бізнесу з того моменту, як вони змогли виконувати дії, а не лише відповідати. Справжньою складністю ніколи не була сама модель; проблемою було підключення її до баз даних, API та внутрішніх інструментів, де фактично відбувається робота, причому це підключення мало здійснюватися лише один раз, а не щоразу для кожного додатку чи постачальника моделі. Протокол контексту моделі (MCP) — це спроба стандартизувати таке підключення. У цій статті пояснюється проблема, яку вирішує MCP, ролі його компонентів, що передається через мережу, та в чому полягають відмінності між двома стандартними способами передачі даних, щоб ви могли зрозуміти, яке місце у вашій архітектурі може зайняти сервер MCP.
Де ШММ створюють цінність: виконання дій
Раніше велика кількість автоматизаційних рішень залишалася недосяжною лише через те, що програмне забезпечення не могло інтерпретувати запити з вільною структурою. Моделі мов усувають цю перешкоду, і після підключення до інструментів вони можуть керувати багатоетапними процесами, які раніше вимагали участі людини для перемикання між системами.
Уявіть асистента, якому потрібно знайти та забронювати поїзд від Касабланки до Рабата. Розуміння запиту — це лише перший крок. Асистент мусить знайти інформацію в сервісі розкладу поїздів, обрати час відправлення, скористатися API для бронювання та підтвердити результат. Кожен з цих кроків є викликом інструменту. Коли ці інструменти доступні через сервер MCP, будь-який сумісний агент може виконати весь процес.
Бізнес-обґрунтування є цілком очевидним: менша кількість ручних кроків за завданням означає нижчі операційні витрати та швидший час виконання. Існує також аргумент, пов’язаний з користувацьким досвідом. Співробітники постійно працюють з багатьма панелями керування та інтерфейсами, кожен з яких має власну логіку. Розмовний фронтенд, підключений до цих бекендів, може приховати значну частину цієї складності за одним інтерфейсом.
Проблема інтеграції, яку вирішує MCP
Використання інструментів — це не щось нове. Кожен основний SDK для LLM його підтримує, але кожен робить це за власними правилами щодо оголошення інструменту, опису параметрів та повернення результатів. Практичний наслідок полягає у тому, що один і той самий інструмент реалізується кілька разів — по один раз від кожного постачальника моделей. Зміна моделей або підтримка кількох одночасно означає необхідність перенесення коду інтеграції, що уповільнює роботу команд та ускладнює масштабування продуктів.
Пропуск SDK не вирішує цю проблему повністю. Ви можете створити власний шар інтеграції, який буде відповідати за перетворення інтентів у дії, виклик ендпоїнтів, збір параметрів, обробку помилок та запис аналітики. Це додає складності, але її можна контролювати. Глибша проблема полягає у тому, що такий шар зазвичай існує всередині одного додатку. Коли другому додатку потрібні ті самі інструменти, команда знову створює цей шар з нуля. Логіка інтеграції прив’язана до користувача, а не до системи, яка володіє цими можливостями.
Що таке MCP
MCP — це відкритий стандарт, який надає штучним інтелектуальним додаткам спільний спосіб підключення до джерел даних та інструментів. Він не уможливлює того, що було абсолютно неможливим раніше; він просто робить ці з’єднання простішими та більш послідовними. Документація протоколу на modelcontextprotocol.io є офіційним джерелом інформації.
Ключова зміна полягає у місці розташування логіки інструментів. За допомогою MCP сервіс на боці сервера, такий як база даних, API чи внутрішній інструмент, публікує свої можливості через сервер MCP. Поширеною аналогією є порт USB-C: сервіс надає стандартний роз’єм, до якого може підключитися будь-який сумісний додаток. Додаток для ШІ більше не містить інформації про те, як використовувати кожен інструмент; йому достатньо лише дотримуватися протоколу.
Архітектура: хости, клієнти та сервери
MCP використовує архітектуру клієнт-сервер із трьома ролями, які легко плутати:
- Хост: сам додаток для ШІ, наприклад чат-асистент, IDE з агентом чи ваш власний сервіс агента. Саме з ним взаємодіє користувач, і він підключається до зовнішнього світу через один або кілька серверів MCP.
Хост ніколи не спілкується безпосередньо з сервером. Він створює по одному клієнту на кожен сервер та делегує всю комунікацію йому, причому кожен клієнт підтримує окреме один-до-одного з’єднання. Таке розділення є корисним на практиці: хост, підключений до сервера файлової системи, сервера обробки замовлень та сервера CRM, запускає три незалежні клієнти, тож збої чи обмеження доступу в одному з’єднанні не впливають на інші.
Три базові елементи сервера
Базові елементи визначають, що може надавати кожна зі сторін. Сервер пропонує три основні типи:
- Інструменти: операції, які може виконувати модель, такі як виклик API чи запис даних.
- Ресурси: дані, які модель може читати та використовувати як контекст, наприклад рядки бази даних чи документи.
- Запити: заздалегідь визначені шаблони інструкцій, які керують моделлю; за своєю суттю вони схожі на багаторазово використовувані системні запити.
Розмежування між інструментами та ресурсами має значення для безпеки та проектування. Читання ресурсів не повинно мати побічних ефектів, тоді як використання інструменту може змінити ситуацію, тому хости часто застосовують різні правила схвалення до кожного з них.
JSON та JSON-RPC: формат повідомлень
JSON (JavaScript Object Notation) представляє структуровані дані у вигляді тексту, складеного з пар ключ-значення, масивів та вкладених об’єктів. Оскільки цей формат є простим та підтримується у всьому світі, відправник та отримувач, написані мовами різного типу, можуть домовитися щодо значення повідомлення.
JSON-RPC ґрунтується на цьому, визначаючи фіксовану структуру повідомлень для віддалених викликів процедур. Запит містить назву методу, параметри та ідентифікатор; якщо обидві сторони дотримуються цієї структури, клієнт може попросити сервер виконати метод та отримати результат або повідомлення про помилку у такому ж передбачуваному форматі. Наведений нижче приклад — це запит JSON-RPC 2.0 з проханням до сервера знайти інформацію про погоду в Касабланці. Зверніть увагу на чотири поля: версію протоколу, ідентифікатор id запиту для зіставлення з відповіддю, назву method та об’єкт params.
{
"jsonrpc": "2.0",
"id": 1,
"method": "get_weather",
"params": {
"city": "Casablanca"
}
}
Цей приклад ілюструє простий JSON-RPC. У самому MCP інструменти не викликаються як методи верхнього рівня, названі за іменем інструменту. Натомість клієнт надсилає запит із методом tools/call, вказуючи назву інструменту та його аргументи у полі params. Саме ця непрямість дозволяє MCP визначати фіксований набір методів протоколу, водночас залишаючи серверам свободу для реалізації будь-яких інструментів на їхній розсуд.
Виявлення — це відсутній елемент
JSON-RPC сам по собі залишає одну проблему нерозв’язаною: клієнт мусить вже знати, які методи пропонує сервер. MCP усуває цю прогалину, стандартизуючи спосіб, яким клієнти виявляють можливості. Клієнт може попросити сервер перелічити його інструменти, ресурси та запити, отримати назви, описи та схеми введення даних, а потім передати ці описи моделі. MCP також визначає, як ініціалізується з’єднання та які механізми передачі використовуються для передавання повідомлень.
Механізми передачі: як подорожують повідомлення
JSON-RPC визначає лексикон; механізм передачі визначає, як байти переміщуються між клієнтом та сервером. На момент написання MCP визначає два стандартні механізми передачі. Перед тим, як покладатися на конкретні деталі, перевірте поточну специфікацію, оскільки протокол продовжує розвиватися.
stdio для локальних інструментів
За допомогою транспорту stdio клієнт запускає сервер MCP як дочірній процес. Сервер читає надходячі повідомлення зі свого стандартного вводу та записує відповіді у свій стандартний вивід. Кожен процес отримує ці канали від операційної системи автоматично, тому не потрібні мережеві сокети чи порти.
Це робить stdio ідеальним вибором для інструментів, які працюють на тій самій машині, що й хост, наприклад сервера, який створює папки у локальній файловій системі. Додатковою перевагою є ізоляція: сервер існує лише тоді, коли хост його тримає у робочому стані, і до нього неможливо отримати доступ з мережі.
Streamable HTTP для спільних, віддалених серверів
За допомогою Streamable HTTP сервер є незалежним процесом, який працює як HTTP-сервіс, і може обслуговувати багато клієнтів одночасно. Повідомлення обмінюються за допомогою звичайних HTTP-запитів.
Цей спосіб передачі даних дозволяє використовувати стрімінг. Замість очікування повної відповіді сервер може надсилати дані поступово, що є корисним для тривалих викликів інструментів. Стрімінг досягається за допомогою Server-Sent Events (SSE) — однонапрямкового каналу, у якому одна довготривала відповідь HTTP містить послідовність подій, надсиланих сервером. Трафік у зворотному напрямку все одно надсилається у вигляді звичайних запитів HTTP від клієнта. Детальна поведінка залежить від реалізації та версії HTTP, яка використовується.
Практичне правило: обирайте stdio, коли інструмент знаходиться на комп’ютері одного користувача, а обирайте Streamable HTTP, коли необхідно поділитися функціоналом між користувачами чи командами, забезпечивши автентифікацію та мережевий контроль, які потрібні для спільних сервісів.
Чому протокол важливіший за інше SDK
Протоколи існують для того, щоб системи, створені різними командами, мовою програмування та за різними графіками випуску, все одно могли ефективно взаємодіяти. Протокол — це узгоджений набір правил щодо того, як незалежні компоненти спілкуються, інтерпретують повідомлення один одного та будують довіру.
Цінність стандартизації доступу до інструментів переважно економічна. Коли витрати на інтеграцію нової моделі чи програми наближаються до нуля, експериментування стає дешевим, а дешеві експерименти сприяють швидшому вдосконаленню. Команда, яка керує системою, може оприлюднити один сервер MCP, і кожен поточний та майбутній AI-додаток у організації зможе ним скористатися без спеціального коду для з’єднання. Щоб дізнатися, як це працює в межах фреймворку агентів, прочитайте нашу статтю про стандартизацію інтеграції інструментів у LangGraph за допомогою MCP.
Основні висновки
- LLM надають найбільшу користь, коли можуть працювати з реальними системами, і перешкодою є інтеграція, а не рівень інтелекту.
- Без стандарту один і той самий інструмент доводиться перереалізовувати для кожного SDK моделі та кожного додатку; MCP переміщує цю логіку на сервер, який належить системі, що надає цю функціональність.
- Хост запускає один клієнт на кожен сервер, і кожен клієнт підтримує окреме з’єднання; сервери надають інструменти, ресурси та запити.
- JSON-RPC визначає формат повідомлень, тоді як MCP додає фіксований словник методів, такий як
tools/call, та механізм виявлення можливостей. - Для локальних інструментів для одного користувача використовуйте stdio, а для спільних віддалених сервісів — Streamable HTTP, і перевіряйте деталі транспортування відповідно до поточних специфікацій.