MCP проти CLI: де насправді проходить межа в епоху AI-агентів

Дискусія навколо Model Context Protocol (MCP) та командних інтерфейсів (CLI) різко загострилася після того, як CTO Perplexity оголосив про перехід від MCP до API та CLI, а CEO Y Combinator підтримав тренд, виклавши набір із 28 skills для Claude Code без жодного MCP. Канал Beer::Сode на цьому тлі розбирає, як обидва підходи працюють «під капотом» і де кожен із них справді має сенс.

Як MCP роздуває контекст і чому це дорого

MCP задуманий як універсальний протокол, що дозволяє AI-агентам підключатися до зовнішніх сервісів — GitHub, Gmail, Slack тощо. Кожен MCP-сервер реєструє набір інструментів, і кожен інструмент описується JSON-схемою: назва, опис, параметри, типи.

За замовчуванням ці описи потрапляють у system prompt на кожен запит. Це й створює проблему «роздутого контексту» — зайві сотні й тисячі токенів, які модель змушена обробляти щоразу.

Claude Code частково зняв це обмеження у версії 2.1.7: інструменти MCP підвантажуються «по запиту», а не висять у контексті постійно. Але це радше виняток: Cursor і VS Code мають лише часткові рішення, а GitHub Copilot та інші досі завантажують усе одразу.

Навіть із оптимізацією залишається дві фундаментальні проблеми MCP:

1. Вартість токенів при довготривалому використанні.
   На прикладі запиту «покажи мої pull requests»:

2. MCP-виклик:

   • схема інструмента — приблизно 800 токенів;
   • JSON-RPC-обгортка — близько 50 токенів туди і 50 назад;
   • плюс результат.

   Разом — орієнтовно 1200 токенів.

3. Надійність з’єднання.
   MCP-сервер — це окремий процес, локальний або віддалений, який проксуює запити до API. Це:

4. додаткова точка відмови (якщо сервер впав, завис, не встановив TCP-з’єднання — агент нічого не отримає);
5. два стрибки замість одного: агент ? MCP ? API і назад тією ж дорогою.

CLI, натомість, — це локальний бінарник, який напряму викликає API. Менше шарів — менше шансів на збій.

Чому CLI виявився дешевшим і простішим

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

Моделі навчалися на відкритих репозиторіях і документації, де приклади CLI-команд для GitHub, AWS, Docker та інших інструментів зустрічалися мільйони разів. Для таких популярних CLI агент уже «знає» синтаксис і може одразу сформувати команду без додаткових підказок.

Якщо CLI знайомий моделі:

• команда — приблизно 15 токенів;
• плюс результат.

Разом — близько 315 токенів.

Якщо CLI незнайомий:

• агент викликає help, аналізує вивід;
• може зробити ще один command --help, щоб дізнатися прапорці;
• потім формує команду і отримує результат.

Кожен крок — орієнтовно 50–200 токенів. Навіть у такому сценарії сумарно виходить близько 515 токенів — удвічі дешевше за MCP.

Цей підхід називається progressive disclosure — інформація розкривається порціями, рівно настільки, наскільки це потрібно для поточного кроку, замість того, щоб одразу передавати повну схему інструмента.

Встановлення: npm vs одна команда

Ще один практичний аспект — інсталяція:

• MCP-сервер:
• npm install;
• налаштування токенів у змінних середовища;
• перезапуск coding-агента, щоб підтягнути конфіг.
• CLI:
• одна команда встановлення;
• нативна авторизація;
• інструмент готовий до роботи.

Це робить CLI привабливим для швидкого підключення інструментів до AI-агентів без додаткової інфраструктури.

Де MCP незамінний: persistent connection і складні сценарії

Попри вищу вартість і додаткові точки відмови, MCP має одну ключову перевагу — постійне з’єднання (persistent connection).

CLI працює за схемою «запит–відповідь–завершення». Для одноразових операцій це ідеально: створити pull request, задеплоїти сервіс, прочитати пошту.

