MCP: як працює Model Context Protocol

LLM вже певний час можуть викликати інструменти, але Model Context Protocol (MCP) забезпечує структурований, стандартизований спосіб робити це.

Проте досі є плутанина щодо того, чим MCP насправді є.

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

Розберімо це.

Якщо ви просто хочете побачити, що MCP відкриває на практиці, перегляньте це коротке відео:

Що таке протокол?

Протокол це просто набір правил, які визначають, як дві або більше систем взаємодіють одна з одною.

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

Поштові системи роблять щось подібне. Усі поштові відділення в певній країні дотримуються стандартизованого формату адреси для надсилання листів.

Або уявіть це як USB-C для AI-інструментів. Двадцять років тому ринок був переповнений різними типами кабелів для заряджання і передавання даних. Так само AI-екосистеми мали кілька способів передавання інструментів мовним моделям. Фреймворки на кшталт LangChain, Haystack і Pydantic AI визначали власні формати для інтеграції інструментів. Це означало, що якщо розробник хотів написати набір інструментів для Google Maps, йому доводилося робити це для кожної конкретної технології.

Щоб зробити це конкретнішим, розгляньмо найпопулярніший протокол, HTTP (Hypertext Transfer Protocol), на якому працюють вебсайти. HTTP, серед іншого, визначає, як браузер (клієнт) запитує вебсторінку у вебсервера і як сервер має відповідати.

Ось приклад циклу HTTP-запит-відповідь:

1. Браузер робить HTTP-запит

Коли ви вводите https://example.com у браузері, браузер надсилає структурований HTTP-запит до вебсервера:

Ось параметри й значення HTTP, використані в нашому прикладі:

"GET" – Це дія (запит вебсторінки).
"/index.html" – Конкретна вебсторінка, яку запитують.
"HTTP/1.1" – Версія протоколу, що використовується.
"Host: example.com" – Доменне ім’я вебсайту.
"User-Agent: Mozilla/5.0" – Інформація про браузер, який робить запит.

Вебсервер знає, як інтерпретувати цей запит, тому що HTTP стандартизує цей формат. Він розуміє цю “мову”.

2. Сервер відповідає за протоколом HTTP

Сервер обробляє запит і надсилає назад структуровану HTTP-відповідь:

"HTTP/1.1 200 OK" – Код відповіді (200 означає успіх).
"Content-Type: text/html" – Тип контенту, який надсилається назад.
"Content-Length: 512" – Розмір відповіді.
HTML Content – Фактичний вміст вебсторінки (там лише заголовок "Welcome to Example.com")

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

Як MCP працює як протокол

Тепер застосуймо той самий підхід до MCP (Model Context Protocol).

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

Що це за “інструменти”?

У контексті LLM, інструменти це зовнішні системи, API або сервіси, з якими AI може взаємодіяти, щоб розширити свої можливості за межі генерації тексту. Вони дають AI-агентам змогу отримувати дані в реальному часі, бронювати зустрічі або писати вашим друзям, роблячи їх набагато кориснішими для реальних потреб.

Припустімо, ви запитуєте AI-агента:

“Котра зараз година в Лондоні?”

Оскільки сам AI не знає правильної відповіді, адже AI-моделі мають дату відсікання знань (жовтень 2023 для моделей OpenAI), йому потрібно отримати актуальні дані від сервісу часу. Але замість того, щоб використовувати HTTP для запиту вебсторінки, AI використовує MCP для запиту даних про час.

Ось що відбувається:

1. AI-агент робить MCP-запит до сервісу часу (приклад)

"method": "tools.call" → AI викликає зовнішній інструмент.
"tool": "get_time" → Назва інструмента, який він хоче використати.
"args": { "location": "London" } → Конкретні вхідні параметри.

Як і в HTTP, цей запит дотримується строгого формату, щоб будь-який MCP-сумісний інструмент точно знав, як його інтерпретувати.

2. MCP-сервер часу відповідає

Зовнішній інструмент (сервер часу) дотримується правил відповіді MCP і надсилає назад:

