MCP: як це працює та коли не варто застосовувати

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Всім привіт. Мене звати Владислав, я працюю Senior Software Engineer у MEV. Раніше я писав тут про те, як за допомогою Cursor Rules навчити AI працювати з вашим проєктом.

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

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

Що таке MCP

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

По суті, MCP розв’язує практичну проблему: до появи MCP кожен AI-застосунок потребував власної кастомної інтеграції з кожним зовнішнім сервісом. Якщо ви хотіли, щоб ваш AI-асистент отримував доступ до GitHub, Slack і бази даних, вам довелося б писати окремий код для кожного з них. MCP змінює це, пропонуючи єдиний протокол, який працює з різними інструментами та AI-моделями.

MCP-сервер відкриває інструменти (наприклад, «пошук у вебі» чи «запит до бази даних») у стандартному форматі. MCP-клієнт (на кшталт Cursor чи Claude Code) може під’єднатися до будь-якого MCP-сервера й одразу зрозуміти, які інструменти доступні, навіть якщо розробники з обох боків ніколи не узгоджували інтеграцію між собою.

Як працює MCP

Учасники

MCP використовує просту клієнт-серверну архітектуру:

• MCP host — AI-застосунок (наприклад: Claude Code, Claude Desktop, VS Code).
• MCP client — об’єкт з’єднання, який хост створює для кожного сервера. Один сервер = один клієнт.
• MCP server — програма, що надає інструменти, ресурси та промпти.

Приклад: VS Code виступає MCP-хостом. Коли він підключається до MCP-сервера Sentry, він створює окремий MCP-клієнт для цього сервера. Якщо також підключається до файлової системи, створюється другий клієнт.

Кожен клієнт взаємодіє строго з одним сервером.

Локальні та віддалені сервери

Сервери можуть працювати локально або віддалено:

• Локальний MCP-сервер працює безпосередньо на вашій машині та зазвичай взаємодіє з клієнтом через легкий транспорт, наприклад stdio.
  Це підходить, коли інструменти чи дані, які потрібні моделі, знаходяться на вашому комп’ютері або всередині середовища розробки.
• Віддалений MCP-сервер працює на зовнішній інфраструктурі — у хмарі чи у внутрішніх корпоративних сервісах. Зазвичай він використовує HTTP або інший мережевий транспорт. Такий варіант підходить, коли інструменти чи дані централізовані, спільні для команди, або до них потрібно отримувати доступ із різних місць.

Layers (Рівні)

MCP складається з двох рівнів:

• Data layer (рівень даних): визначає JSON-RPC-повідомлення, життєвий цикл, інструменти, ресурси, промпти, нотифікації.
• Transport layer (транспортний рівень): визначає, як передаються повідомлення (stdio або HTTP), включаючи фреймінг і автентифікацію.

Сам протокол залишається однаковим незалежно від транспорту.

Управління життєвим циклом

MCP-клієнт і MCP-сервер узгоджують:

• версію протоколу;
• підтримувані можливості;
• доступні примітиви;
• розмежування ролей.

Ця взаємодія гарантує, що обидві сторони говорять однією мовою.

Primitives (Примітиви)

Примітиви визначають, яку інформацію та дії MCP-сервер може надати.

Server Primitives (Примітиви сервера)

Tools (інструменти)

Дії, які AI-застосунок може викликати. Інструменти — це виконувані функції, що надаються сервером. LLM може викликати їх для реальних операцій: читати файли, робити API-запити, виконувати пошук, надсилати запити до бази даних тощо.

Приклад: GitHub MCP-сервер надає інструмент repos_list_open_pull_requests.

Коли користувач каже:"Покажи всі відкриті PR для репозиторію нашого мобільного застосунку«, LLM може безпосередньо викликати:

tools/call:
  name: "repos_list_open_pull_requests"
  arguments:
    repo: "mobile-app"

Сервер відповідає структурованими даними, що описують кожен PR.

Resources (ресурси)