MCP дозволяє тримати з’єднання відкритим і виконувати серію операцій без перепідключення. Це критично для сценаріїв реального часу:

• Figma: агент створює фрейм, одразу отримує результат, додає текст, застосовує стилі — усе в рамках одного постійного з’єднання, без запуску окремої команди на кожну дію.
• Playwright / браузер: сторінка відкрита, агент клікає, скролить, перевіряє елементи й одразу бачить результат, не піднімаючи новий процес щоразу.

У таких випадках MCP дає:

• менший оверхед на встановлення з’єднання;
• більш природну модель взаємодії «як людина в UI»;
• можливість будувати складні інтерактивні сценарії.

Звідси просте робоче правило:

• потрібне постійне з’єднання в реальному часі (браузер, canvas, моніторинг) — має сенс MCP;
• одноразові запити «зробив і забув» — логічніше CLI.

Як жити, якщо для сервісу немає CLI — і що з безпекою

Не всі сервіси мають готовий CLI, і не для всіх існують MCP-сервери. Є кілька шляхів, як це обійти.

Варіант 1: написати CLI самостійно

Приклад: сервіс Focus To-Do для управління задачами.

• Готового MCP-сервера немає.
• CLI теж відсутній.

Рішення:

1. Зробити реверс-інжиніринг: подивитися файли застосунку, проаналізувати запити.
2. Разом із Claude Code розібрати формат даних і ендпоінти.
3. На основі цього згенерувати CLI на Python — близько 800 рядків коду.
4. Підключити його як плагін у Claude Code зі skill’ом для Focus To-Do.

У підсумку агент отримує можливість працювати з сервісом природною мовою, а під капотом запускаються готові CLI-команди.

Варіант 2: CLI Anything для open source

Інший шлях — використати репозиторій CLI Anything:

• на вхід подається посилання на будь-який open source-проєкт на GitHub;
• система аналізує код, проєктує CLI, пише реалізацію з тестами;
• на виході — готовий CLI, який можна підключати до AI-агентів.

Обмеження очевидне: це працює лише для відкритих репозиторіїв.

Безпека: ширший доступ CLI проти обмежених MCP-інструментів

З точки зору безпеки CLI і MCP поводяться по-різному:

• MCP:
• кожен інструмент має чітко описані операції й параметри;
• дозволи обмежені рамками конкретного tool’а;

• легше гарантувати, що агент не вийде за межі дозволеного.

• CLI через Bash:

• це довільна bash-команда;
• агент потенційно отримує значно ширший доступ до системи.

Щоб це контролювати, у CLI-підході вводять структурні обмеження:

• GET-операції можуть бути дозволені напряму;
• POST/DELETE — лише з явним підтвердженням;
• критичні дії — через додаткові перевірки.

Це не обов’язково безпечніше, ніж просто прописати в skill’і «ніколи не видаляй дані», але це інший тип трейд-офу, який потрібно усвідомлено приймати.

Практичний висновок: комбінувати, а не протиставляти

Позиція Perplexity про перехід від MCP до CLI має під собою технічні підстави:

• навіть із оптимізаціями MCP залишається дорожчим у токенах;
• додає ще один шар, який може впасти;
• складніший у встановленні й підтримці.

Водночас MCP займає свою нішу там, де потрібне:

• persistent connection;
• інтерактивна робота в реальному часі;
• тонка конфігурація безпеки й обмеження викликів інструментів.

Робочий підхід, який пропонується:

• CLI — скрізь, де це можливо: одноразові операції, інтеграції з API, автоматизація рутинних дій.
• MCP — там, де без постійного з’єднання ніяк: браузер, Figma, canvas, real-time моніторинг.

Практична рекомендація для команд, що вже працюють із MCP:

1. Подивитися, які MCP-сервери зараз підключені.
2. Для кожного перевірити, чи існує CLI-альтернатива.
3. Замінити хоча б один MCP на CLI і порівняти вартість, надійність і зручність.

Source

https://www.youtube.com/watch?v=9Tu8usEv8EU