Що таке MCP і як він дає ШІ доступ до інструментів

MCP простими словами

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

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

Кому MCP справді потрібен

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

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

Як працюють host, client і server

У специфікації є три ролі. Host — застосунок, у якому працює користувач: редактор, desktop-клієнт або власний AI-продукт. Усередині host створює окремий client для кожного підключеного сервера. Server — програма, що надає дані або дії.

1. Підключення. Host запускає локальний сервер через STDIO або звертається до віддаленого через Streamable HTTP.
2. Виявлення. Клієнт отримує версію протоколу, можливості та опис доступних функцій.
3. Вибір. Модель бачить назву інструмента, опис і схему аргументів та вирішує, чи потрібен виклик.
4. Підтвердження. Клієнт може показати людині майбутню дію й дані, які буде передано.
5. Виконання. Сервер робить операцію та повертає структурований результат, який потрапляє в контекст моделі.

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

Три базові можливості: tools, resources і prompts

У версії специфікації від 28 липня 2026 року також описані опційні розширення: довгі асинхронні задачі, структуровані skills і MCP Apps з інтерактивними формами чи графіками всередині сумісного клієнта. Це вже не лише «виклик функції», але підтримка складніших робочих процесів.

MCP і function calling — не одне й те саме

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

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

Що змінилося у MCP 2026-07-28

Багато гайдів 2025 року вже описують попередню архітектуру. Актуальна специфікація зробила протокол stateless: із ядра прибрали сесії, заголовок Mcp-Session-Id та початковий handshake initialize. Версія протоколу й можливості клієнта тепер передаються в метаданих кожного запиту.

• сервер зобов’язаний підтримувати server/discover для оголошення версій, можливостей та ідентичності;
• зміни списків tools, prompts і resources можуть надходити через новий subscriptions/listen;
• довгі tasks винесені з ядра в офіційне розширення;
• Roots, Sampling і Logging позначені застарілими для нових реалізацій;
• старий HTTP+SSE остаточно позначений deprecated — нові сервери мають орієнтуватися на Streamable HTTP;
• результати списків отримали підказки для кешування, щоб зменшити затримку й повторні запити.

Безпечний маршрут підключення MCP

1. Сформулюйте одну задачу. Не підключайте «весь GitHub» заради експерименту. Почніть, наприклад, із читання issues одного тестового репозиторію.
2. Знайдіть офіційний сервер. Віддавайте перевагу серверу, який публікує сам власник сервісу. Перевірте домен, репозиторій, документацію та дату оновлення.
3. Видайте мінімальні права. Окремий тестовий акаунт або токен лише для читання кращий за головний ключ із повним доступом.
4. Обмежте інструменти. Якщо клієнт дозволяє allowlist, залиште тільки потрібні tools. Менше інструментів означає нижчу вартість, меншу затримку й меншу площу ризику.
5. Не вимикайте підтвердження. Для створення, видалення, платежів, публікації та надсилання повідомлень людина має бачити й схвалювати дію.
6. Перевірте журнал. Подивіться фактичні аргументи й відповіді сервера. Не тестуйте на персональних даних, секретах або робочій базі.

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

Типові помилки

• Встановлювати випадковий пакет через одну команду. Команда може завантажити й виконати сторонній код. Перевіряйте власника та джерело.
• Давати повний диск. Для файлового сервера дозвольте окрему тестову папку, а не домашній каталог.
• Зберігати секрет у JSON-конфігурації репозиторію. Використовуйте змінні середовища або менеджер секретів і ніколи не комітьте реальний токен.
• Довіряти опису tool. Опис надходить від сервера і сам по собі не доводить, що функція поводиться саме так.
• Автоматично схвалювати запис. Prompt injection у сторінці, issue або документі може підштовхнути агента до небажаної дії.
• Плутати MCP із моделлю. Якість відповіді, контекстне вікно та ціна токенів залежать від моделі; MCP лише з’єднує її із зовнішніми можливостями.

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

Короткий чекліст

• Є конкретна задача, для якої MCP кращий за прямий API.
• Сервер походить від відомого власника або перевіреного репозиторію.
• Права обмежені тестовими даними й мінімальним scope.
• Доступні моделі лише потрібні tools.
• Дії із записом вимагають явного підтвердження.
• Аргументи та відповіді журналюються без збереження секретів.
• Сценарій перевірений на prompt injection і помилковий вибір tool.
• Версія SDK сумісна зі специфікацією, на яку ви орієнтуєтесь.

Часті запитання

Чи треба програмувати, щоб користуватися MCP?

Не завжди. Деякі AI-застосунки підключають віддалені сервери через інтерфейс. Але для локального сервера часто доведеться встановити середовище, змінити конфігурацію та розуміти дозволи.

Чи можна довіряти каталогу MCP-серверів?

Каталог допомагає знайти варіанти, але не замінює перевірку. Важливі власник, репозиторій, домен віддаленого сервера, запитані права й політика даних.

Чи зникає потреба в API-ключах?

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

З чого почати практично?

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