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