Привіт! У попередній статті ми розбиралися, як RAG (Retrieval-Augmented Generation) перетворює наших ШІ-помічників на справжніх ерудитів. Але що робити, якщо ми хочемо не тільки отримувати відповідь, а ще й дію, наприклад, дізнатися про наш набір «Весняний луг» і відразу його замовити?

Саме тут на сцену виходить те, що ми називаємо Model Context Protocol (MCP). Якщо RAG був тією самою «шпаргалкою», що дозволяє LLM бути в курсі подій, то MCP — це вже повноцінна система взаємодії LLM із зовнішнім світом (цифровим). Він не просто знаходить факти, а активно їх організовує, фільтрує, пріоритезує та представляє модель у такому вигляді, щоб вона могла ухвалювати по-справжньому обдумані рішення та виконувати реальні дії.

У статті:

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

Model Context Protocol (MCP)

Що таке Model Context Protocol (MCP)

MCP — це протокол, запропонований компанією Anthropic. Можна сказати, що це набір правил, принципів та методів, якими сама LLM (або спеціальний агент на її основі) керує своїм контекстом. Це ніби LLM не просто отримувала купу даних, а активно замовляла потрібну інформацію, вказувала, як її обробити, та формувала з неї потрібний контекст для виконання конкретного завдання.

Чим MCP відрізняється від RAG: активне управління контекстом з боку LLM

Пам'ятаєте, ми порівнювали RAG з пошуком потрібних книг у бібліотеці? MCP йде набагато далі, і в цьому процесі сама LLM відіграє ключову роль.

Уявіть, що ви запускаєте нового ШІ-помічника для відділу продажів вашого онлайн-магазину посуду. З RAG ви можете запитати: «Чи є у нас на складі такий-то чайник?» — і RAG швидко знайде інформацію про наявність. Або: «Які умови акції на цей товар?» — і RAG підтягне умови акції з бази даних. Це ніби ви запитували бібліотекаря, чи є конкретна книга.

З MCP ми ставимо складніше завдання, наприклад: «Допоможи мені скласти персоналізовану пропозицію для клієнта, який цікавився набором посуду, але не купив, оскільки його збентежила ціна доставки».

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

LLM (через MCP) сама вирішує:

  • Які інструменти використовувати: спочатку звернутися до CRM-системи, щоб знайти історію взаємодії з клієнтом (що він дивився, що запитував).
  • Далі — залучити систему інвентаризації, щоб перевірити наявність набору посуду, який цікавить.
  • Потім запросити у системи знижок інформацію про можливі індивідуальні пропозиції чи актуальні акції.
  • І, звісно, подивитися в логістичну систему, щоб запропонувати варіанти доставки, які могли б знизити вартість.
  • Можливо, навіть проаналізувати відгуки на схожі товари, щоб виділити переваги.

LLM не просто отримує ці дані, а активно бере участь у їх обробці. Вона (через MCP) може давати інструкції: «Відфільтруй тільки останні 3 взаємодії», «Виділи ключові факти про товар», «Підсумуй умови доставки в один абзац».

MCP — це ті правила та механізми, які дозволяють LLM виконати це складне багатоступеневе збирання та обробку інформації. Внаслідок цього LLM отримує не просто купу розрізнених даних, а комплексний, ретельно сформований контекст, який вона сама ж і допомогла створити. На основі цього «готового сценарію» LLM генерує персоналізовану та переконливу пропозицію для клієнта.

Отже, якщо RAG — це потужний інструмент для пошуку та вилучення, то MCP — це протокол, який дозволяє LLM активно керувати, організовувати, агрегувати та інтелектуально управляти своїм контекстом, перетворюючи розрізнені дані на цілеспрямоване «знання». І якщо ви подумали, що RAG може бути компонентом MCP, то так, ви праві. Це ключовий крок до створення по-справжньому розумних та адаптивних ШІ-систем, здатних виконувати найскладніші бізнес-завдання.

Можна з деякою натяжкою сказати, що MCP — це аналог API, але для LLM. І, мабуть, найдивовижніше, що ми використовуємо ті самі технології, які використовували й раніше. Крім того, стандартні API теж можуть бути перетворені для використання LLM через протокол MCP.

Model Context Protocol (MCP): зазираємо «під капот»

