AI‑агенти стрімко виходять за межі звичайних чатботів: вони запускають тести, ходять в API, читають файли, працюють з Jira та GitHub. Але як саме підключити модель до всіх цих інструментів — і як організувати її поведінку так, щоб система була передбачуваною? У свіжому пояснювальному ролику IBM Technology розбирають дві ключові технології для цього — Model Context Protocol (MCP) від Anthropic та Agent Development Kit (ADK) від Google — і показують, що це не конкуренти, а дві частини однієї архітектури.
MCP: стандартний «адаптер» між LLM і зовнішнім світом
Від «клейового коду» до протоколу
До появи MCP кожен, хто будував агента, змушений був писати власні інтеграції для всього: баз даних, файлових систем, веб‑скрейперів, корпоративних сервісів. Один розробник писав обгортку для Postgres, інший — для GitHub, третій — для Google Drive, і всі по суті вирішували одну й ту саму задачу «з нуля».
Model Context Protocol змінює це, вводячи відкритий стандарт: є клієнт (LLM‑агент або хост‑система) і є MCP‑сервер, який «обгортає» конкретний інструмент чи джерело даних. Протокол визначає, як саме вони спілкуються.
Як це працює технічно
MCP використовує формат повідомлень JSON‑RPC — по суті структурований текст, який легко парсити й логувати. Далі все залежить від того, де розгорнуто сервер:
- Локально (IDE‑плагін, десктоп‑додаток, доступ до файлової системи):
- обмін через стандартний ввід/вивід (stdin/stdout);
- Віддалено, через веб:
- HTTP зі стримінгом;
- підтримка токенів автентифікації, щоб хост і сервер могли безпечно підтверджувати один одного.
Ключова ідея: MCP‑сервер — це багаторазова обгортка навколо вашого інструменту. Написавши його один раз, ви дозволяєте будь‑якому MCP‑сумісному клієнту використовувати цей інструмент без додаткового «клейового» коду.
Три базові примітиви MCP
MCP описує три типи можливостей, які може надати сервер:
- Tools (інструменти)
Функції, які LLM може викликати: - «запусти цей SQL‑запит»;
- «зроби пошук у вебі»;
-
«створи задачу в Jira».
-
Resources (ресурси)
Дані, які модель може читати: - файли;
- документація;
-
внутрішні та зовнішні бази даних.
-
Prompts (промпти)
Готові шаблони підказок, які сервер може надавати клієнту, щоб не дублювати їх у кожному застосунку.
Модель‑агностичність і зростаюча екосистема
Одна з головних переваг MCP — незалежність від конкретної моделі. Неважливо, чи це Claude, GPT, Gemini або локальна LLM: якщо клієнт «говорить» MCP, він може використовувати ті самі сервери.
Це дозволяє:
- перевикористовувати інтеграції при зміні моделі або хост‑платформи;
- уникати повторної реалізації доступу до GitHub, Slack, Google Drive, Postgres, Jira, Figma тощо — для багатьох популярних сервісів уже існують готові MCP‑сервери, які розвиває спільнота.
Фактично MCP вирішує проблему підключення: як дати агенту стандартизований, безпечний і багаторазовий доступ до зовнішніх інструментів та даних.
ADK: каркас для побудови передбачуваних AI‑агентів
Якщо MCP відповідає на питання «як агент говорить із зовнішнім світом», то Agent Development Kit від Google відповідає на інше: як побудувати самого агента та оркеструвати його роботу.
Структура замість «магічного» коду
ADK — це open‑source Python‑фреймворк, який змушує організовувати агента як повноцінну програмну систему, а не як набір розрізнених викликів LLM. У центрі — кілька базових примітивів:
- Agents (агенти) — одиниці виконання з:
- конкретною моделлю;
- інструкціями;
- дозволеним набором інструментів;
-
контрольованим циклом міркувань.
-
Tools (інструменти) — виклики коду, API чи навіть інших агентів.
-
State (стан) — короткострокова робоча пам’ять у межах однієї сесії.
-
Memory (пам’ять) — довгострокові дані, які зберігаються між сесіями (наприклад, вподобання користувача).
-
Events (події) та Runners (раннери) — механізми, які приймають запити, передають їх агентам, виконують інструменти, оновлюють стан і повертають результати.
Як виглядає цикл роботи агента в ADK
- Користувацький запит надходить до раннера.
- Раннер передає його агенту.
- Агент:
- може згенерувати відповідь;
- може запросити виклик інструменту;
- може змінити внутрішній стан.
- Агент «yield’ить» (призупиняється) і повертає управління раннеру.
- Раннер:
- виконує інструмент;
- оновлює стан/пам’ять;
- вирішує, що робити далі.
- Агент продовжує роботу з урахуванням наслідків.
Критично важливо, що агент зупиняється на кожному кроці, а раннер має повний контроль над наслідками. Це:
- спрощує дебаг і трасування;
- дозволяє будувати передбачувані сценарії;
- дає можливість ставити «запобіжники» (наприклад, не дозволяти небезпечні дії).
Типи агентів: від гнучких до жорстко детермінованих
ADK підтримує кілька типів агентів:
-
LLM‑агенти
Класичний підхід «думай і дій»: модель сама планує кроки, обирає інструменти, коригує стратегію. Максимальна гнучкість, але менше контролю. -
Workflow‑агенти
Детерміновані робочі процеси: - послідовні;
- паралельні;
- циклічні (loop‑based).
Вони корисні, коли наперед відомо, які кроки мають бути виконані й у якому порядку, і немає сенсу віддавати це на розсуд моделі.
- Кастомні агенти
Розробник може створювати власні типи агентів під специфічні задачі.
ADK також:
- підтримує кілька бекендів моделей, не прив’язуючи вас до одного постачальника;
- є агностичним до фреймворків інструментів на інтеграційному рівні — зокрема, може працювати з MCP‑серверами як із джерелами інструментів.
Як MCP і ADK працюють разом: практичний сценарій
Щоб зрозуміти, де закінчується MCP і починається ADK, варто розглянути приклад.
Власний AI‑асистент для розробки
Уявімо, що створюється кодовий асистент, який уміє:
- шукати по репозиторію;
- відкривати файли;
- запускати тести;
- допомагати з дебагом;
- працювати з issue‑трекером.
У такій системі виникають дві великі групи задач.
1. Логіка агента, пам’ять, оркестрація — зона ADK
Потрібно визначити:
- як агент планує дії (коли шукати по репо, коли запускати тести);
- як він реагує на помилки;
- як зберігає короткостроковий стан і довгострокову пам’ять;
- як організувати взаємодію кількох спеціалізованих агентів (наприклад, «дослідник коду», «тестувальник», «верифікатор»).
Це територія ADK:
- задається структура мислення агента;
- описуються робочі процеси (послідовні, паралельні, циклічні);
- впроваджуються guardrails, щоб агент, наприклад, не видалив продакшн‑базу «для чистоти експерименту».
2. Стандартизований доступ до інструментів — зона MCP
Той самий асистент має:
- читати код із репозиторію;
- запускати тест‑раннер;
- створювати або оновлювати задачі в issue‑трекері.
Це завдання MCP:
- кожен із цих ресурсів/інструментів обгортається MCP‑сервером;
- ADK‑агент бачить їх як уніфіковані інструменти;
- інтеграції можна перевикористовувати в інших проєктах або з іншими моделями.
У підсумку:
- ADK визначає, що агент має робити і як він це планує;
- MCP визначає, як саме агент технічно виконує ці дії, спілкуючись із зовнішніми системами.
Це різні рівні однієї архітектури, які природно доповнюють одне одного.
Не «MCP чи ADK», а «яку проблему ви вирішуєте»
У сучасних AI‑проєктах обидві технології дедалі частіше з’являються в одному стеку:
- MCP закриває проблему конективності: стандартизований доступ до інструментів і даних, модель‑агностичність, повторне використання інтеграцій.
- ADK закриває проблему оркестрації: структура агентів, керований цикл міркувань, стан і пам’ять, багатoагентні системи, дебаг і трасування.
Тому ключове питання для розробника — не «що обрати», а «який шар проблеми я вирішую зараз»:
- якщо потрібно підключити LLM до GitHub, Slack, бази даних чи файлової системи — це про MCP;
- якщо потрібно побудувати надійну, тестовану й передбачувану систему агентів — це про ADK, який, до того ж, може використовувати MCP‑сервери як джерело інструментів.
Джерело
YouTube: MCP vs ADK: How Modern AI Agents Connect and Work Together