Scegliere tra CLI e MCP per i flussi di lavoro dei tuoi agenti AI

Costruisco flussi di lavoro per agenti da circa un anno e una domanda continua a sorgere tra gli sviluppatori: dovrei usare uno strumento CLI o creare un server MCP per questo compito? All'inizio mi sembrava ovvio, ma più lo spiegavo, più mi rendevo conto che c'era una reale confusione. Lasciate che chiarisca.

Di cosa stiamo parlando qui?

Quando parlo di CLI in questo contesto, non mi riferisco all'esecuzione di comandi nel tuo terminale. Mi riferisco a come gli agenti AI invocano strumenti esterni. Ci sono due schemi principali:

Esecuzione di comandi shell funziona eseguendo direttamente comandi shell. L'agente esegue essenzialmente qualcosa come npm run build o python script.py e analizza l'output.

MCP (Model Context Protocol) è un protocollo aperto sviluppato da Anthropic che utilizza JSON-RPC 2.0 per la comunicazione tra applicazioni AI e sistemi esterni. Invece di eseguire comandi shell, l'agente chiama strumenti strutturati esposti da un server MCP. Il server scopre gli strumenti disponibili tramite il metodo tools/list e l'agente li esegue utilizzando tools/call con parametri tipizzati.

La differenza chiave: i comandi shell forniscono all'agente una stringa grezza da eseguire, mentre MCP fornisce all'agente definizioni di strumenti strutturate e type-safe con schemi di input chiari.

Quando i comandi shell hanno senso

Vi darò un esempio concreto. Sul mio sito portfolio, ho degli script che generano reindirizzamenti dai miei vecchi post del blog di WordPress alle nuove pagine Next.js. Non ho creato un server MCP per questo. Perché? Perché è un'operazione semplice e una tantum che esisteva già come script Node.

I comandi shell vincono quando:

• Hai già uno script o un comando funzionante
• Il compito è semplice e non necessita di una gestione complessa dello stato
• Stai prototipando e vuoi muoverti velocemente
• Lo strumento è ben consolidato e ha un'interfaccia CLI stabile

Un altro scenario: uso ffmpeg per l'elaborazione audio nei miei progetti. Voglio creare un server MCP per ffmpeg? Assolutamente no. È uno strumento decennale con un'interfaccia CLI stabile. L'agente deve solo costruire la giusta stringa di comando.

L'agente non ha bisogno di definizioni di strumenti type-safe qui. Ha solo bisogno di passare gli argomenti a un processo esterno.

Quando MCP brilla

Ora, ecco dove MCP vale l'investimento. Ho creato un server MCP per il mio strumento di ricerca RFP. La funzionalità non è affatto semplice. È una ricerca full-text su migliaia di documenti di contrattazione governativa, con filtraggio, ranking e riassunti basati sull'AI.

Se l'avessi fatto con comandi shell, l'agente avrebbe costruito stringhe di comando complesse con dozzine di argomenti. Sarebbe stato soggetto a errori e difficile da mantenere. Invece, il server MCP espone strumenti chiari con schemi di input appropriati: search_rfps(query, filters) e get_rfp_details(id). L'agente li chiama con argomenti tipizzati e il server MCP gestisce la complessità.

MCP vince quando:

• Hai flussi di lavoro complessi e multi-step che necessitano di una struttura adeguata
• Hai bisogno di interfacce type-safe con JSON Schema per gli input
• Stai costruendo qualcosa da zero che verrà utilizzato ripetutamente
• Vuoi che l'agente scopra dinamicamente gli strumenti disponibili
• Hai bisogno di un controllo granulare su ciò che l'agente può fare
• Vuoi supportare distribuzioni sia locali (trasporto STDIO) che remote (trasporto HTTP)

Il protocollo supporta anche la negoziazione delle capacità durante l'inizializzazione della connessione, in modo che i server possano pubblicizzare le funzionalità che supportano e i client possano adattarsi di conseguenza.

E per quanto riguarda l'interazione con le API?

Questo capita spesso. Se l'agente deve chiamare un'API REST, dovrebbe usare curl o creare un server MCP?

Approccio CLI significa che l'agente costruisce stringhe di comando come curl -X GET https://api.example.com/data -H "Authorization: Bearer $TOKEN". Funziona, ma l'agente deve ottenere correttamente ogni header, parametro di query e dettaglio di autenticazione. Se sbaglia una cosa, la chiamata fallisce.

Approccio MCP espone strumenti come get_data(filters) o search_customers(query). Il server MCP gestisce internamente le chiamate HTTP, l'autenticazione, la gestione degli errori e i tentativi. L'agente passa solo parametri strutturati.

Per una chiamata rapida e una tantum, la CLI va bene. Per qualsiasi cosa si utilizzi regolarmente, MCP è più pulito. Il server può gestire il refresh dei token OAuth, il rate limiting e messaggi di errore appropriati. Il tuo agente non ha bisogno di sapere nulla di tutto ciò.

Il framework decisionale

Ecco come la penso ora:

Inizia con i comandi shell se: il compito è un semplice wrapper attorno a un comando esistente, è un'operazione una tantum o a bassa frequenza, o hai solo bisogno che qualcosa funzioni rapidamente.

Passa a MCP se: lo strumento ha input complessi che necessitano di validazione, verrà utilizzato frequentemente nei flussi di lavoro degli agenti o necessita di una corretta scoperta degli strumenti. L'overhead di configurazione di un server MCP ha senso solo quando la complessità dello strumento lo giustifica.

C'è anche una considerazione sulla curva di apprendimento. Il tuo team deve capire come funziona MCP: è un protocollo aperto con SDK per diverse lingue. Se sei l'unico a creare strumenti per agenti e hai solo bisogno che qualcosa venga fatto, i comandi shell vanno bene. Se stai creando strumenti per un team o desideri un'infrastruttura riutilizzabile, MCP ripaga.

E per quanto riguarda la combinazione di entrambi?

Puoi farlo, e dovresti farlo quando appropriato. Ho un server MCP per il mio blog che gestisce operazioni complesse come la generazione di traduzioni o la gestione dei metadati dei post. Ma chiama ancora comandi shell internamente per cose come l'esecuzione di script Node o l'accesso a git. MCP è il livello di orchestrazione, i comandi shell sono uno degli strumenti che può utilizzare.

Non pensarla come un'opzione o l'altra. Pensa a MCP come a un modo per dare agli agenti un'interfaccia più pulita ai tuoi strumenti esistenti, inclusi i comandi shell. Il protocollo utilizza messaggi JSON-RPC 2.0 indipendentemente dal trasporto, sia esso STDIO per processi locali o HTTP Streamable per server remoti.

La prossima volta che stai costruendo qualcosa per un agente, chiediti: si tratta di un semplice wrapper attorno a un comando esistente, o necessita della propria interfaccia strutturata con definizioni di strumenti type-safe? Quella risposta ti dirà quale percorso intraprendere.