Model Context Protocol (MCP) — це не просто черговий інструмент, а ціла концепція, яка дозволяє нашим ШІ-помічникам стати справжніми менеджерами з управління інформацією. Тепер подивімось, як це все влаштовано зсередини.

Основні компоненти MCP: команда для розумної взаємодії

Щоб ШІ-помічник міг так розумно працювати з даними, йому потрібен цілий набір з декількох компонентів, які спілкуються між собою за певними правилами:

  • Хост MCP (MCP Host): це, грубо кажучи, сам застосунок, де живе велика мовна модель (LLM) — наш ШІ-помічник. Наприклад, це може бути спеціальна програма на вашому комп'ютері або частина складної корпоративної системи. Хост — це мозок всієї операції, який хоче отримати доступ до зовнішніх даних чи можливостей.
  • Клієнт MCP (MCP Client): цей компонент — «посередник» або «перекладач» всередині Хоста. Він вміє «розмовляти» із зовнішніми MCP-серверами та передавати їх відповіді назад ШІ-помічнику. Думайте про нього, як про телефон, який набирає потрібний номер.
  • Сервер MCP (MCP Server): це зовнішня програма чи сервіс, яка надає дані або функції Хосту. Сервер MCP — це як спеціаліст у якійсь галузі. Наприклад, один MCP-сервер може бути «спеціалістом» з вашої CRM-системи, інший — з бази даних товарів, третій — з файлів на вашому комп'ютері.

Можна уявити, що Host та Client це одна програма, а Server — це окрема програма. Спілкування йде між Client та Server, а далі вже внутрішня справа самої програми Client та Host, як вони спілкуються між собою.

Як вони «розмовляють»: технічний діалог, який легко зрозуміти

Спілкування між Клієнтом MCP та Сервером MCP відбувається за чіткими правилами, використовується всім зрозумілий JSON-RPC. Є три основних типи «дзвінків» (повідомлень), якими вони обмінюються:

  • Request (Запит): це коли Клієнт MCP (від імені LLM) щось просить у Сервера MCP. Наприклад: «Дай мені історію замовлень клієнта з ID 123».
  • Response (Відповідь): коли Сервер MCP відповідає на Запит Клієнта. Наприклад: «Ось історія замовлень клієнта 123: купив те-то, такого-то числа».
  • Notification (Сповіщення): це коли Сервер MCP просто щось повідомляє, не очікуючи на відповідь. Наприклад: «Завдання з перевірки статусу замовлення завершено».

Як «підключаються»: зв'язок між Клієнтом та Сервером може бути налагоджений двома основними способами

  • «Дротом» (Stdio): використовується для локальних серверів, коли все працює на одному комп'ютері (найчастіше сервері) чи всередині однієї системи. Це як пряме, надійне дротове з'єднання.
  • «Повітрям» (HTTP з SSE): застосовується для віддалених серверів, які знаходяться десь в інтернеті. Тут використовується стандартний інтернет-протокол HTTP, а SSE (Server-Sent Events) дозволяє Серверу надсилати дані в реальному часі, без постійних запитів від Клієнта. Це ніби Сервер міг би сам зателефонувати Клієнту, коли у нього є нова інформація чи прогрес за завданням.

«Знайомство» та «Узгодження можливостей»

Коли Клієнт та Сервер з'єднуються, вони спочатку «вітаються», і Сервер відразу повідомляє Клієнту (а отже, і LLM), що саме він вміє робити та які функції надає. Це і є те саме «самооголошення» методів, яке позбавляє необхідності читати тонни документації. LLM отримує список доступних інструментів та їх описів і сама вирішує, як їх використовувати. І це буквально змінює все.

«Будівельні блоки» контексту в MCP: що саме ШІ-помічник може використовувати

Щоб наш ШІ-помічник був по-справжньому розумним «менеджером з контексту», MCP дає йому доступ до кількох важливих «будівельних блоків» інформації та функцій:

