CLI проти MCP: як навчити AI-агентів обирати правильний інструмент

AI‑агенти дедалі частіше працюють не лише з текстом, а й із реальними системами розробників — файлами, Git‑репозиторіями, веб‑сервісами. Канал IBM Technology розбирає, як саме агенти взаємодіють із зовнішнім світом через два підходи — класичний CLI та новий протокол MCP — і де кожен із них має сенс.

Два шляхи для агентів: CLI та MCP

CLI (Command Line Interface) — це знайомий розробникам термінал: ls, cat, grep, curl, git, docker та десятки інших утиліт. AI‑модель, навчена на мільйонах прикладів з мануалів, Stack Overflow і документації, зазвичай уже «знає», як ними користуватися: які прапорці існують, як будувати пайплайни, як комбінувати команди.

MCP (Model Context Protocol) працює інакше. Це стандартизований протокол, у якому спеціалізовані сервери надають набір «інструментів» із чітко описаними:

• назвою (наприклад, read_file, search_files);
• текстовим описом призначення;
• JSON‑схемою вхідних параметрів (типи, обов’язковість, опис).

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

Саме тут і виникає суперечка: чи не є MCP зайвою складністю, якщо модель і так чудово володіє CLI‑командами?

Коли CLI виглядає переконливіше

Простий кейс: робота з файлами

У базовому сценарії — прочитати файл notes.md і знайти певне слово в кількох Markdown‑файлах — агент може:

• через CLI:
• виконати cat notes.md для виведення вмісту;
• використати grep -n для пошуку слова в обох файлах;
• через MCP:
• викликати інструмент read_file на MCP‑сервері файлової системи;
• викликати search_files із рядком пошуку.

Результат однаковий, але є нюанси:

• CLI‑команди компактні, модель не потребує додаткових підказок чи схем — знання вже «зашиті» в параметри моделі.
• MCP‑сервер файлової системи рекламує, наприклад, 13 інструментів, але агент використовує лише два. Усі 13 JSON‑схем усе одно потрапляють у контекст, витрачаючи тисячі токенів ще до початку реальної роботи.

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

Git і «податок» MCP на контекст

Git — ще один показовий приклад. Через CLI агент може:

• виконати команду для показу останніх 10 комітів;
• запустити git status для перевірки робочого дерева;
• комбінувати прапорці й форматування, спираючись на знання з тренувальних даних.

Альтернатива — GitHub MCP‑сервер із приблизно 80 інструментами. Кожен має:

• назву;
• опис;
• повну JSON‑схему параметрів.

У сумі це близько 55 000 токенів, які завантажуються в контекстне вікно ще до того, як агент виконає бодай одну корисну дію. Навіть якщо реально потрібні один‑два інструменти.

Це означає:

• менше простору в контексті для коду, логів і промптів;
• прямі витрати в грошах, якщо білінг іде за токени;
• дублювання знань, які модель уже має щодо CLI‑команд Git.

У таборі прихильників CLI це головний аргумент: для локальних дев‑інструментів MCP платить високий «податок» за знання, які вже вбудовані в модель.

Де MCP починає вигравати

Веб‑сторінки та «прірва» між сирими даними й корисним результатом

Сценарій: отримати сторінку modelcontextprotocol.io, витягнути головний заголовок і зробити короткий виклад перших абзаців.

Через MCP:

• агент викликає MCP‑сервер Fetcher, побудований на headless‑браузері;
• використовує інструмент fetch_url із посиланням;
• сервер:
• запускає браузер;
• завантажує сторінку;
• чекає на виконання JavaScript;
• конвертує результат у читабельний текст;
• повертає його агенту.

Витрати — близько 250 токенів і кілька секунд.

Через CLI:

• старт із curl -s <URL> | head -n 200:
• замість контенту — майже суцільний JavaScript‑бандл, оскільки сайт працює на Next.js і віддає JS‑додаток, а не готовий HTML;
• далі агент:
• пробує фільтрувати HTML‑теги й відкидати JS через текстові утиліти — безуспішно;
• шукає вбудовані JSON‑фрагменти з даними — знаходить лише частини;
• пише Python‑скрипт, щоб реверс‑інжинірити внутрішній формат даних Next.js, яким фреймворк стрімить контент у браузер.

Після кількох ітерацій агент усе ж отримує достатньо тексту для підсумку, але:

• витрачає понад 2 000 токенів;
• працює кілька хвилин;
• навантажує локальну машину додатковою обробкою.

CLI дає «сирий» інтерфейс до HTTP, але не до того, що реально потрібно — уже зібраної, відрендереної сторінки. MCP‑сервер Fetcher закриває цю прірву, надаючи агенту готовий текст як сервіс.

Аутентифікація, доступи й аудит

Ще одна зона, де MCP має системну перевагу, — інтеграції з сервісами на кшталт Slack, Notion чи баз даних.

Через CLI агент змушений:

• керувати OAuth‑токенами;
• шукати й зберігати ідентифікатори каналів чи ресурсів;
• оновлювати токени;
• вручну (хай і автоматизовано) стежити за безпекою цих операцій.

Через MCP:

• сервер бере на себе:
• аутентифікацію;
• оновлення токенів;
• роботу з ідентифікаторами;
• агент лише формулює, що потрібно зробити (надіслати повідомлення, прочитати записи, змінити дані).

На рівні організації це ще важливіше:

• потрібен розподіл доступів між співробітниками;
• небажано ділитися спільними обліковими даними;
• потрібні журнали аудиту, щоб відстежувати, хто й що робив від імені агента.

Усе це важко «прикрутити» до CLI постфактум, тоді як MCP закладає такі можливості в сам протокол.

Комбінований підхід: не «або‑або», а «і‑і»

Зіставлення сценаріїв показує чіткий патерн:

• CLI виграє, коли:
• команда майже один‑в‑один відповідає задачі (файли, Git, текстова обробка, запуск скриптів);
• модель добре знає інструмент із тренувальних даних;
• важлива компактність і дешевизна в токенах;
• корисна можливість будувати пайплайни через пайпи (|) і комбінувати кілька утиліт в один рядок.
• MCP виграє, коли:
• між «сирим» інтерфейсом (HTTP, CLI‑утиліта) та потрібним результатом є значний розрив (рендеринг JavaScript‑сторінок, складні API);
• потрібне централізоване керування аутентифікацією й доступами;
• важливі аудит, пер‑юзерні права й корпоративне управління;
• доцільно винести складну логіку на сервер, щоб агент працював із нею як із високорівневим інструментом.

Реалістичний сценарій для сучасних AI‑агентів — не вибирати табір, а вміти перемикатися:

• використовувати CLI там, де це прямий, дешевий і давно відпрацьований шлях;
• звертатися до MCP, коли потрібна додаткова абстракція, headless‑браузер, інтеграція з SaaS‑сервісами або корпоративне управління доступами.

І якщо агент раптом починає реверс‑інжинірити JavaScript‑фреймворк лише для того, щоб прочитати веб‑сторінку, це надійний сигнал: обрано не той інструмент.

Джерело

CLI vs MCP: How AI Agents Choose the Right Tool for the Job — IBM Technology