Контекстні дані, які AI-застосунок може читати. Ресурси надають LLM доступ до інформації лише для читання, яку модель може використати для аналізу, планування чи прийняття рішень.

Це можуть бути:

• вміст файлів;
• налаштування середовища;
• схеми баз даних;
• метадані репозиторію;
• конфігураційні файли;
• будь-які інші структуровані дані, доступні для читання.

Приклад: MCP-сервер файлової системи може відкрити ресурс, наприклад:

resource: "/workspace/package.json"

Якщо користувач запитує: «Чи використовує цей проєкт TypeScript?», то AI-застосунок може викликати resources/read для /workspace/package.json, переглянути devDependencies і потім дати точну відповідь на основі реальних даних, а не припущень.

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

Prompts (Промпти)

Шаблони, що керують взаємодією LLM. Промпти — це багаторазові шаблони, розміщені на сервері. Вони допомагають клієнту створювати узгоджені інструкції для LLM щодо використання інструментів сервера.

Приклад: MCP-сервер векторного пошуку містить промпт semantic_query_guide, який містить:

• інструкції, як формулювати пошукові запити;
• приклади коректних і некоректних запитів;
• рекомендації щодо fallback-поведінки.

Коли LLM потрібна допомога для формування запиту до векторного пошуку, вона може отримати цей промпт через prompts/get, підставити запит користувача і сформувати правильно структурований виклик інструменту.

Ще один приклад: аналітичний сервер може надавати промпт sql_safe_query_template, який містить:

• шаблони для написання безпечних SQL-запитів;
• перелік дозволених операцій;
• приклади «очищених» (sanitized) запитів.

LLM використовує цей промпт кожного разу, коли формує SQL-запити через інструменти сервера.

Client primitives (Примітиви клієнта)

Sampling (Семплінг)

MCP-сервер просить хост-LLM згенерувати текст. Сервер може запитати завершення моделі, не маючи в собі власного LLM.

Приклад: Уявімо, що MCP-сервер бази даних надає інструмент «smart query builder». Користувач пише нечіткий запит: «Знайди всіх клієнтів, які замовляли щось велике торік».

Серверу потрібен чистий SQL-запит, але він не хоче вбудовувати LLM. Тоді він надсилає запит семплінгу хосту: «Перепиши цей запит природною мовою в безпечний SQL».

Хост-LLM повертає, наприклад:

SELECT * FROM orders WHERE size = 'large' AND year = 2024;

Сервер використовує цей SQL-запит для виконання інструменту.

Elicitation (Уточнення)

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

Приклад: файловий MCP-сервер має інструмент delete_file. Якщо LLM пропонує «Видали /Users/username/Documents/2023-report.pdf», то сервер не хоче виконувати операцію без підтвердження.

Він надсилає запит:

«Сервер потребує підтвердження користувач: «Ви впевнені, що хочете видалити цей файл?» Користувач у своєму IDE бачить:

Do you want to delete 2023-report.pdf?
[Yes] [No]

Відповідь передається серверу — і лише після цього дія продовжується.

Logging (Логування)

MCP-сервер надсилає логи клієнту для налагодження та прозорості.

Приклад: хмарний MCP-сервер S3 завантажує великий файл і надсилає логи:

• «Upload started...»;
• «Uploaded 40%...»;
• «File too large, attempting multipart upload...»;
• «Upload complete».

Ці повідомлення відображаються в панелі логів або консолі AI-застосунку.

Notifications (Сповіщення)

MCP-сервер може надсилати оновлення в реальному часі без запитів.

Приклад: якщо список інструментів змінюється, сервер надсилає notifications/tools/list_changed, і клієнт одразу отримує оновлений список.

Example Flow (Приклад процесу)

Нижче наведено простий наскрізний процес, який показує, як MCP-клієнт взаємодіє з MCP-сервером.

Initialization (Ініціалізація)

