Рік тому підключення внутрішніх систем компанії до AI-асистента було науковим проєктом. Сьогодні це тікет у Jira — Model Context Protocol перетворив «під’єднай AI до нашої бази замовлень» з кастомної інтеграційної роботи на те, що мідл-інженер може прототипувати за тиждень. Якщо потрібне пояснення самого протоколу, розбір MCP закриває цю тему.
Цей пост — інша розмова: та, яку я веду з CTO та платформними лідами після того, як демо прототипу пройшло добре. Бо демо — легка частина, а питання, що йдуть далі («то можемо ми це розкатати?»), — це питання архітектури, безпеки й економіки в AI-костюмі.
Що MCP насправді змінює для команди?
MCP стандартизує сантехніку інтеграції AI із системами, що зміщує складну роботу з «як це під’єднати» на «що цьому має бути дозволено робити». Один сервер, що експонує ваш трекер задач, працює в кожному MCP-сумісному клієнті, яким користується команда, — одна інтеграція, написана один раз. Це реальний важіль: до стандарту кожна AI-поверхня вимагала перезбирати кожну інтеграцію.
Чого він не змінює: фактичний контракт вашого внутрішнього API, модель автентифікації та чутливість даних проходять крізь нову трубу без змін. MCP-сервер — це шар подання над вашими системами для дуже буквально мислячого споживача: якщо нижчий API дозволяє викликачеві читати замовлення всіх клієнтів, MCP-сервер тепер пропонує цю можливість кожній розмові з AI. Протокол стандартизував з’єднання, а не судження.
Де має проходити межа безпеки?
У самому MCP-сервері — і ніколи не делегуватися добрій поведінці моделі. Правило, якого я вимагаю від команд: сервер забезпечує рівно те, що може робити людина за сесією, використовуючи ваш наявний auth (scoped-токени, права на рівні рядків), тож навіть повністю збита з пантелику модель не може запросити дані, до яких людина й так не мала доступу. «Модель зазвичай не просить дані інших клієнтів» — це не позиція безпеки; «токен не може читати дані інших клієнтів» — ось вона.
Три конкретні рішення заслуговують на проєктний час до розкатки. Розділення читання й запису: read-only tools — інший клас ризику, ніж tools, що мутують стан, — починайте з read-only, додавайте записи tool за tool’ом з явними процесами схвалення. Реальність prompt injection: будь-який вивід tool, що містить користувацький контент (текст тікетів, листи, відгуки), може нести інструкції, за якими модель може піти, тому ставтеся до виводів tools як до недовіреного вводу — рівно як у класичній веб-безпеці. І логування: кожен виклик tool, з аргументами, прив’язаний до сесії людини — бо «що AI чіпав минулого вівторка» одного разу спитає хтось із комплаєнс-посадою, і відповіддю не має бути знизування плечима.
Скільки насправді коштує розкатка MCP?
Сервер — дешевий рядок кошторису; контрактна робота навколо нього — справжній бюджет. Зібрати перший read-only-сервер над добре задокументованим внутрішнім API — це справді дні, а не місяці: механіку можна опанувати у форматі курсу (створення MCP-серверів існує рівно для цього). Витрати, що дивують команди: проєктування tool-schema (описи настільки точні, щоб модель обирала правильний tool для правильної задачі, — погані описи дають AI, що впевнено помиляється щодо ваших власних систем), evals (тестовий набір, що доводить, що tools використовуються правильно в реалістичних розмовах, а не просто повертають 200) і постійне володіння — бо кожна зміна schema вище за течією тепер має другого споживача, якого можна зламати.
Вартість самого рантайму йде за економікою агентів: кожен результат tool потрапляє в контекстне вікно моделі й оплачується, тож сервер, що повертає 200 рядків там, де вистачило б 5, тихо множить ваш рахунок за tokens. Формування результату — фільтрація, сумаризація, пагінація всередині сервера — це рішення водночас про якість і про вартість, і саме тут дисципліна продакшен LLM-застосунків окупає себе.
Будувати власними силами чи кликати когось ззовні?
Будуйте in-house, коли інтеграція read-only, у нижчого API є ясний власник, і у вас є хоча б один інженер, що довозив LLM-фічу до продакшену, — профіль, який знає, чому описи tools несучі й навіщо потрібен eval-набір. Знання накопичується: перший сервер вчить команду патернів, які кожен наступний сервер перевикористовує, і цим знанням варто володіти, а не орендувати його.
Кейс за кейсом лінія проходить приблизно тут:
| Ситуація | Будувати in-house | Спершу кликати рев’ю |
|---|---|---|
| Read-only-сервер над внутрішнім API з ясним власником | Так — дні роботи, і команда лишає патерн собі | Не потрібно |
| Ваш перший tool зі здатністю до запису | Ризиковано наодинці | Так — протестувати межі під тиском до того, як вони стануть продакшен-фактами |
| Регульовані, клієнтські чи фінансові дані | Ні | Так — модель auth і захист від injection перевірені до запуску |
| Проєктування tool-schema на великій поверхні | Здійсненно; чекайте на ітерації | Корисно — розпливчасті описи дають AI, що впевнено помиляється щодо ваших систем |
| Eval-набір на коректне використання tools | Так, і володіти ним довгостроково | Опційно |
Кличте зовнішнє рев’ю, коли залучені записи, коли дані регульовані або коли інтеграція торкається систем, чия відмова дорога, — не щоб віддати збірку на аутсорс, а щоб протестувати під тиском межі tools, модель auth і захист від injection до того, як вони стануть продакшен-фактами. Саме такий формат «спершу дизайн-рев’ю» — наш консалтинг з AI-інтеграції: друга думка senior-рівня про архітектуру, поки її ще дешево змінювати, при цьому збірка лишається за вашою командою. Чесна евристика: демо зайняло тиждень, тому спокуса — повірити, що продакшен — це ще два; команди, в яких це виходить, закладають розрив «від демо до продакшену» як сам проєкт — той самий розрив, який покликаний закрити context engineering.
Версія в один абзац для наступної зустрічі з керівництвом
MCP зробив з’єднання дешевим. Він лишив безпечне, коректне, економічне з’єднання рівно настільки ж складним, яким воно було завжди. Протокол тепер стандарт; судження — досі ні.
MCP зробив підключення AI до внутрішніх систем дешевим; він лишив безпечне, коректне, економічне підключення рівно настільки ж складним, яким воно було завжди, і переніс цю складність у дизайн tools, межі auth, evals і формування результатів. Починайте з read-only, забезпечуйте права в сервері обліковими даними самого користувача, ставтеся до виводів tools як до недовірених, логуйте все і формуйте результати так, ніби tokens коштують грошей — бо вони коштують. Перший сервер будуйте in-house на низькоризиковій системі; купуйте рев’ю до того, як вийде перший здатний до запису чи регульований. Протокол тепер стандарт. Судження — досі ні.