1. Повідомлення (Messages): це основа будь-якого діалогу. MCP чітко визначає, хто і що говорить. У кожному повідомленні ми матимемо такі блоки:

  • User (ми): те, що говоримо чи запитуємо ми.
  • Assistant (наш ШІ): те, що відповідає ШІ-помічник.
  • System (система): спеціальні інструкції, які ми даємо ШІ-помічнику, щоб він відповідав у потрібному стилі («Будь ввічливим» або «Відповідай тільки за фактами»).
  • Tool (інструмент): це не сам інструмент, а результат його роботи. Наприклад, коли ШІ попросив перевірити наявність товару, і сервер повернув відповідь — це буде повідомлення від Tool. Це допомагає LLM не плутатися і розуміти, хто і що говорить.

2. Інструменти (Tools): це ті самі зовнішні сервіси та функції, які LLM може викликати. Кожен інструмент має ім'я (наприклад, «ПеревіритиНаявністьТовару»), зрозумілий опис (щоб LLM розуміла, коли його використовувати, наприклад: «Використовуй цей інструмент, щоб дізнатися, чи є товар на складі») та список параметрів (що йому потрібно для роботи, наприклад, «ID товару»). LLM сама вирішує, який інструмент використовувати, ґрунтуючись на нашому запиті та своєму розумінні.

3. Пам'ять (Memory): дозволяє ШІ-помічнику «запам'ятовувати» важливі речі між різними сесіями спілкування. Наприклад, якщо клієнт уже говорив про свої уподобання в посуді, ШІ-помічник може «запам'ятати» це, щоб наступного разу пропонувати більш релевантні товари. Це реалізується через спеціальні сервери пам'яті, до яких LLM може звертатися.

4. Файли та Ресурси (Files & Resources): це спосіб дати LLM доступ до даних, які зберігаються у файлах (наприклад, PDF-інструкції), записах баз даних чи результатах інших запитів. Наприклад, LLM може запросити прочитати вміст файлу інструкція_з_догляду_за_кавником.pdf або запис про конкретного клієнта в базі даних.

5. Промпти (Prompts): наприклад, шаблон «АналізВідгуку» може включати кроки: прочитати відгук, виділити основні проблеми, підсумувати їх та запропонувати рішення. LLM може використовувати ці «заготовки» для побудови складних робочих процесів.

MCP у дії

Отже, ми вже знаємо, з яких компонентів складається Model Context Protocol (MCP) і як вони «розмовляють» між собою. Тепер подивімось, як усе це працює на практиці, на прикладі нашого інтернет-магазину посуду.

Уявіть, що ми під'єднали нашого ШІ-помічника до наших основних систем: CRM-системи (де зберігається вся історія клієнтів), бази даних товарів та складу (з усіма описами та наявністю), а також до нашої внутрішньої вікі-бази знань (де лежать статті та інструкції з догляду за посудом). Для кожної із цих систем ми створили свій MCP-сервер, який вміє «розмовляти» за протоколом MCP.

Як ШІ-помічник складе персональну пропозицію

Уявімо ситуацію, яку обговорювали раніше. Менеджер запитує: «Складіть індивідуальну пропозицію для клієнта, який два тижні тому дивився набір «Весняний луг», але не купив, бо його збентежила вартість доставки. Уточніть, чи є зараз на цей набір якісь знижки та запропонуйте йому вигідніші варіанти доставки».

