Вступ до MCP: від фрагментації до спільних серверів інструментів

Що, якби модель мови могла підключатися, спілкуватися та діяти у реальному світі? MCP є з’єднувачем між інтелектом та дією.

ChatGPT був запущений 30 листопада 2022 року та прискорив використання штучного інтелекту у повсякденному житті — для підвищення продуктивності, виконання щоденних завдань та розв’язання проблем. Постачальники почали вбудовувати ШІ у продукти, які люди вже використовували: набори для підвищення продуктивності, чат-додатки, системи пошуку, інтегровані середовища розробки, корпоративне програмне забезпечення. Асистенти більше не були лише окремими чат-ботами.

З’явилась ще складніша проблема. Моделі можуть міркувати та писати, але для виконання значущої роботи потрібен правильний контекст, дані, інструменти та системи. Підключення цих елементів зазвичай вимагало створення індивідуальних інтеграцій, API, механізмів автентифікації та коду, специфічного для кожного інструменту. Цей стан називається фрагментацією.

Проблема фрагментації

Фрагментація виникає, коли команди використовують багато асистентів ШІ, кожен з яких знаходиться у власній екосистемі.

Уявіть розробника у VS Code. Допоміжний інструмент всередині редактора розуміє лише те, що знаходиться всередині нього. Як тільки їм потрібні питання у GitHub чи сторінки у Confluence поза межами IDE, вони залишають цього допоміжника, копіюють текст, вставляють його назад та сподіваються, що модель отримає достатньо контексту.

Ця постійна зміна інструментів та ручне передавання контексту є проявом фрагментації: модель є розумною, але вона не бачить автоматично всіх систем, які потрібні для виконання завдання.

Що означає „контекст“

Контекст — це все, що модель може бачити під час відповіді. Практично це те, що використовується LLM для структурування відповіді — часто історія чату та все, що вставив користувач.

Приклад: створення функції безпеки за допомогою ChatGPT. Розробник може:

1. JIRA — скопіювати вимоги та критерії прийняття до чату.
2. GitHub — вставити відповідні реалізації та репозиторії.

MySQL — вручну отримувати дані системи та вводити їх.

Google Drive — вставляти документи, керівні принципи безпеки, нотатки щодо архітектури.

Teams/Slack — збирати недокументовані знання від колег.

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

• Ручне копіювання та вставляння між системами є повільним.
• Контекст розсіюється; розробники стають своєрідними людськими API.
• Час зборки може перевищувати час розробки.
• Більше джерел робить цей процес нездатним до масштабування; реальні системи є більшими, ніж буфер для вставки.

Саме ці труднощі сприяли впровадженню викликання функцій/інструментів у середині 2023 року (робота OpenAI).

Викликання функцій

Виклик функцій дозволяє моделі отримувати доступ до зовнішніх ресурсів через функції та використовувати отримані результати як контекст. Чат сам по собі поступився місцем автоматизації завдань: модель обирає інструмент, додаток його запускає, а потім модель продовжує роботу.

Завдяки інструментам, створеним для JIRA, GitHub, MySQL, Drive, Slack тощо, модель може вибирати, що запустити на основі запиту користувача, отримувати контекст та відповідати — без необхідності постійного вручну вставляння даних.

Обмеження виклику функцій у межах окремого додатка

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

Чи може N × M скоротитися до N + M? Саме тут вступає у гру MCP.

Протокол контексту моделі (MCP)

MCP — це відкритий протокол, який стандартизує спосіб підключення додатків ШІ до зовнішніх інструментів, даних та сервісів.

Є дві основні ролі:

• Klient MCP — знаходиться в додатку/агенті ШІ, підключається до сервера, виявляє та використовує доступні інструменти/ресурси.
• Сервер MCP — створює зв’язок між додатком ШІ та GitHub, JIRA, базою даних, Drive, Slack чи іншим сервісом.

Klient ↔ сервер спілкуються за протоколом MCP. Замість того, щоб кожен асистент винаходив власний адаптер для кожного постачальника, додатки виявляють та використовують можливості через єдиний формат.

Виклик функцій проти MCP — приклад з погодою

1. Виклик функцій

Ви визначаєте функцію, яка знаходиться локально в додатку та взаємодіє з API погоди:

import requests