"status": "success" → Підтверджує, що запит оброблено правильно.
"result" → Містить фактичні дані про час.

Тепер AI-агент може взяти ці дані й скласти фактичну відповідь користувачеві:

“Поточний час у Лондоні, 12:20 PM (GMT).”

Підсумуємо й усунемо плутанину:

“MCP це застосунок.” → Ні, MCP це набір правил. Щоб фактично використовувати його, потрібні AI-програмне забезпечення та інструменти, які реалізують MCP, так само як застосунку Instagram потрібні активні сервери Instagram, щоб відповідати на HTTP-запити й надавати дані.

“MCP це база даних.” → Ні, MCP не зберігає дані. Він допомагає AI-агентам взаємодіяти з базами даних або API.

“MCP це як API.” → Не зовсім. API це конкретний спосіб взаємодії з однією системою, тоді як протокол (наприклад, MCP або HTTP) визначає універсальний спосіб, у який багато різних систем можуть взаємодіяти. MCP це мова, яку AI-система може використовувати для взаємодії з багатьма фактичними API (час, бази даних, Stripe, Slack тощо).

Чому MCP викликає інтерес

Тепер, коли ми знаємо, що MCP це стандартизований спосіб взаємодії AI-програмного забезпечення із зовнішніми інструментами й застосунками, і що MCP не є API, розберімося, чому спільнота AI-розробників (і ми також) зацікавилася ним.

Оскільки MCP не є API, а радше дає AI-застосункам змогу взаємодіяти з фактичними API у масштабі, він допомагає проєктам, які потребують підключення до багатьох зовнішніх систем, швидше стартувати. Інструменти також надають моделі охоплення, і те, що сталося в інциденті OpenAI Hugging Face, показує, як виглядає це охоплення, коли воно виходить за межі завдання. Щоб зробити це, розробникам іноді доводилося проходити повний цикл розробки API-інтеграції, але сьогодні вони зазвичай використовують наявні бібліотеки або open-source проєкти (наприклад, доступні на GitHub), які надають потрібну функціональність.

Використання таких бібліотек прискорює розробку, але їхня правильна інтеграція з вашою системою (якщо вона несумісна з реалізацією, яку ви знайшли на GitHub) усе одно потребує зусиль, щоб інструмент працював з AI.

З MCP, коли фреймворк уже налаштований, додавання нової інтеграції (скажімо, інтеграції Google Drive) може звестися до підключення до MCP-сервера Google Drive кількома рядками коду. Ви не зіткнетеся з проблемами сумісності, тому що обидві сторони використовують той самий протокол: MCP.

Порівняймо обидва підходи, щоб чіткіше побачити відмінності.

Стандартна інтеграція проти використання Model Context Protocol (MCP)

Щоб зробити порівняння конкретним, розгляньмо додавання доступу до файлів Google Drive для AI-агента, спочатку вручну, а потім із MCP-сумісним інструментом.

Стандартна інтеграція

1. Знайти й адаптувати бібліотеку: ви шукаєте клієнт Google Drive API або open-source проєкт. Google надає клієнтські бібліотеки (наприклад, Google Drive API for Python), ви додаєте їх до свого проєкту. Вам усе одно потрібно переконатися, що вони працюють із середовищем вашого AI.

2. Реалізувати логіку: ви пишете функції, наприклад, для пошуку файлів або отримання документа з Drive. Коли AI щось потрібно, він має викликати ці функції. Ви форматуєте запит AI у виклики API, специфічні для Google Drive. Після отримання відповіді від Google ви витягуєте контент, щоб передати його назад у контекст AI.

3. Обробити помилки й граничні випадки: додайте код для обробки випадків на кшталт “файл не знайдено”, помилок дозволів або лімітів частоти запитів API. Якщо API Google повертає помилку, ви перехоплюєте її і, можливо, відповідаєте вибаченням або просите AI переформулювати запит. Також потрібно захиститися від того, щоб ваш AI не надсилав забагато запитів надто швидко.

