MCP: як дати ШІ-агенту контрольований доступ до ваших систем

Уявіть, що ви наймаєте підрядника й видаєте йому ключ. Питання не в тому, чи він чесний, а в тому, від яких саме дверей цей ключ. Model Context Protocol — це, по суті, спосіб зробити зв'язку ключів замість універсального.

Мовна модель сама по собі вміє тільки одне: продовжувати текст. Вона не має доступу ні до вашої CRM, ні до складу, ні до бази знань. Щоб вона стала корисною в робочому процесі, її треба з'єднати з системами — і саме тут починаються складнощі.

Перший рефлекс — «дамо моделі доступ до бази й нехай сама розбирається». Це погана ідея з трьох причин. Модель не має уявлення про те, які дані чутливі. Вона не розрізняє «прочитати» і «змінити». І вона генерує ймовірний текст, а не гарантовано коректний запит — тобто рано чи пізно згенерує щось несподіване.

Другий підхід — писати окрему інтеграцію під кожну пару «модель × система». Він працює, але кількість цих пар росте як добуток, і кожне оновлення доводиться повторювати всюди.

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

MCP-сервіс оголошує три речі.

Інструменти — дії, які можна виконати. Не «доступ до таблиці замовлень», а конкретно знайти_замовлення(номер) і статус_доставки(номер). Кожен інструмент має описані параметри й описану відповідь.

Ресурси — дані, які можна прочитати: документ, запис, довідник. Теж поштучно, а не оптом.

Підказки — заготовлені сценарії використання, які клієнт може запропонувати користувачеві.

Модель бачить лише цей перелік. Вона не знає, що всередині — SQL, чужий API чи файл на диску, — і не може вийти за межі оголошеного. Якщо інструмента «видалити замовлення» в переліку немає, така дія неможлива в принципі, а не «не рекомендована інструкцією».

Це ключова відмінність від підходу «напишемо в промпті, чого не можна».

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

Практичне правило звучить так: усе, що має бути гарантовано, реалізується в сервісі; усе, що бажано, можна написати в промпті.

З цього випливає, як проєктувати інструменти:

• Один інструмент — одна дія з передбачуваними наслідками.
• Параметри вузькі: замовлення(номер), а не запит(будь_який_sql).
• Права перевіряються всередині інструмента, за роллю користувача, а не за словами моделі.
• Дії, що змінюють дані, відокремлені від тих, що лише читають, і за потреби вимагають підтвердження людиною.

Друга перевага, про яку згадують рідше: кожен виклик інструмента можна записати. Хто звернувся, який інструмент викликав, з якими параметрами й що отримав.

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

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

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

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

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