Ось як наш ШІ-помічник, використовуючи MCP, проведе своє «розслідування»:

  1. Крок 1. Розуміємо завдання. Наш ШІ-помічник (наша LLM), отримавши запит, спочатку аналізує його. Він «розуміє», що йому потрібен комплекс даних: історія клієнта, інформація про конкретний товар, поточні акції та варіанти доставки.
  2. Крок 2. Вивчаємо клієнта. ШІ-помічник, дотримуючись своїх внутрішніх правил, по суті дивиться, які в нього є MCP сервери та їх опис і розуміє, куди за якими даними йти. Спочатку звертається до MCP-сервера CRM. Він «запитує» у нього: «Дай мені історію клієнта X, який дивився набір “Весняний луг”». Сервер CRM у відповідь каже: «Я вмію “отримати історію клієнта за ID” та “знайти клієнтів за переглянутими товарами”». LLM вибирає потрібний метод і запитує дані.
  3. Крок 3. Дізнаємося про товар. На основі історії клієнта LLM розуміє, що йдеться про набір «Весняний луг». Потім вона звертається до MCP-сервера бази даних товарів: «Дай мені всю інформацію про набір «Весняний луг»: його характеристики, наявність на складі, може навіть відгуки».
  4. Крок 4. Перевіряємо знижки. Отримавши дані про товар, LLM вирішує перевірити знижки. Вона звертається до MCP-сервера системи знижок: «Чи є зараз спеціальні знижки на набір «Весняний луг» і які додаткові знижки ми можемо запропонувати?»
  5. Крок 5. Шукаємо варіанти доставки. І, нарешті, LLM розуміє, що вартість доставки була проблемою. Вона звертається до MCP-сервера логістики: «Які є найвигідніші варіанти доставки для клієнта X та набору «Весняний луг», враховуючи його місцеперебування?»
  6. Крок 6. Збираємо та формуємо контекст. Отримавши всі ці дані від різних MCP-серверів, LLM, використовуючи принципи MCP, збирає їх воєдино. Вона відфільтровує зайве, виділяє найважливіше (наприклад, нову знижку та дешевий варіант доставки), пов'язує факти між собою і, можливо, робить проміжні уточнювальні запити, якщо щось незрозуміло. У підсумку вона формує повний, логічно вибудуваний та оптимізований «звіт» для самої себе.
  7. Крок 7. Генеруємо відповідь. На основі цього ретельно сформованого контексту LLM генерує персональну та переконливу пропозицію для клієнта.

Підсумок: Як бачите, LLM сама «вирішує», куди та за чим піти. Вона не просто отримує дані, а активно керує процесом їх збирання й обробки. MCP надає їй необхідні «інструменти» та «правила», щоб вона могла вести це «розслідування» і в підсумку сформувати ідеально точну та корисну відповідь.

Технології для побудови MCP-сервера: що використовуємо на практиці

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

Наш MCP-сервер — це як «адаптер», і справді його часто порівнюють з USB, тим інтерфейсом, який подружив усі зовнішні пристрої з комп'ютером. Сам собою він не містить усіх даних вашого магазину посуду і не виконує основні дії на кшталт оформлення замовлення. Його завдання — знати, як отримати потрібну інформацію чи виконати дію, звертаючись до вже наявних систем, а потім «перекласти» це у зрозумілий для ШІ формат.

Ось які технології ми зазвичай використовуємо:

1. Мови програмування. Найчастіше для написання MCP-серверів ми використовуємо Python. Він добре підходить для роботи з даними, взаємодії з різними системами та швидкої розробки. Але можна використовувати й інші мови, як-от Go, Node.js чи навіть Java, якщо вони краще підходять для конкретного завдання або вже використовуються у вашій інфраструктурі.

2. Фреймворки для створення мережевих сервісів. Щоб наш MCP-сервер міг «слухати» запити від Клієнта MCP та надсилати відповіді, ми використовуємо спеціальні програми-«помічники», які називаються фреймворками. Вони допомагають нам швидко створювати мережеві сервіси (по суті, мінісайти чи API), які можуть спілкуватися за протоколом MCP. Приклади таких фреймворків — FastAPI або Flask у Python.

3. Бібліотеки для роботи з даними. Щоб MCP-сервер міг отримувати інформацію з ваших систем, йому потрібні спеціальні «перехідники» чи бібліотеки.

  • Якщо дані зберігаються в базі даних (наприклад, SQL-база з товарами або замовленнями), ми використовуємо бібліотеки, які вміють «читати» та «писати» в ці бази.
  • Якщо інформація знаходиться в CRM-системі чи іншому хмарному сервісі, то MCP-сервер буде використовувати API цих сервісів. Це той самий звичайний API, з яким ви, можливо, вже знайомі. MCP-сервер просто виступає в ролі його користувача, запитуючи потрібні дані.
  • Для роботи з файлами (документами, таблицями) також є спеціальні бібліотеки, які дозволяють MCP-серверу читати вміст файлів та передавати його ШІ-помічнику.

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

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

Складнощі та обмеження Model Context Protocol

Як і будь-яка технологія, Model Context Protocol (MCP) має свої нюанси та обмеження. Цей розділ не для того, щоб вас налякати, а щоб ви могли будувати реалістичні очікування та ухвалювати зважені рішення.

Розгляньмо основні підводні камені, з якими ми стикаємося під час роботи з MCP:

1. Комплексність проєктування та налагодження: будуємо не просто будинок, а ціле місто. Якщо RAG — це як побудувати добротний будинок, то MCP — це вже проєктування та зведення цілого мікрорайону з безліччю будинків (серверів), доріг (з'єднань) та систем комунікацій. Кожен MCP-сервер, який ми створюємо, має бути ідеально налаштований для взаємодії з конкретною вашою системою (CRM, БД, зовнішнім API).

2. «Перевантаження» для ШІ-помічника. Хоча MCP і покликаний максимально ефективно збирати та форматувати контекст для LLM, у самої великої мовної моделі є обмеження за обсягом інформації, яку вона може обробити за один раз (те саме «вікно контексту»). Якщо ми зібрали дуже багато інформації, то наш запит виходить занадто великим чи містить занадто багато деталей, LLM усе одно може «забути» щось важливе з початку або заплутатися. Це явище іноді називають «проблемою контексту, що зникає».

3. Швидкість роботи та споживання ресурсів.

  • Швидкодія: пам'ятайте, наш сервер робить багато послідовних запитів до різних MCP-серверів. Кожен такий запит забирає час.
  • Споживання ресурсів: кожен виклик до MCP-сервера, кожна операція у ваших системах, кожен запит до API LLM — це споживання обчислювальних ресурсів, що, звісно, впливає на операційні витрати. Чим складніше агент, тим дорожче він коштуватиме.

4. Якість вихідних даних: «Сміття на вході — сміття на виході». MCP — це потужний інструмент для управління контекстом, але він не виправляє якість ваших вихідних даних. Якщо дані у вашій CRM застаріли, у базі товарів є помилки, а у вікі-базі лежать неточні інструкції, то й ШІ-помічник, попри всю свою «розумність» та здібності MCP, оперуватиме цими неправильними даними.

5. Обробка помилок та непередбачених ситуацій. Що станеться, якщо один з MCP-серверів тимчасово недоступний? Якщо зовнішній API, до якого звертається MCP-сервер, поверне помилку? Або якщо LLM запросить інструмент, який вона не повинна використовувати?

Як бачите, створення системи на базі Model Context Protocol — це серйозне інженерне завдання. Воно відкриває величезні можливості, але й вимагає глибокого розуміння всіх цих нюансів. Розуміння цих складнощів — перший крок до успішного створення насправді надійного та ефективного ШІ-помічника.

Часові рамки та приблизні витрати. Скільки коштує «побудувати» MCP-детектива

Коли ми говоримо про створення системи Model Context Protocol (MCP), важливо розуміти: це не просто встановлення програми, а повноцінний інженерний проєкт. Він складніший, ніж впровадження простого RAG, оскільки містити більше рівнів взаємодії та логіки. Тому і часові рамки, і витрати будуть відповідними.

Розгляньмо приблизні етапи й те, чого очікувати, якщо ви вирішите дати своєму ШІ-помічнику можливості «детектива»:

1. Проєктування та вибір технологій: «Розробка плану розслідування». На цьому етапі ми детально розбираємо, які саме завдання має виконувати ваш ШІ-помічник за допомогою MCP, до яких систем йому потрібен доступ (CRM, бази даних, файлові сховища) і як ці системи взаємодіятимуть. Ми вибираємо конкретні інструменти та підходи, які найкраще підійдуть для вашої інфраструктури.

  • Приблизні терміни: від 1 дня до 1 місяця. Час сильно залежить від складності ваших поточних систем та кількості джерел даних, до яких потрібно підключитися.

2. Розробка MCP-серверів та інтеграції. Після планування починається створення тих самих MCP-серверів, які будуть «перекладачами» між вашими наявними системами та ШІ-помічником. Ми пишемо код, який дозволяє MCP-серверам «слухати» запити від LLM та звертатися до ваших CRM, баз даних, API та інших джерел. Це включає очищення та підготовку даних, якщо вони «сирі».

Це найважливіший етап і найневизначеніший. Звичайно, у вас може бути тільки одна CRM, в якій зібрано все, але це буде CRM, створена під вас, без документації та можливості інтеграції. Доведеться писати не тільки MCP-сервер, а й API вашої CRM. Або у вас 5 сайтів, CRM, Wiki-база, ERP-система, і все це добре описано та має готові API. Такий проєкт буде набагато швидше зробити.

  • Приблизні терміни: від 15 днів до 6 місяців. Це може бути довше, якщо у вас багато різнорідних систем, що вимагають складної інтеграції, або дані вимагають значної попередньої обробки.

3. Налаштування логіки LLM та тестування. Коли MCP-сервери готові, ми вчимо саму LLM (ШІ-помічника) правильно використовувати нові «інструменти», які надає MCP. Це включає написання складних інструкцій (промптів), щоб LLM розуміла, коли і як викликати той чи той MCP-сервер, як обробляти отримані дані та формувати фінальну відповідь. Ми проводимо безліч тестів, ставлячи ШІ-помічнику найрізноманітніші, часом каверзні запитання, щоб переконатися, що він працює коректно, точно та швидко.

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

4. Оптимізація та розгортання. Коли система показує стабільні результати, ми проводимо фінальну оптимізацію, щоб покращити швидкість роботи та ефективно використовувати ресурси. Потім ми розгортаємо всю систему на серверах, роблячи її доступною для реального використання. Це фінальні штрихи перед тим, як ваш ШІ-помічник почне свої «розслідування» у бойовому режимі.

  • Приблизні терміни: від 2 днів до 1 місяця.

Загальна оцінка термінів та витрат

Для створення повноцінної, надійної MCP-системи, здатної виконувати складні завдання, зазвичай потрібно від 20 днів до 9 місяців і більше. Важливо розуміти, що це не просто проєкт, а, скоріше, створення та розвиток нової платформи для вашого бізнесу.

Приблизні витрати: вартість залежатиме від масштабу проєкту, складності інтеграцій та вибору технологій, але основні статті витрат такі:

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

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

MCP — ключ до розумних ШІ-помічників

Ну що ж, ось ми й підійшли до кінця нашої подорожі світом Model Context Protocol (MCP). Сподіваюся, мені вдалося показати вам, що за уявною «магією» розумних ШІ-помічників стоїть серйозна та захоплива робота, а MCP — це одна з найважливіших її цеглинок.

Наприкінці хочу поділитися своєю особистою думкою про потенціал MCP. Я вважаю, що MCP — це технологія майбутнього, і ми тільки починаємо бачити її потенціал. Для кращого розуміння, сам протокол був представлений у листопаді 2024 року, але в реальності про нього заговорили тільки з лютого 2025. А сьогодні майже не один агент не працює без MCP. Також можу сказати, що майже всі компанії, які працюють у сфері інтернету та даних, уже будують свої MCP-сервери (можливо, не публічні).

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

Щоб зрозуміти, як працює MCP, я рекомендую встановити Claude Desktop, а потім зайти на GitHub, щоб вивчити деякі MCP-сервери. Цікаві колекції ви можете знайти за цими посиланнями:

Якщо ви новачок на GitHub, просто прокрутіть вниз до розділу опису на цих сторінках, і ви знайдете посилання на самі MCP-сервери.

Як встановити MCP-сервер, можете подивитися в YouTube. Це дуже легко, але краще побачити наочно.

І ще кілька слів на завершення. Якщо в нашій попередній статті ми говорили про RAG (Retrieval-Augmented Generation) як про спосіб дати ШІ-помічнику доступ до «шпаргалок», навчити його шукати та знаходити потрібну інформацію з великих обсягів даних, то сьогодні ми розібралися з MCP.

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

Звичайно, побудова таких систем вимагає певних інвестицій часу та ресурсів. Важливо ретельно продумати архітектуру, забезпечити якість даних і, що критично важливо, подбати про безпеку, особливо якщо ви працюєте з конфіденційною інформацією. Але переваги, які дає MCP, — точніші, корисніші та складніші відповіді від ШІ, здатного виконувати реальні бізнес-завдання — з лишком окуповують ці вкладення.

У наступній статті ми поговоримо про донавчання моделей (Fine-tuning).

Але на цьому ми не закінчимо. Як я казав у попередній статті, у майбутньому в нас буде набагато більше можливостей. І ось ми вже в майбутньому. Ці технології так швидко розвиваються, що у нас з'явився ще один метод — протокол A2A від Google.

Як і минулого разу, пишіть коментарі або будь-які питання в особисті повідомлення.