4. Підтримувати: з часом, якщо Google оновить свій API або бібліотеку, вам доведеться оновити свій код. Якщо ви знайдете баг у бібліотеці, можливо, доведеться виправити його або знайти інше джерело. Фактично ви стаєте відповідальними за підтримку цієї інтеграції Google Drive у вашому AI-застосунку.

Цей процес поширюється й на інші інструменти: хочете додати Slack або базу даних до свого AI? Потрібно повторити весь процес для кожного з них.

Інтеграція MCP

Тепер подивімося, як цей процес виглядав би за використання MCP.

Спочатку визначимо ключові поняття:

Клієнт – AI-застосунок (ChatGPT, застосунок Claude, Quickchat AI), який установлює з’єднання з одним або кількома серверами й запитує інформацію або дії для виконання завдань, заданих користувачем.

Сервер – кожен сервер може підключатися до чогось на кшталт бази даних, API (Google Drive) і визначати набір “інструментів” або даних, які він може надати. У цьому випадку сервер це програма, яка надає ці інструменти й можливості клієнту (AI-застосунку).

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

• Ініціалізація MCP-сервера. Розробник або системний адміністратор налаштовує MCP-сервер для певного інструмента або джерела даних. MCP-сервер зазвичай є невеликою програмою, яка реалізує специфікацію MCP. Наприклад, доступний готовий MCP-сервер Google Drive, який знає, як шукати й отримувати документи.

  Під час ініціалізації сервера ви надаєте йому доступ до цільової системи (Google Drive). Потім сервер відкриває набір інструментів, що відповідають діям або запитам, які він може обробляти. По суті, це API-адаптер, який говорить MCP з одного боку і рідною мовою сервісу з іншого боку.

  Після запуску сервер очікує на запити.

• Підключення LLM (клієнта) до MCP-сервера. Далі AI-застосунок (сторона “клієнта”) має підключитися до цього сервера. На практиці, якщо ви використовуєте AI-платформу, що підтримує MCP (наприклад, Claude Desktop), ви налаштовуєте її з адресою або командою для запуску сервера. Після підключення клієнт встановлює сесію із сервером, дотримуючись handshake MCP. Якщо ви використовуєте інтерфейс Claude, ви побачите, що Claude “підключений” до певних MCP-серверів (UI може показувати доступні конектори).

Так це виглядає в Claude UI

• Виявлення доступних інструментів. Після встановлення з’єднання перше, що потрібно зробити, це з’ясувати, що пропонує сервер (іноді це відбувається автоматично після підключення до сервера). MCP-клієнт надсилає на сервер запит tools/list (це визначено в протоколі). Сервер відповідає списком доступних інструментів, кожен із такими деталями, як назва, опис і схема вводу.

  Наприклад, сервер може відповісти, що має доступні інструменти create_file(path, content), read_file(path) і search_files(query). Потім клієнт робить цю інформацію доступною для LLM. У багатьох реалізаціях клієнт відформатує ці описи інструментів і включить їх у контекст моделі (наприклад, додавши до системного промпта: “У вас є доступ до таких інструментів… [список інструментів]”).

Ось системний промпт AI разом із повідомленням користувача, який запитує поточний час

Коли інструменти MCP реалізовані, інтегрується інструмент під назвою “get_current_time”, що дає AI змогу отримати доступ до зовнішнього ресурсу й отримати точний час у Лондоні

Це означає, що вам не потрібно заздалегідь продумувати й програмувати всі потенційні дії, які можуть знадобитися вашому AI-застосунку для виконання певного завдання. З MCP AI може на ходу виявити всі можливі дії, запитавши MCP-сервер, і вибрати потрібну.

• Використання інструмента через MCP. Коли AI потрібно виконати дію або отримати дані, він викликає інструмент через MCP. З погляду AI (особливо для моделей на кшталт Claude, які нативно підтримують використання інструментів), він вирішить у своїх міркуваннях: “Мені слід викликати інструмент X із цими параметрами.” MCP-клієнт перехоплює цей намір і надсилає запит tools/call у форматі MCP до відповідного сервера (MCP-сервера Google Drive).

