Коротко: MCP-сервер для Business Central — це проміжний шар, який публікує перелік описаних операцій («показати прострочені рахунки», «створити замовлення»), автентифікується в Business Central і виконує тільки те, що є в переліку. Модель обирає з каталогу, а не звертається до бази.
Що таке MCP простими словами
Model Context Protocol — це домовленість про те, як розповісти AI-моделі, які інструменти їй доступні. Не більше й не менше.
Без протоколу підключення моделі до Business Central виглядає так: ви пишете код, який заздалегідь вирішує, який виклик API робити для якого типу запитання. Це працює й саме так будують більшість перших інтеграцій. Ламається воно тоді, коли перелік того, що система має вміти, зростає: кожна нова можливість — це нова гілка в дереві рішень, і через рік ніхто не може сказати, що саме система вміє.
MCP розвертає підхід. Ви публікуєте набір інструментів, у кожного є назва, опис і схема параметрів. Модель читає каталог і обирає сама. Додати можливість — це додати опис інструмента, а не редагувати дерево.
Головний практичний наслідок не в зручності розробки, а в тому, що перелік дозволеного стає документом. Його можна роздрукувати, дати на перевірку безпеці й прочитати за один раз. У зашитій у код інтеграції ця інформація розмазана по файлах.
Як влаштований MCP-сервер
Це окремий застосунок, який стоїть між моделлю і Business Central. Чотири його обов'язки:
- Публікує каталог інструментів. Відповідає на запит «що ти вмієш» переліком операцій зі схемами параметрів.
- Перевіряє параметри. Модель попросила суму «понад мільярд» або дату з майбутнього — сервер відхиляє до звернення до Business Central.
- Автентифікується. Тримає облікові дані й звертається до Business Central під конкретним обліковим записом. Модель цих даних не бачить ніколи.
- Повертає результат у передбачуваній формі. Включно з явною відповіддю «даних немає», яку не можна сплутати з помилкою.
Розгортається сервер зазвичай у вашому середовищі Azure або в підрядника — вибір впливає на те, де опиняються облікові дані й журнали. Компоненти рішення загалом розібрані в статті про архітектуру AI-агента.
Що саме він віддає моделі
Не таблиці. Операції — і різниця тут принципова.
| Тип | Приклад | Параметри |
|---|---|---|
| Читання за метою | Прострочена заборгованість | Сума, дні, компанія |
| Пошук запису | Знайти клієнта | Назва або код |
| Стан на дату | Доступність номенклатури | Номенклатура, локація |
| Створення | Замовлення закупівлі в чернетці | Постачальник, рядки |
| Точкове оновлення | Дата останнього контакту | Клієнт, дата |
| Запуск процесу | Подати запит на погодження | Документ |
Зверніть увагу на два останні рядки: операції запису робляться вузькими навмисно. Не «оновити картку клієнта», а «оновити дату останнього контакту». Різниця в тому, що перше дозволяє змінити кредитний ліміт, а друге — ні, і це обмеження діє на рівні коду, а не на рівні надії, що модель так не зробить.
Описи інструментів — окрема робота, яку недооцінюють. Модель обирає інструмент за описом, тож погано сформульований опис призводить до того, що операція викликається не вчасно. Це проблема коректності, а не безпеки, але на її налагодження йде помітна частина часу.
Як виглядає погано спроєктований сервер
Три ознаки, за якими це видно одразу — корисно, якщо оцінюєте чужу роботу.
Універсальний інструмент. Операція «виконати запит» або «отримати дані з таблиці X» з довільними фільтрами. Розробнику з нею зручніше, а межа безпеки переїжджає з коду в судження моделі. Ознака того, що проєктувальник економив час.
Операції, які повертають забагато. Інструмент віддає цілу таблицю, а фільтрувати має модель. Наслідки подвійні: назовні йде більше даних, ніж потрібно, і агент упирається в обмеження інтенсивності запитів Business Central.
Немає явної відповіді «даних немає». Порожній результат і помилка виглядають однаково, тож модель схильна заповнити пропуск правдоподібним припущенням. У фінансовому контексті це найнебезпечніша поведінка з можливих.
Коли MCP виправданий
Не завжди — і чесна відповідь тут економить бюджет.
Не потрібен, якщо у вас вузький асистент на десяток відомих запитань, які не зростатимуть. Прямі виклики API дешевші, простіші й вийдуть швидше. Розгорнуте порівняння — у статті MCP чи API.
Потрібен, якщо ви будуєте агентів, які мають обирати серед багатьох операцій; якщо перелік можливостей зростатиме; якщо до тих самих даних мають звертатися кілька різних клієнтів; або якщо служба безпеки має регулярно переглядати перелік дозволеного.
Практичне правило: якщо ви можете назвати всі майбутні можливості системи на аркуші й упевнені, що список не зміниться, MCP зайвий. Якщо не можете — він окупиться на третій-четвертій можливості.
Три ризики
- Розростання переліку. Кожен доданий за рік зручний інструмент розширює поверхню. Перелік потребує періодичного перегляду, як будь-який набір прав, — інакше через два роки ніхто не знає, що система вміє.
- Ще один компонент в експлуатації. Сервер треба хостити, моніторити й перевіряти після кожного оновлення Business Central. Це не багато, але це не нуль.
- Ілюзія безпеки. MCP робить перелік дозволеного видимим, але сам по собі нічого не забороняє. Дозволи Business Central і модель автентифікації лишаються головним контролем — детально в розборі безпеки AI в Business Central.
І окремо: MCP молодий, інструментарій навколо нього рухається швидше, ніж зазвичай рухається корпоративне ПЗ. Поточний стан варто перевіряти, а не покладатися на сторінку, написану кілька місяців тому, зокрема й на цю.
Що зробите самі, а що замовляти
| Частина | Самотужки |
|---|---|
| Підняти готовий MCP-сервер і перевірити з'єднання | Так, якщо є розробник |
| Реєстрація застосунку в Entra ID | Так, стандартна процедура |
| Вирішити, які операції взагалі потрібні | Тільки ви |
| Спроєктувати вузькі операції під модель даних BC | Потрібне знання BC, не лише API |
| Написати описи, за якими модель обирає правильно | Досвід вирішує |
| Перевірити, що сервер відмовляє там, де має | Складно без переліку чужих помилок |
Перші два рядки варто спробувати до розмови з підрядником — це кілька днів і повна ясність щодо того, чого не вистачає. Орієнтир вартості проєкту: AI Discovery від $750, асистент від $3 000, агент від $6 000. Хостинг сервера й використання моделі — окремі поточні витрати.
Часті запитання
Чи обов'язковий MCP для роботи AI з Business Central?
Ні. Вузький асистент на десяток відомих запитань добре працює на прямих викликах API і вийде швидше. MCP окупається тоді, коли перелік можливостей зростатиме або коли ви будуєте агентів, яким треба обирати серед багатьох операцій.
Чи дає MCP моделі доступ до бази?
Ні, навпаки. Модель бачить перелік описаних операцій із перевіреними параметрами й не бачить ані бази, ані облікових даних. Виклики виконує сервер під обліковим записом Business Central, і платформа застосовує ті самі дозволи, що й до людини.
Де розгортається MCP-сервер?
У вашому середовищі Azure або в підрядника. Вибір впливає на те, де опиняються облікові дані й журнали, тож це рішення радше про політику даних, ніж про техніку.
Скільки інструментів має бути в переліку?
Стільки, скільки вміщається в документ, який читається за один раз. Якщо перелік неможливо охопити поглядом, він завеликий: перевірити його ніхто не зможе, а модель почне обирати неправильно.
Чи переживе MCP-сервер оновлення Business Central?
Якщо він побудований на стандартному API — так, потрібна перевірка після кожного великого релізу. Якщо він читає недокументовані внутрішні структури — ні, і саме тому цього уникають.
Один сервер може обслуговувати кілька клієнтів?
Так, це одна з переваг підходу: той самий сервер працює з різними AI-клієнтами. Але кожен клієнт потребує свого рішення щодо автентифікації й того, які дані йому доступні.