Усі уроки · 44
MCP: USB-порт для ШІ
Model Context Protocol — відкритий стандарт, що з’єднує моделі з інструментами та даними, і чому він знадобився індустрії.
USB-порт для ШІ
Ви підключаєте мишу до будь-якого ноутбука, і вона працює. Вам не потрібно купувати мишу, зроблену під одну конкретну модель ноутбука, а виробник миші не пише окремий драйвер для кожного комп’ютера на світі. Так було не завжди: у клавіатур був свій круглий роз’єм, у принтерів — широкий, у мишей — третій, і жоден не підходив ні до чого іншого. Потім усі домовилися про один порт, один раз заплатили за перехід — і плутанина зникла.
У ШІ-застосунків такого порту не було. До MCP підключення ШІ-застосунку до інструмента щоразу було окремою роботою: редакторові знадобилося читати файли — пишемо інтеграцію вручну; чату знадобився ваш календар — ще одна інтеграція вручну. За M застосунків і N інструментів потрібно було до M × N з’єднувачів, кожен крихкий і кожен підтримувався окремо.
У листопаді 2024 року компанія Anthropic опублікувала Model Context Protocol (MCP) — USB-порт для ШІ: відкритий стандарт підключення моделей до інструментів і даних. Його швидко прийняли OpenAI, Google, Microsoft і десятки виробників інструментів. Сьогодні про ШІ-програму заведено питати: «Вона підтримує MCP?»
Один протокол замість M × N з’єднувачів
З MCP автор інструмента пише один MCP-сервер, і ним може користуватися будь-який MCP-сумісний застосунок. Автор застосунку реалізує протокол один раз, і всередині нього працює будь-який MCP-сервер. M × N перетворюється на M + N.
Що взагалі таке протокол?
Розберемося з нуля: це слово тут несе велике навантаження.
Протокол — це лише узгоджений набір правил про те, як спілкуються дві сторони. Він визначає, які бувають повідомлення, якої вони форми, хто говорить першим і що відбувається, коли щось іде не так.
Найпростіший побутовий приклад — телефонний дзвінок. Обидві сторони дотримуються сценарію, якого ніхто не записував: той, хто дзвонить, вітається, той, хто відповів, озивається, вони говорять по черзі, один із них прощається, і розмова закінчується. Якби одна сторона почала вигукувати назви товарів без привітання, розмова формально все одно лишилася б звуковими хвилями — але не працювала б. Цей сценарій і є протокол.
У комп’ютерів усе те саме, лише записано точно. Веб працює на HTTP —
протоколі, який каже: клієнт надсилає запит із методом (GET) і адресою, а сервер
відповідає кодом стану (200, 404) і тілом відповіді. Лише завдяки цій
домовленості браузер, написаний однією компанією, може прочитати сторінку, яку
віддає зовсім інша.
MCP — домовленість такого самого роду для одного вузького завдання: як ШІ-застосунок і постачальник інструментів спілкуються між собою. Вона закріплює чотири речі:
- Рукостискання (handshake) — застосунок питає «хто ви і що пропонуєте?», а сервер відповідає списком інструментів, ресурсів і промптів.
- Формат повідомлень — кожне повідомлення — це «конверт» JSON-RPC 2.0, тож обидві сторони знають, де лежать ім’я методу, параметри й ідентифікатор.
- Виклик — «запусти цей інструмент із такими аргументами» і «ось результат» (або «ось помилка»).
- Транспорт — як байти фізично передаються: локальним каналом чи по HTTP.
Ось і вся ідея: дві програми домовилися про ті самі чотири правила й тепер можуть працювати разом, жодного разу не зустрівшись і не зазирнувши одна одній усередину. Три ролі нижче — це просто назви, які MCP дає учасникам цієї розмови.
Три ролі
У MCP навмисно невеликий словник. Три чітко розділені ролі:
- MCP-хост (host) — застосунок, яким користується людина: редактор на кшталт Cursor чи VS Code, чат-застосунок на кшталт Claude Desktop, фреймворк для агентів.
- MCP-клієнт (client) — з’єднувач, що живе всередині хоста. Він підтримує з’єднання з одним MCP-сервером і спілкується за протоколом від імені хоста. Зазвичай один хост запускає кілька клієнтів — по одному на кожен підключений сервер.
- MCP-сервер (server) — невелика програма, яка надає можливості: інструменти для виклику, ресурси для читання, промпти для повторного використання. Сервер може обгортати що завгодно: файлову систему, базу даних, GitHub, Slack, внутрішній API вашої компанії.
Проста картинка: хост — це комп’ютер, клієнт — USB-порт, сервер — пристрій, який ви підключаєте.
Два рівні: транспорт і дані
MCP описано у двох рівнях, і якщо тримати їх окремо, усе стає на свої місця.
Транспортний рівень відповідає на запитання «як передаються байти?»
- stdio — сервер працює як локальний процес, а повідомлення йдуть через стандартний ввід і вивід. Просто, швидко, приватно. Це варіант за замовчуванням для локальних конфігурацій на кшталт Claude Desktop.
- HTTP (Streamable HTTP, а для повідомлень від сервера до клієнта — SSE) — сервер працює віддалено, тож команда може розмістити один спільний сервер з повноцінною автентифікацією. Так інструменти відкривають для цілої організації.
Рівень даних відповідає на запитання «що ми говоримо?» Усі повідомлення — це JSON-RPC 2.0: запити, відповіді та сповіщення в стандартному «конверті». Поверх нього розташовані три типи можливостей:
- інструменти (tools) — дії, які може викликати модель: зробити запит до бази даних, надіслати повідомлення, створити заявку. Коли їх використовувати, вирішує модель.
- ресурси (resources) — дані, які застосунок може прочитати й підставити в контекст: файли, схеми, документи. Ними керує застосунок, а не модель.
- промпти (prompts) — шаблони промптів із параметрами для повторного використання, які пропонує сервер; в інтерфейсі вони часто виглядають як слеш-команди.
Як запит проходить через увесь стек
Ось повний шлях одного запиту користувача:
«Що в мене в календарі на завтра?» — набрано в застосунку-хості.
Отже, повне коло таке: ви — хостові, хост — моделі, модель — назад хостові, хост — клієнтові, клієнт — серверові, сервер — назад клієнтові, клієнт — хостові, хост — знову моделі і, нарешті, відповідь — вам. Модель і сервер ніколи не розмовляють напряму — хост завжди посередині.
Та сама форма, яку ви вже знаєте з виклику функцій, — але тепер інструмент живе в окремому процесі, можливо, на іншій машині, і ним може користуватися будь-який MCP-сумісний застосунок.
Як інструменти потрапляють до моделі
Модель ніколи ні до чого не «підключається». Хост збирає визначення інструментів з усіх підключених серверів і поміщає їхні схеми — ім’я, опис, JSON Schema параметрів — у контекст моделі. Модель читає ці описи як меню й обирає, що викликати. Тому опис інструмента — це вся його «презентація» для моделі. Напишете недбало — і модель обере не той інструмент або не обере жодного.
Подивіться в розмові
Ось обмін репліками, у якому видно крок з інструментом:
Перевірте себе
В аналогії з USB: що таке MCP-сервер?
Хто розмовляє з моделлю під час виклику інструмента MCP?
Звідки модель знає, які інструменти існують?
Куди йти далі
Тепер ви знаєте, що таке MCP і як запит проходить через хост, клієнт і сервер. Далі на дорожній карті — мультимодальний ШІ: моделі, які працюють із зображеннями, звуком і відео, а не лише з текстом. А якщо хочете побачити, звідки пішов виклик інструментів, урок Інструменти та виклик функцій — саме на ньому побудований MCP.