• MCP-сервер діє як міст. Він отримує структурований MCP-сумісний запит від AI-агента, зіставляє його з правильним endpoint Google Drive API, переписує запит у фактичний виклик Google Drive API, виконує запит, обробляє відповідь і знову переформатовує її в MCP-сумісну відповідь, перш ніж надіслати назад AI-агенту.

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

  Припустімо, AI-агент використовує інструмент MCP, щоб знайти файл у Google Drive. Якщо запит містить недійсний ID файлу (наприклад, рядок завдовжки п’ять символів замість очікуваного формату), MCP-сервер поверне повідомлення про помилку:

  Замість того, щоб просто зазнати невдачі, AI-агент може взяти цю структуровану відповідь і переформулювати її у зрозумілий для користувача відгук:

  “Схоже, ID файлу, який ви надали, занадто короткий. ID файлів Google Drive зазвичай мають довжину 28 символів. Перевірте його й спробуйте ще раз.”

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

• Відповідь на запитання/запит користувача. Щойно MCP-сервер повертає результат, MCP-клієнт передає ці дані назад AI-застосунку. Потім модель включає результат у свої міркування або безпосередньо у відповідь, яку генерує для користувача.

  Якщо користувач просить створити новий файл Google Sheets, відповідь сервера (що містить ID файлу та згенероване посилання) буде передана в модель. Потім модель відповість користувачеві: “Гарні новини! Ваш новий файл Google Sheets готовий. Ви можете відкрити його тут: [link].”

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

Переваги використання MCP

Зверніть увагу, як цей підхід абстрагує багато деталей: клієнт не обробляв API-ключі або HTTP status codes, цим займається MCP-сервер.

Головне тут простота в точці інтеграції: ми “запитуємо” клієнтів і отримуємо їх. Логіка того, як їх отримати, інкапсульована в іншому місці. Це означає, що розробнику, який працює на AI-стороні, не потрібно писати нові HTTP-виклики для кожної нової дії, він просто викликає інструменти за назвою. Основну роботу (auth, виклики endpoint Google Drive, форматування відповіді) виконує код MCP-сервера, який є повторно використовуваним і стандартизованим.

Ось короткий виклад ключових переваг:

• Зменшує обсяг API-специфічного glue code. До MCP, щоб змусити AI використовувати зовнішній сервіс, зазвичай потрібно було писати чимало “клейового” коду: викликати API, перетворювати відповідь у текст, який модель може обробити, потім парсити вихід моделі, щоб, можливо, викликати інший API тощо. З MCP значна частина цього glue code зникає. Клієнт моделі й сервер обмінюються даними структуровано, тому вам не потрібно вручну перетворювати інші формати (наприклад, JSON) у текст або навпаки, це робить протокол. Також не потрібно писати логіку для визначення, що і коли викликати. Це робить AI (керуючись описами інструментів і власними міркуваннями або промптом).

• Повторно використовувані спільні конектори замість одноразових API-обгорток. З MCP ви пишете інтеграцію один раз і можете повторно використовувати її в багатьох проєктах та AI-системах. Наприклад, ви можете створити MCP-сервер для внутрішньої wiki вашої компанії. Будь-який AI-застосунок, що підтримує MCP, може підключитися до цього одного сервера, щоб робити запити до wiki. Вам не потрібно повторно реалізовувати “пошук у wiki” для кожного нового AI-чатбота або кожного іншого постачальника LLM. Така повторна використовуваність є зсувом від минулого, коли кожна команда могла писати власну трохи відмінну інтеграцію для того самого API. MCP заохочує бібліотеку конекторів, які можна спільно використовувати й колективно покращувати.

• Plug-and-play інтеграція з різними LLM. MCP не залежить від моделі. Протоколу байдуже, чи клієнт це Claude, GPT-4, DeepSeek або будь-яка майбутня модель, якщо клієнт може працювати з інтерфейсом MCP. У майбутньому, якщо ви захочете перейти на іншу модель, ви зможете зробити це без переписування всіх інтеграцій.

