Uk
En
Fr
De
It
Es
Що таке MCP-сервер?
MCP-сервер - це програма, яка дає ШІ-асистентам змогу користуватися продуктом: вона відкриває дії та дані продукту через Model Context Protocol (MCP), тож модель на кшталт Claude чи ChatGPT може шукати інформацію й виконувати дії від імені користувача. Уявіть його як API, створений для ШІ-клієнтів, а не для розробників-людей.
Model Context Protocol - відкритий стандарт, який Anthropic представила в листопаді 2024 року, щоб розв'язати повторювану проблему: кожному ШІ-застосунку був потрібен окремий код для підключення до кожного інструмента. MCP визначає один спільний спосіб, у який ШІ-застосунок (клієнт, його також називають хостом) дізнається, що пропонує сервер, і викликає це. Повідомлення використовують JSON-RPC 2.0. Щойно продукт має MCP-сервер, будь-який MCP-сумісний асистент може підключитися до нього без окремої інтеграції, подібно до того, як будь-який браузер може відкрити будь-який сайт, що працює за HTTP.
Що відкриває MCP-сервер?
MCP-сервер відкриває три види можливостей: інструменти, ресурси й промпти. Інструменти використовуються найширше; ресурси й промпти - корисні доповнення залежно від продукту й того, що підтримує клієнт.
| Можливість | Що це | Хто вирішує її використати | Приклад у SaaS для керування проєктами |
|---|---|---|---|
| Інструменти (tools) | Функції, які може викликати модель, з назвою, описом і JSON-схемою вхідних даних | Модель, зазвичай із підтвердженням користувача | create_task, update_status, log_time, search_tasks |
| Ресурси (resources) | Дані для читання, ідентифіковані URI | Застосунок або користувач | README проєкту, звіт по спринту, документ |
| Промпти (prompts) | Шаблони промптів із параметрами для повторного використання | Користувач, часто як slash-команда | "Підсумуй цей спринт", "Підготуй чернетку release notes" |
Добрий опис інструмента важить стільки ж, скільки код за ним. Модель вирішує, який інструмент викликати, на основі його назви, опису й схеми вхідних даних, тож розмиті описи призводять до хибних викликів. Результати інструментів мають бути компактними й читабельними: повертайте поля, потрібні моделі, а не весь рядок бази даних із п'ятдесятьма колонками.
Протокол також визначає можливості, що працюють у зворотному напрямку, від клієнта до сервера, як-от запит у користувача відсутніх даних (elicitation) чи запит на генерацію моделлю (sampling). Їх підтримка залежить від клієнта, тож більшість продакшен-серверів насамперед покладаються на інструменти.
Як підключається MCP-сервер: stdio чи HTTP?
MCP-сервери підключаються через один із двох стандартних транспортів: stdio для локальних серверів, що працюють на комп'ютері користувача, і HTTP (транспорт "Streamable HTTP") для віддалених серверів, що працюють у хмарі. SaaS-продуктові майже завжди потрібен віддалений HTTP-сервер.
| stdio (локальний) | Streamable HTTP (віддалений) | |
|---|---|---|
| Де працює | Як процес, який запускає ШІ-клієнт на комп'ютері користувача | На ваших серверах, доступний за URL |
| Встановлення | Користувач встановлює й налаштовує його | Користувач додає URL і входить у систему |
| Типове використання | Інструменти розробників, файлова система, локальні бази даних, CLI | SaaS-продукти, спільні корпоративні системи |
| Автентифікація | Зазвичай токен чи ключ у локальній конфігурації | Авторизація на основі OAuth для кожного користувача |
| Оновлення | Кожен користувач оновлює свою копію | Ви розгортаєте один раз для всіх |
| Логування й контроль | На комп'ютері користувача | Централізовано, під вашим контролем |
Ранні версії специфікації використовували для віддалених серверів окремий транспорт HTTP плюс Server-Sent Events; у 2025 році його замінив транспорт Streamable HTTP. Якщо оцінюєте старіший сервер чи SDK, перевірте, який транспорт він реалізує, бо новіші клієнти очікують поточний.
Як працює автентифікація MCP-сервера?
Віддалені MCP-сервери автентифікують користувачів через OAuth: асистент переводить користувача на екран входу й згоди вашого продукту, отримує токен доступу й пред'являє його з кожним запитом. Сервер потім діє з правами саме цього користувача.
Специфікація авторизації MCP спирається на OAuth 2.1 та пов'язані стандарти, зокрема метадані, які повідомляють клієнтам, де розташований ваш сервер авторизації. На практиці це означає:
- Користувач додає URL вашого сервера у свого асистента.
- Асистент знаходить ваш сервер авторизації й запускає OAuth-процес.
- Користувач входить у ваш продукт і схвалює запитаний доступ.
- Кожен виклик інструмента містить токен, обмежений цим користувачем і цими правами.
Два правила запобігають більшості проблем із безпекою. По-перше, сервер має перевіряти, що токени видано саме для нього, і не передавати токен клієнта іншим сервісам. По-друге, права мають перевірятися на сервері для кожного виклику, так само як це робить ваш вебзастосунок. Для внутрішніх інструментів і ранніх прототипів поширене спрощення - API-ключ на користувача, але SaaS для клієнтів має використовувати повноцінний OAuth.
Коли SaaS-продукту варто випускати MCP-сервер?
SaaS-продуктові варто випустити MCP-сервер, коли клієнти вже використовують ШІ-асистентів у роботі й виграли б від того, щоб просити цих асистентів читати чи змінювати дані в продукті. Якщо користувачі регулярно копіюють дані з вашого застосунку в ChatGPT чи Claude або просять "інтеграцію з ШІ", це і є сигнал.
Добрі причини його створити:
- Ваш продукт зберігає робочі дані, які люди хочуть підсумовувати, шукати чи оновлювати: завдання, тікети, записи CRM, документи, замовлення, аналітику.
- Дії повторюються: створення записів, зміна статусів, облік часу, підготовка чернеток відповідей.
- Клієнти просять функцій ШІ, а ви хочете дати їм це без створення повноцінного асистента всередині продукту.
- Дистрибуція: ШІ-асистенти дедалі частіше показують і рекомендують конектори, тож присутність там ставить ваш продукт туди, де користувачі вже працюють.
Причини зачекати: продукт ще не має стабільного API, дані дуже чутливі, а ваша модель прав недостатньо детальна, або ключовий процес візуальний і не перекладається на дії, які може виконати модель. У таких випадках спершу виправте API та права доступу або почніть з інструментів лише для читання.
MCP-сервер не замінює функції ШІ всередині продукту. Він їх доповнює: функції в продукті обслуговують користувачів у вашому інтерфейсі, а MCP - тих, хто живе у своєму асистенті. Якщо ви обираєте між цими двома варіантами, наш посібник з інтеграції ChatGPT або Claude у застосунок описує бік функцій усередині продукту.
Які ризики безпеки мають MCP-сервери?
Основні ризики - prompt injection, надто широкі права, руйнівні дії без підтвердження та витік даних між користувачами. MCP-сервер дає моделі змогу діяти, тож саме сервер, а не модель, має бути місцем, де застосовуються обмеження.
- Prompt injection: текст усередині документа, листа чи вебсторінки може наказати моделі викликати інструменти, яких користувач не мав на увазі. Виходьте з того, що вхідні дані інструментів можуть бути підробленими, і перевіряйте їх, як будь-які неперевірені дані.
- Отруєння описів інструментів: клієнтам варто підключатися лише до серверів, яким вони довіряють, бо шкідливі описи можуть спрямовувати модель. Як постачальник, тримайте описи фактичними й стабільними.
- Надто широкі права: давайте токенам мінімально потрібні права. Пропонуйте права лише на читання клієнтам, яким потрібні лише пошук і підсумки.
- Руйнівні дії: уникайте або чітко позначайте видалення й масові операції; надавайте перевагу м'якому видаленню й чернеткам. Багато клієнтів просять користувача підтверджувати виклики інструментів, але не покладайтеся лише на це.
- Витоки між клієнтами: кожен запит має бути обмежений автентифікованим користувачем і організацією, і це мають підтверджувати тести.
- Ліміти запитів і витрати: зациклена модель може викликати інструмент сотні разів. Застосовуйте ліміти запитів на користувача.
- Журнали аудиту: записуйте, який користувач, який клієнт і який інструмент, із вхідними даними й результатами, щоб клієнти бачили, що робив їхній асистент.
Як створюється MCP-сервер?
MCP-сервер зазвичай створюють за допомогою одного з офіційних SDK (є для TypeScript, Python та кількох інших мов) як тонкий шар поверх наявного API чи сервісного рівня. Робота стосується не так протоколу, як вибору правильних інструментів і забезпечення прав доступу.
Типовий проєкт проходить такі кроки:
- Обрати завдання: перелічити 5-20 завдань, які користувачі просили б асистента виконати у вашому продукті. Менше інструментів з добрими описами краще, ніж інструмент на кожен endpoint.
- Спроєктувати інструменти: зрозумілі назви, описи, написані для моделі, типізовані схеми вхідних даних, компактні результати й корисні повідомлення про помилки, після яких модель може виправитися.
- Авторизація: OAuth для віддалених серверів, права на рівні користувача для кожного виклику, окремі права на читання й запис.
- Безпечні налаштування за замовчуванням: чернетки замість негайної публікації, підтвердження для незворотних дій, ліміти на масові операції.
- Тестування з реальними клієнтами: підключити Claude, ChatGPT та інструмент розробника, виконати реалістичні запити й перевірити, що модель обирає правильні інструменти з правильними аргументами.
- Спостережуваність: логування, метрики для кожного інструмента й сповіщення про сплески помилок.
Для продукту з чистим API перший віддалений сервер зазвичай потребує 2-6 тижнів. Якщо вашому продуктові потрібні функції ШІ понад MCP, як-от агенти, що самостійно виконують робочі процеси, дивіться наш посібник скільки коштує ШІ-агент.
Як ми створюємо MCP-сервери в Lytvynov Production?
Спершу ми створюємо MCP-сервери для власних продуктів. І наша внутрішня дошка проєктів, і CMS нашого сайту мають MCP-сервери, тож наша команда й наші ШІ-агенти для написання коду щодня створюють і оновлюють завдання, обліковують час і редагують вміст сайту з Claude та інших асистентів. Це щоденне використання показало нам, де такі сервери ламаються: розмиті описи інструментів, відсутня перевірка полів, інструменти запису, що публікують одразу, хоча чернетка була б безпечнішою, і розбіжності між кодом сервера та тим, що насправді розгорнуто.
Для клієнтів ми застосовуємо той самий підхід до SaaS-продуктів і внутрішніх систем. Ми створювали системи завдань і тікетів, як-от платформу керування завданнями на замовлення для команди підтримки телеком-компанії, та функції на LLM у нашому власному SaaS AI Resume Master. Наш бекенд-стек - PHP/Symfony з фронтендом на React, а MCP-сервери ми пишемо мовою, що пасує вашому продукту, поверх вашого наявного API та моделі прав доступу.
Наступний крок
Якщо ви розглядаєте MCP-сервер для свого продукту, ми починаємо з короткої розмови для оцінки обсягу: переглядаємо ваше API та права доступу, обираємо перший набір інструментів, а після цього даємо фіксовану ціну. Перегляньте нашу послугу інтеграції ШІ та розробки ШІ-агентів або зв'яжіться з нами, щоб обговорити ваш продукт.