MCP-клієнт надсилає: версію протоколу, підтримувані можливості, інформацію про клієнта. MCP-сервер відповідає своїми можливостями. Якщо все узгоджується — з’єднання готове.
Після цього MCP-клієнт надсилає notifications/initialized.

Цей етап гарантує, що обидві сторони знають:

• Які версії вони використовують.
• Які функції підтримують.
• Які примітиви застосовуватимуть.

Tool Discovery (Виявлення інструментів)

MCP-клієнт запитує tools/list. MCP-сервер відповідає повним списком доступних інструментів, зокрема: назвою, заголовком, описом, схемою вхідних даних.

AI-застосунок збирає інструменти з усіх MCP-серверів і об’єднує їх у єдиний реєстр, який може використовувати LLM.

Tool Execution (Виконання інструментів)

Коли потрібен інструмент, MCP-клієнт надсилає tools/call із:

• Точною назвою інструменту.
• Аргументами, що відповідають його схемі.

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

Real-time Updates (Оновлення в реальному часі)

Якщо MCP-сервер додає або видаляє інструменти, він надсилає notifications/tools/list_changed. MCP-клієнт тоді отримує оновлений список через tools/list.

Це дає змогу підтримувати актуальний реєстр інструментів AI-застосунка без постійного опитування.

Використання MCP на практиці

Використання MCP залежить від того, чи ви використовуєте його як споживач, чи створюєте власний сервер.

Як споживач

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

Вибір MCP-клієнта

Починаєте зі сторони клієнта. Найпоширеніші варіанти: Claude Desktop, Claude Code, Cursor, VS Code, Codex або інші MCP-сумісні застосунки зі списку:
modelcontextprotocol.io/clients

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

Пошук MCP-серверів

Переглянути MCP-сервери можна тут:

modelcontextprotocol.io/examples

github.com/...​elcontextprotocol/servers

Додавання серверів у вашому клієнті

Сторінка кожного MCP-сервера зазвичай містить інструкції інтеграції для конкретних клієнтів. Наприклад, Playwright MCP має чіткий розділ «Getting started»: github.com/...​right-mcp#getting-started

Що відбувається після підключення

Після того як клієнт налаштований:

1. Клієнт запускає сервер або під’єднується до нього.
2. Сервер повідомляє про свої інструменти та ресурси.
3. Клієнт робить ці інструменти доступними для LLM.
4. Модель починає викликати інструменти щоразу, коли вони потрібні у вашому робочому процесі.

Нічим не потрібно керувати вручну. Клієнт обробляє всю комунікацію, сервер — всю логіку виконання, а модель просто використовує ті інструменти, які ви зробили доступними.

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

• Використай Context7 MCP, щоб отримати найновішу документацію React для useTransition, а потім реалізуй React-компонент, який показує стан завантаження, поки виконується важка операція.
• Отримай найновішу документацію React Router за допомогою Context7 MCP і перепиши мою конфігурацію маршрутизації так, щоб вона відповідала рекомендованим патернам версії v7.
• Використай GitHub MCP, щоб отримати issue № 142. Підсумуй проблему та згенеруй зміни у коді, необхідні для її виправлення.
• Використай GitHub MCP, щоб отримати мій PR № 154, прочитай усі коментарі код-рев’ю та запропонуй зміни в кодовій базі, необхідні для їх врахування.
• Використай Sentry MCP, щоб отримати найсвіжішу production-помилку. Підсумуй стек-трейс і покажи, на якій саме стрічці нашого коду відбувається збій.
• Використай Sentry MCP, щоб отримати останню production-помилку. Потім використай GitHub MCP, щоб знайти файл і стрічку, де сталася помилка, і запропонуй патч, який її виправляє.
• Використай Figma MCP, щоб отримати найновіший дизайн-фрейм для екрана Dashboard і згенеруй React-компоненти, що відповідають візуальній структурі.
• Використай Postgres MCP, щоб показати всі акаунти, створені за останні 24 години, і згенеруй звіт про активних та неактивних користувачів.

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

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

Створення власного MCP

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