• Простіша підтримка. Оскільки це відкритий стандарт, зростає спільнота, яка робить внесок у готові сервери (для баз даних, популярних API тощо), що їх можна використовувати замість створення з нуля. Коли ви інтегруєте більше систем, MCP допомагає уникнути “спагеті” з багатьох точка-до-точки інтеграцій. І вам не потрібно відстежувати всі оновлення API від інших провайдерів.

Чи стануть API-інтеграції застарілими?

І традиційні API-інтеграції, і MCP мають своє місце. Найкращий підхід може залежати від характеру проєкту, експертизи команди й довгострокових цілей.

Якщо вам потрібно інтегруватися лише з одним або двома зовнішніми сервісами, а взаємодії відносно прості, пряме API-підключення часто є найшвидшим рішенням. Якщо вашому вебзастосунку потрібно лише перевірити платіжний токен Stripe під час checkout, прямий виклик API Stripe простий і ефективний. Запровадження MCP у цьому сценарії може бути надмірним. Ви можете підключити AI-агента до будь-якого документованого REST API за допомогою однієї перевіреної HTTP Action або використати інтеграцію в один клік, наприклад Google Sheets для запису лідів і запитів на демо, без запуску MCP-сервера.

У випадках, коли потрібен дуже точний контроль над запитом/відповіддю (для оптимізації продуктивності, спеціальної обробки даних або пропрієтарних протоколів), пряме написання до API може бути кращим. Традиційні інтеграції дають змогу використовувати всі розширені можливості API й точно налаштовувати виклики. Якщо API має незвичні вимоги або якщо ви хочете уникнути будь-якого шару абстракції для максимальної прозорості й контролю, традиційний підхід доречний.

Щоб побачити конкретний приклад того, як інструменти MCP відкриваються виробничому AI-агенту поряд із кастомними API-діями, перегляньте, як Quickchat AI Agents поєднують обидва підходи. Глибше обговорення того, коли використовувати MCP, окремі AI Actions або “Generate from Text”, наведено в APIs for AI Agents: From MCP to Custom Endpoints. Щоб спробувати самостійно, скористайтеся покроковим посібником, як підключити свого AI-агента до віддаленого MCP-сервера, щоб він викликав активний інструмент посеред розмови.

Список доступних MCP-серверів

Якщо ви хочете почати працювати з MCP, перегляньте каталоги MCP-серверів нижче:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Ви також можете запустити один без написання коду: кожного Quickchat AI Agent можна перетворити на MCP-сервер з hosted URL, який Claude, ChatGPT і Cursor викликають як інструмент. Підключення працює і в іншому напрямку: Quickchat AI Agent може викликати hosted MCP-сервер постачальника як свої інструменти. Саме так AI-помічник для планування, створений на MCP-сервері Calendly, перевіряє реальну доступність і бронює зустрічі з чату, а Notion AI-чатбот відповідає з актуального довідкового центру і записує запити підтримки назад у базу даних Notion.

Quickchat AI також запускає віддалений MCP-сервер для вашого власного облікового запису. Підключіть його до ChatGPT, Claude, Cursor або Codex, і ви зможете керувати своїми AI Agents звідти: аналітика, транскрипти розмов, оновлення бази знань і створення нових Agent, за одним входом через OAuth. Покрокове налаштування для кожного клієнта наведено в Manage Your AI Agent from ChatGPT, Claude, and Codex with MCP.

FAQ

Чи працює це лише з Claude?

MCP не залежить від моделі. Протоколу байдуже, чи клієнт це Claude, GPT-4, локальна похідна LLaMA або будь-яка майбутня модель, якщо клієнт може працювати з інтерфейсом MCP. Це означає, що ви не прив’язані до одного AI-провайдера, коли створюєте інтеграції інструментів.

Чим MCP відрізняється від того, щоб просто заздалегідь надати моделі всю потрібну інформацію? Чому б не заповнити промпт даними?