def get_weather(city):
    response = requests.get(
        "https://api.weather.com/current",
        params={"city": city}
    )
    return response.json()

Ви реєструєте цю функцію як інструмент. Користувач запитує: «Яка погода в Бенгалуру?» Модель може викликати get_weather("Bengaluru"). Додаток її запускає, повертає дані, а модель формує відповідь.

Команда розробників додатку відповідає за визначення та підтримку цієї функції та відповідних механізмів взаємодії з API.

2. MCP

Інформація про погоду зберігається на сервері MCP, який взаємодіє з API та надає стандартний інструмент:

@mcp.tool()
def get_weather(city: str):
    """Get the current weather for a city."""
    return weather_api.get_current_weather(city)

Додаток на основі ШІ є клієнтом MCP, який знаходить функцію get_weather. Той самий запит користувача → пошук/виклик через MCP → використання результату у відповіді.

Різниця полягає у тому, що MCP стандартизує взаємодію між додатком на основі ШІ та відповідними можливостями, тож один сервер може обслуговувати багато сумісних клієнтів.

Переваги MCP

• Менше повторюваних завдань з технічного обслуговування порівняно з каталогами функцій окремих додатків
• Нижчі витрати та час, необхідні для інтеграції
• Чіткіші межі безпеки на рівні сервера
• Інтеграції масштабуються ближче до формули N + M, ніж N × M

Ось чому це важливо. У наступних розділах буде розглянута архітектура, внутрішні механізми та практична реалізація.

Ще раз розглянемо аспекти безпеки

Повернімося до розробника, який створює функції безпеки. Без MCP чи інших інструментів йому доводиться шукати потрібну інформацію в JIRA, GitHub, MySQL, Drive та Slack; кожен крок — це переклад контексту. За допомогою викликів функцій ці кроки перетворюються на названі функції, які може використовувати модель, проте кожному асистенту в компанії все одно потрібна власна копія інтеграцій.

MCP усуває це дублювання. Один сервер погоди, один сервер JIRA, один сервер GitHub можуть обслуговувати багато клієнтів, сумісних з MCP. Структура N×M наближається до формату N клієнтів плюс M серверів.

Примітки щодо дизайну, які ігнорують команди

Ставтеся до описів інструментів як до тексту продукту: чіткі назви та документація до параметрів допомагають правильно обрати модель. Зберігайте інструменти для запису після підтвердження та розділяйте сервери для запису від інструментів каталогу з лише читальним доступом. Логуйте виклики інструментів з ідентифікаторами кореляції, щоб можна було відстежити причину поганої відповіді до неправильного пошуку, а не звинувачувати „модель“ у загальних термах.

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

Що буде далі

Як тільки мотивація стає зрозумілою — фрагментація, об’єднання контексту та проблеми інтеграції — наступним кроком є архітектура: як клієнти знаходять інструменти, як сервери автентифікуються, як сеанси передають результати та як запустити перший продакшн-сервер. Ці теми потребують окремих детальних розглядів; завданням цього тексту було зробити „чому“ незаперечним та показати приклад роботи з метеоданими обома способами.

Фрагментація як проблема бюджету

Підрахуйте кількість годин, які ваша команда витрачає на копіювання даних з JIRA та GitHub у чати. Ця праця є податком на кожного штучного інтелектуального асистента, якого ви використовуєте. Виклики функцій скорочують час копіювання, але збільшують обсяг коду адаптерів. MCP спрямований на використання спільних серверів замість окремих версій для кожного асистента.

Сформулюйте бізнес-кейс у цих термінах: менше годин роботи людей з API, менше дублікатів інтеграцій, чіткіші пункти аудиту. Для фінансового відділу діаграми архітектури мають менше значення, ніж таблиці у форматі N×M.

Висновки щодо прикладу прогнозу погоди для рецензентів

У сценарії виклику функцій HTTP-клієнт для прогнозу погоди знаходиться в самому додатку. У сценарії MCP він розташований на сервері, який можуть використовувати інші додатки. Однак формулювання запиту користувача залишається однаковим, тоді як власність інтеграції відрізняється. Варто обирати сервер, якщо вже планується створення другого клієнта; краще використовувати локальну функцію, якщо експеримент буде скасований у наступному циклі розробки.