Створення MCP-сервера є простим завдяки офіційним SDK. Незалежно від того, чи використовуєте ви TypeScript, Python або іншу мову, документація містить чіткі приклади, які допоможуть вам розпочати роботу: modelcontextprotocol.io/docs/sdk

Коли варто використовувати MCP

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

Наприклад:

• Context7 MCP, щоб надати LLM прямий доступ до найновішої документації бібліотек, які ви використовуєте;
• Atlassian MCP, щоб LLM міг автоматично отримувати Jira-тікети або сторінки Confluence без ручного копіювання та вставляння у чат;
• Figma MCP, щоб LLM міг аналізувати дизайн-файли, витягувати їх і генерувати UI-компоненти, які відповідають вашим реальним дизайн-специфікаціям.

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

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

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

Недоліки та обмеження

Перевантаження контексту

MCP-сервери додають свої визначення інструментів безпосередньо в контекст моделі. Насичений сервер, такий як GitHub, може займати 50 000+ токенів лише для опису своїх інструментів. Додайте ще кілька серверів — і ви вже витрачаєте 60 000–70 000 токенів, ще до того, як модель прочитає ваш запит.

Це призводить до:

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

Нещодавня стаття команди Anthropic підкреслює ці недоліки:
www.anthropic.com/...​g/code-execution-with-mcp

Хочу зазначити, що компанії активно працюють над оптимізацією цього процесу. Наприклад, Anthropic нещодавно внесла покращення та представила «Tool Search Tool» — інструмент, який автоматично знаходить потрібні інструменти за потреби. Детальніше про це можна прочитати тут: www.anthropic.com/...​neering/advanced-tool-use

Надмірне навантаження на продуктивність

Кожен виклик інструменту перериває генерацію:

• Модель зупиняється.
• Інструмент виконується.
• Результат інструменту повертається в контекст.
• Модель знову починає генерувати.

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

Виклик інструментів є неприродним для моделей

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

• Моделі галюцинують синтаксис викликів інструментів.
• Ігнорують інструмент повністю.
• Обирають неправильний інструмент, коли їх забагато.
• Неправильно формують параметри.
• Заходять у цикли не в той бік.
• Забагато інструментів перевантажує модель.

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

Тому краще явно називати MCP-сервер у запиті, наприклад:
«використай Context7 MCP, щоб отримати найактуальнішу документацію».

Ризики безпеки та довіри

Коли AI отримує можливість виконувати дії, поверхня атаки неминуче збільшується.

Основні ризики:

• Потенційно небезпечні дії, якщо модель неправильно інтерпретує інструкції.
• Необхідність пісочниць, коли моделі виконують код. Без ізоляції модель може отримати доступ до хост-системи несподіваними способами.
• Prompt injection, особливо коли сервери отримують неперевірений контент (документація, вебсторінки тощо).
• Витоки даних, якщо сторонні сервери отримують доступ до вашої інформації.

Cloudflare та інші тепер виконують увесь код, згенерований моделями, у жорстко ізольованих пісочницях із дозволеними (whitelisted) API, тому що ризики реальні.

Порівняння MCP з іншими підходами

MCP проти API виклику функцій

OpenAI, Anthropic та інші провайдери пропонують власні механізми виклику функцій у своїх API. Вони насправді дуже схожі на MCP: ви визначаєте функції зі схемами, і модель «вчиться», коли їх викликати.

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

MCP проти Skills

Anthropic нещодавно представив Skills — папки, що містять markdown-інструкції та скрипти, які пояснюють моделям, як виконувати завдання. Skills простіші за MCP, оскільки:

• не потребують знання протоколу;
• не потребують налаштування серверів;
• достатньо просто розмістити markdown-файли в директорії.

Попри простоту, Skills можуть бути потужними, тому що використовують те, у чому моделі найсильніші: читання тексту та написання коду.

MCP проти генерації коду

Cloudflare та інші компанії виявили, що замість того, щоб моделі прямо викликали MCP-інструменти, набагато ефективніше дозволити моделям писати код TypeScript або Python, який сам викликає ці інструменти. Код потім виконується у захищеній пісочниці.