MCP принципово відрізняється від заповнення промпта моделі даними, тому що дає моделі змогу динамічно отримувати інформацію тоді, коли вона потрібна, замість роботи зі статичним, попередньо завантаженим промптом. Додавання тексту в промпт наштовхується на обмеження, оскільки AI-моделі мають фіксоване контекстне вікно. Це означає, що надмірна кількість даних може призвести до втрати важливих деталей, сповільнення відповідей і збільшення витрат на API (через моделі ціноутворення за токени, які використовують постачальники LLM). Також це надає знання лише на певний момент часу, тоді як MCP забезпечує доступ у реальному часі до актуальних зовнішніх даних і дозволяє AI виконувати дії, а не лише читати інформацію. AI з переповненим промптом може знати деталі клієнта, але не зможе оновити записи або обробити транзакції.

Що, якщо ми підключимо до AI десятки інструментів? Хіба це не перевантажить модель або не змусить її використовувати їх неправильно?

Це залежить від реалізації, але справді, сучасні LLM мають обмеження в тому, наскільки добре вони розрізняють і вибирають між багатьма варіантами. Якщо надати моделі, скажімо, 50 можливих інструментів, є ризик, що вона вибере неправильний. Сам підхід MCP не змушує завантажувати все одразу. Ви маєте підключати релевантні інструменти залежно від контексту. Найкраща практика, підключати лише ті інструменти, які потрібні для поточного завдання/домену, і використовувати мультиагентну співпрацю, тобто певну маршрутизацію інструментів або агента, який спочатку вирішує, яку підмножину інструментів слід розглядати.

MCP проти Function Calling

Традиційний function calling (як в API OpenAI або інших LLM) дає розробнику змогу визначити набір функцій, надати їхні визначення моделі й дозволити моделі “викликати” їх за назвою з аргументами. Це був великий крок для AI-інтеграції, але він має обмеження. Одна з головних відмінностей полягає в тому, коли і як визначаються інструменти. У класичному function calling усі можливі функції потрібно оголосити заздалегідь (під час проєктування) у промпті або через API. Модель може викликати лише ці фіксовані функції. У MCP інструменти можна виявляти під час виконання, AI може запитати, що доступно, і навіть отримати нові інструменти посеред сесії.

MCP проти GPT Actions & Plugins

GPT Actions/Plugins стосуються екосистеми OpenAI, де можна було вмикати плагіни (наприклад, веббраузер або PDF reader) для ChatGPT, або “GPTs” (кастомні агенти ChatGPT), які можуть використовувати інструменти. Це було цікаво, але потребувало кастомної розробки для кожного плагіна і було обмежене платформами OpenAI. Якщо вам потрібен був плагін ChatGPT для певного завдання, потрібно було створити API і manifest, а також пройти схвалення OpenAI або принаймні ввімкнути його вручну. Кожен плагін фактично був окремим silo, плагін погоди, плагін подорожей тощо, кожен із власними endpoint і логікою. MCP покращує цю концепцію, уніфікуючи її й відкриваючи.

MCP проти RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) це техніка, у якій LLM доповнюється зовнішньою базою знань. Зазвичай RAG передбачає векторну базу даних або пошуковий індекс: запит користувача використовується для отримання релевантних документів або даних (через семантичний пошук або інші методи), і ці документи надаються моделі як додатковий контекст для “читання” під час формування відповіді. RAG призначений для надання моделі знань, яких вона спочатку не мала, що особливо корисно для фактичних QA або доменно-специфічної інформації. Однак RAG доступний лише для читання, модель отримує текстові фрагменти, але не виконує дій за межами retrieval.

MCP, натомість, призначений для виконання дій або довільних операцій, а не лише для отримання інформаційного контексту. З MCP AI може робити речі: записувати в базу даних, надсилати email, виконувати код тощо. Він не обмежений отриманням знань, він може запускати зміни в зовнішніх системах. Отже, у багатьох аспектах RAG і MCP слугують різним цілям.