Кожен проєкт з AI-агентами рано чи пізно впирається в ту саму стіну: модель розумна, але не бачить вашої CRM, ERP чи внутрішньої вікі. Донедавна кожне підключення було окремою інтеграцією, написаною під одного вендора моделі й один застосунок. Model Context Protocol (MCP) це змінює: він дає AI-застосункам єдиний відкритий спосіб працювати з інструментами та даними. У гайді розбираємо, що таке MCP, коли його варто впроваджувати, як спроєктувати MCP-сервер для бізнес-системи і як зробити його безпечним.
Що таке MCP одним абзацом
MCP — відкритий протокол, що стандартизує підключення AI-застосунків до зовнішніх джерел даних та інструментів. Anthropic представила його в листопаді 2024 року (Anthropic, 2024), а в грудні 2025-го протокол передали в Agentic AI Foundation — нейтральний фонд під егідою Linux Foundation, серед платинових учасників якого AWS, Anthropic, Google, Microsoft і OpenAI (Linux Foundation, 2025). Специфікація версіонується датами; актуальна ревізія — 2026-07-28.
Найкраща аналогія — зі самої специфікації: MCP робить для AI-інструментів те, що Language Server Protocol зробив для редакторів коду. Замість того щоб кожен редактор підтримував кожну мову окремо, кожна мова постачає один сервер, і ним може користуватися будь-який редактор.
Як працює MCP: host, client і server
Повідомлення MCP передаються у форматі JSON-RPC 2.0 між трьома ролями (специфікація MCP):
- Host — AI-застосунок, у якому працює користувач: чат, IDE, внутрішній асистент.
- Client — конектор усередині host, що підтримує з'єднання з одним сервером.
- Server — сервіс, що надає контекст і можливості, наприклад «наша CRM» чи «наше сховище документів».
Сервери пропонують три типи можливостей:
| Можливість | Хто керує | Приклад у бізнес-системі |
|---|---|---|
| Tools (інструменти) | Модель вирішує, коли викликати | create_invoice, search_customers, get_stock_level |
| Resources (ресурси) | Застосунок або користувач обирає | PDF договору, прайс-лист, схема бази даних |
| Prompts (шаблони) | Користувач обирає шаблон | «Підсумуй останній квартал цього клієнта» |
Клієнти можуть надавати elicitation: сервер посеред задачі просить користувача уточнити відсутні дані замість того, щоб вгадувати. Опційні розширення додають довготривалі задачі та інтерактивні елементи інтерфейсу.
Чому це важливо для бізнесу
Без стандарту підключення трьох AI-застосунків до п'яти внутрішніх систем означає п'ятнадцять інтеграцій, кожна зі своєю автентифікацією, обробкою помилок і підтримкою. З MCP ви один раз будуєте п'ять серверів, і ними може користуватися будь-який сумісний host.
Практичні переваги, які ми бачимо:
- Немає vendor lock-in. Той самий сервер працює з асистентами різних провайдерів моделей, бо протоколом тепер керує нейтральний фонд, а не одна компанія.
- Одна межа безпеки на систему. Контроль доступу, логування та rate limits живуть у сервері поруч із даними, а не в промптах.
- Швидші пілоти. Коли у вашої ERP є MCP-сервер, новий асистент для продажів чи підтримки — це здебільшого робота над промптом і UX.
- Повторне використання між командами. Асистент фінансової звітності та агент підтримки викликають той самий інструмент
get_order.
MCP не замінює якісний пошук. Для запитань по великих масивах документів вам усе ще потрібні індексація, гібридний пошук і reranking — див. RAG-системи для бізнесу. MCP — це спосіб, яким агент добирається до цього пошуку і до структурованих систем, дані з яких ніколи не можна «вгадувати» з тексту.
Коли MCP — не той інструмент
- Один фіксований процес. Якщо ваш код завжди викликає ті самі три API в тому самому порядку, звичайна функція чи workflow-рушій простіші.
- Масове перенесення даних. MCP розрахований на інтерактивний доступ, яким керує модель, а не на нічний ETL мільйонів рядків.
- Системи без стабільного API. MCP-сервер — тонкий, добре спроєктований шар поверх наявного API. Якщо сам API ненадійний, спершу виправте його.
Як спроєктувати MCP-сервер для бізнес-системи
Якість агента значною мірою залежить від якості його інструментів. Кілька правил, яких ми дотримуємося:
- Проєктуйте інструменти навколо задач, а не ендпоінтів. Один
find_customer(query), що шукає за назвою, email чи ЄДРПОУ, кращий за три низькорівневі ендпоінти, які модель має поєднувати. - Пишіть описи для моделі. Опис інструмента фактично є частиною промпту: що він робить, коли його використовувати і що повертає.
- Повертайте компактні структуровані результати. Двадцять релевантних полів, а не весь запис на 200 полів. Великі відповіді марнують контекст і гроші.
- Робіть побічні ефекти явними. Розділяйте інструменти читання (
get_invoice) і запису (post_invoice) та вимагайте підтвердження для всього, що рухає гроші чи надсилає повідомлення. - Падайте інформативно. «Клієнта не знайдено; спробуйте пошук за ЄДРПОУ» допомагає моделі виправитися; stack trace — ні.
Ось мінімальний сервер лише для читання на Python з хелпером FastMCP з офіційного SDK:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("crm")
@mcp.tool()
def find_customer(query: str, limit: int = 5) -> list[dict]:
"""Search customers by name, email or tax ID.
Use this before any customer-specific action. Returns id, name,
email, segment and open_balance for up to `limit` matches."""
rows = crm_db.search_customers(query, limit=limit) # ваш наявний шар даних
return [
{"id": r.id, "name": r.name, "email": r.email,
"segment": r.segment, "open_balance": float(r.balance)}
for r in rows
]
@mcp.resource("crm://customers/{customer_id}/summary")
def customer_summary(customer_id: str) -> str:
"""Plain-text account summary for a single customer."""
return crm_db.render_summary(customer_id)
if __name__ == "__main__":
mcp.run()
Починайте з режиму читання. Інструменти запису додавайте лише тоді, коли логи покажуть, як модель використовує інструменти читання на реальних запитаннях.
Безпека: частина, яку не можна пропустити
MCP дає моделі змогу читати дані та виконувати дії, тож принципи безпеки зі специфікації — не факультативне читання. Host має отримати явну згоду користувача перед викликом інструментів, описи інструментів від недовірених серверів вважаються недовіреними, а дані користувача не можна передавати деінде без його згоди (специфікація MCP: безпека).
На практиці:
- Автентифікуйте користувачів, а не агента. Для віддалених серверів специфікація визначає потік авторизації на основі OAuth (авторизація в MCP). Кожен виклик інструмента має виконуватися з правами людини, яка поставила запитання, — тоді агент ніколи не побачить більше, ніж могла б побачити вона.
- Встановлюйте лише сервери, яким довіряєте. Дослідники продемонстрували «tool poisoning»: шкідливий сервер ховає в описі інструмента інструкції, які модель виконує (Invariant Labs, 2025). Перевіряйте сторонні сервери як будь-яку іншу залежність.
- Уникайте «смертельної трійці». Агента, що має доступ до приватних даних, стикається з недовіреним контентом і може передавати дані назовні, можна змусити злити дані (Simon Willison, 2025). Для кожного сценарію розірвіть хоча б одну з трьох умов.
- Логуйте кожен виклик. Хто запитав, який інструмент, з якими аргументами, що повернулося. Це знадобиться для налагодження, аудитів і реагування на інциденти.
Про prompt injection і ширшу модель загроз — у статті Безпека AI-агентів: prompt injection і OWASP Top 10 для LLM.
План впровадження, який працює
| Фаза | Тривалість | Результат |
|---|---|---|
| 1. Обрати одну систему й один сценарій | 1 тиждень | Список із 20–50 реальних запитань користувачів |
| 2. Сервер лише для читання | 1–2 тижні | 3–6 інструментів, OAuth, логування |
| 3. Пілот на 5–10 користувачах | 2–4 тижні | Залоговані сесії, аналіз збоїв, кращі описи інструментів |
| 4. Інструменти запису з підтвердженням | 2 тижні | Дії на кшталт створення тікетів чи чернеток |
| 5. Масштабування | постійно | Наступна система, спільні конвенції для інструментів |
Міряйте пілот як будь-яку AI-функцію: частка успішно виконаних задач, частота помилок інструментів і як часто користувачам доводиться виправляти агента. Наш підхід до вимірювань — у статті Як оцінювати LLM-застосунки. Якщо ваша основна система — Odoo, конкретний приклад є в статті Інтеграція AI-агентів з Odoo.
FAQ
MCP — тільки для Claude? Ні. MCP — відкритий протокол під керуванням Agentic AI Foundation у Linux Foundation, його підтримують застосунки та SDK багатьох вендорів.
Чи потрібен MCP, якщо в нас уже є REST API? REST API залишається. MCP-сервер — тонкий шар поверх нього, що описує ваш API зрозумілою для AI-застосунків мовою і додає згоду, автентифікацію та логування, придатні для агентів.
Локальні чи віддалені сервери? Локальні підходять для інструментів розробника та десктоп-застосунків. Для бізнес-систем, якими користується команда, обирайте віддалені сервери з OAuth, щоб доступ централізовано керувався й аудитувався.
Скільки часу займає створення сервера? Сервер лише для читання для системи з пристойним API зазвичай займає один-два тижні разом з автентифікацією та логуванням. Більша частина зусиль іде на дизайн інструментів і тестування на реальних запитаннях.
Джерела
- Anthropic (2024). Introducing the Model Context Protocol.
- Linux Foundation (2025). Formation of the Agentic AI Foundation; MCP joins the Agentic AI Foundation.
- Model Context Protocol. Специфікація, ревізія 2026-07-28 і Authorization.
- Invariant Labs (2025). MCP security notification: tool poisoning attacks.
- Simon Willison (2025). The lethal trifecta for AI agents.