Це цікаво з кількох причин:

• Моделі тренувалися на величезній кількості реального коду, але майже не тренувалися на синтаксисі інструментальних викликів.
• Вони природно краще пишуть код, ніж викликають інструменти.
• Коли ті самі можливості подаються як TypeScript API, а не як MCP-визначення інструментів, моделі використовують на 98% менше токенів і працюють значно краще.

Підхід «code mode» також дозволяє моделі ефективніше компонувати операції:

• замість циклу: виклик інструменту → чекати результат → наступний виклик → знову чекати (і щоразу збільшувати контекст);
• модель пише код, який виконує увесь робочий процес цілісно;
• і повертає лише фінальний результат.

Докладніше тут:

• blog.cloudflare.com/code-mode
• lucumr.pocoo.org/2025/7/3/tools

Найкращі практики

• Тримайте набір MCP невеликим і сфокусованим. Моделі працюють гірше, коли мають занадто багато інструментів. Якщо помічаєте падіння якості, перевірте, скільки MCP доступно моделі. Видаляйте непотрібні або тримайте їх вимкненими за замовчуванням і вмикайте лише тоді, коли конкретне завдання потребує певного інструменту.
• Правильно визначайте область застосування MCP. Використовуйте user-level scope для персональних MCP, потрібних у різних проєктах. Використовуйте project-level scope для командних MCP, які мають бути під контролем версій.
• Стежте за використанням контексту. Використовуйте інструменти на кшталт команди /context у Claude Code, щоб бачити, скільки контексту споживає кожен MCP-сервер.
• Регулярно переглядайте дозволи MCP. Використовуйте процеси затвердження для інструментів, які можуть змінювати дані. Багато MCP-клієнтів дозволяють вимагати ручне підтвердження перед виконанням певних операцій. Надавайте лише мінімально необхідні дозволи. Наприклад, Atlassian MCP може мати доступ лише до читання Jira-тікетів, але без створення, оновлення чи видалення.
• Іноді MCP — це зайве. Не кожне завдання потребує MCP-сервера. Іноді просте копіювання-вставлення працює швидше й ефективніше.
• Не використовуйте MCP лише тому, що це модно. Застосовуйте MCP лише тоді, коли вони дійсно потрібні. Часто простіше рішення працює краще.

Популярні MCP-сервери

• GitHub — працює з репозиторіями, дає змогу переглядати pull requests, створювати issues та виконувати операції з кодом.
• Playwright — надає можливості автоматизації браузера.
• Context7 — здійснює пошук документації в різних бібліотеках і фреймворках.
• Atlassian — під’єднується до Jira та Confluence.
• Sentry — допомагає відстежувати помилки, читати stack traces та аналізувати проблеми у продакшені.
• Figma — надає AI доступ до дизайн-файлів, щоб він міг генерувати код або переглядати UI-деталі.
• Slack — забезпечує можливості керування каналами та обміну повідомленнями.
• Sequential Thinking — забезпечує динамічне, покрокове мислення та рефлексивне розв’язання задач.
• Serena — зберігає контекст між сесіями, щоб модель пам’ятала, над чим ти працював.

Більше MCP-серверів:

• modelcontextprotocol.io/examples
• github.com/...​elcontextprotocol/servers

Підсумок

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

Корисні джерела

• Model Context Protocol (MCP) documentation: modelcontextprotocol.io/...​ocs/getting-started/intro
• Code execution with MCP: Building more efficient agents (Anthropic): www.anthropic.com/...​g/code-execution-with-mcp
• Introducing advanced tool use on the Claude Developer Platform (Anthropic):
  www.anthropic.com/...​neering/advanced-tool-use
• Code Mode: the better way to use MCP (Cloudflare): blog.cloudflare.com/code-mode
• Tools: Code Is All You Need: lucumr.pocoo.org/2025/7/3/tools

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.