CLI vs MCP: Ho Scoperto Come Risparmiare il 97% di Token con Claude

L'AI non ti ruberà il lavoro. Ma qualcuno che sa usare gli strumenti giusti per farla lavorare meglio, sì. E quello strumento potrebbe essere una semplice riga di comando.

Quando ho iniziato a lavorare con Claude Code per automatizzare i miei workflow, una delle prime cose che ho imparato è che i token costano. Non solo in termini di euro sulla bolletta API, ma anche in termini di performance: più token bruci, più il contesto si degrada e le risposte diventano meno affidabili. Poi ho scoperto un approccio che ribalta completamente il modo in cui gli agenti AI interagiscono con i tool esterni: le Command Line Interface (CLI). E i numeri parlano chiaro: 35 volte meno token rispetto agli MCP, 97% di risparmio in alcuni scenari.

Tre Modi per Far Parlare un Agente AI con il Mondo Esterno

Oggi, quando vuoi che Claude o un altro agente AI interagisca con un servizio esterno, hai tre opzioni:

Chiamate API dirette: l'approccio più comune. Mandi una richiesta HTTP, ricevi un JSON gonfio di metadati, consumi migliaia di token per informazioni che spesso non ti servono nemmeno.
Server MCP (Model Context Protocol): lo standard attuale per fornire tool agli agenti AI. Risolve il problema della scoperta degli strumenti, ma introduce una "tassa" pesante: ogni server porta con sé uno schema completo che descrive tutti i tool disponibili. Risultato? 30.000+ token bruciati solo all'avvio, prima ancora che l'agente faccia qualcosa.
Command Line Interface (CLI): l'approccio emergente, quello che sto testando ora. L'agente esegue comandi in un terminale locale, riceve output puliti e preformattati, consuma una frazione dei token.

Ho fatto dei test concreti con Claude Code: per lo stesso task, una CLI consuma il 97% di token in meno rispetto a un'API diretta, e circa 35 volte meno rispetto a un server MCP. Non è solo una questione di costo: è una questione di affidabilità. Meno token significa meno context rot, quel fenomeno per cui le performance del modello degradano quando il contesto diventa troppo lungo.

Perché le API Tradizionali Sono un Inferno per gli Agenti

Prendiamo un esempio concreto: vuoi che Claude recuperi tutte le issue da una repository GitHub. Con le API ufficiali di GitHub, ti ritrovi a:

Gestire la paginazione: 47 chiamate separate per ottenere tutti i risultati
Parsare JSON enormi pieni di metadati che non ti servono: oltre 3.000 token per informazioni che potresti sintetizzare in 200
Affrontare rate limit e autenticazione complessa

Con una CLI ben progettata? Un comando, 50 millisecondi di risposta da un database SQLite locale, output formattato esattamente come serve all'agente. Zero round trip sulla rete, zero rate limiting.

Il problema di fondo è che le API sono state costruite per gli sviluppatori e il codice, non per gli agenti AI che "pagano a parola".

MCP: Lo Standard che Costa Troppo

I server MCP hanno risolto un problema reale: la scoperta degli strumenti. Prima di MCP, ogni agente doveva sapere esattamente quali API chiamare e come. MCP standardizza questo processo: l'agente si collega a un server, scarica lo schema dei tool disponibili, e via.

Il problema? Quel download iniziale è costoso. Ho testato il server MCP per GitHub: 43 tool disponibili, oltre 30.000 token consumati solo per caricare gli schemi all'avvio. Prima ancora che l'agente esegua un singolo task.

Quando ho workflow complessi che coinvolgono più tool, quei 30.000 token si moltiplicano. E ogni volta che riavvio la sessione, devo ricaricare tutto. Con una CLI, l'agente carica lo schema solo quando gli serve, con un approccio "lazy loading" che risparmia token preziosi.

Come Funzionano le CLI Agent-First

Una CLI progettata per gli agenti AI ha caratteristiche precise:

Output preformattato: niente JSON grezzi, solo le informazioni necessarie in formato leggibile
Lazy loading: l'help e gli schemi si caricano solo su richiesta
Database locale: SQLite in locale con risposte in 50 millisecondi, niente latenza di rete
Comandi compositi: puoi concatenare operazioni di diverse CLI in un unico comando, incatenando input e output

Ho costruito un workflow per analizzare normative italiane: invece di chiamare API inesistenti, ho creato una CLI che fa reverse engineering del sito normativa.it, estrae gli articoli di legge, li indicizza in SQLite e risponde alle query in tempo reale. Claude può ora cercare "tutte le norme su whistleblowing", ottenere i permalink agli articoli del Codice Civile, confrontare testi di legge. Tutto in locale, tutto veloce, tutto economico.

Printing Press: Da Qualsiasi API a CLI in Minuti

Il problema pratico è: come costruisco una CLI per ogni servizio che mi serve? Scrivere una CLI efficiente richiede competenze. È qui che entra in gioco Printing Press, uno strumento che automatizza esattamente questo processo.

Printing Press prende in input:

Documentazione API ufficiale
Specifiche OpenAPI
Pagine web (fa reverse engineering ispezionando le richieste di rete)
Server MCP esistenti (li converte in CLI)

E restituisce una CLI completa, scritta in Go, pronta per essere usata da Claude Code, Cursor, o qualsiasi altro agente AI.

Esempio concreto: ho preso ESPN, il sito sportivo americano. Non ha API pubbliche documentate. Ho dato a Printing Press l'URL, lo strumento ha ispezionato le richieste di rete (come farebbe un developer con gli strumenti del browser), ha ricostruito gli endpoint, ha generato la CLI. In 2 minuti Claude poteva interrogare le partite NBA del weekend, senza che ESPN avesse mai pubblicato un'API ufficiale.

Quando Usare CLI, Quando Usare MCP

Dopo settimane di test, la mia regola pratica è questa:

Usa le CLI quando: lavori come singolo professionista o in team piccolo, ottimizzi i costi, costruisci workflow personali, hai bisogno di massima velocità e minimo consumo di token.

Usa i server MCP quando: metti un prodotto in produzione, devi gestire traffico di molti utenti, serve robustezza e scalabilità, lavori in ambienti enterprise dove lo standard conta più dell'efficienza marginale.

Io uso Claude Code per automatizzare ricerche, analisi di dati, preparazione di report. Per questi casi, le CLI mi stanno facendo risparmiare centinaia di euro al mese in costi API e migliorando sensibilmente l'affidabilità dei workflow. Se dovessi costruire un SaaS per clienti esterni, probabilmente tornerei agli MCP per la gestione del carico.

Il Futuro è nei Comandi, Non nelle API?

C'è una cosa che mi ha colpito esplorando questo approccio: i Large Language Model sono pre-addestrati anche su interazioni con terminali. Sanno già come funzionano le shell, come leggere l'output di comandi Unix, come concatenare operazioni. Non è un caso che Claude Code sia nata come CLI prima di diventare un'interfaccia grafica.

Forse stiamo assistendo a un ritorno al futuro: negli anni '80 tutto era command line, poi sono arrivate le GUI per rendere i computer accessibili a tutti, poi le API per far parlare i software tra loro. Ora, con gli agenti AI che "pensano" in linguaggio naturale ma eseguono in terminale, le CLI tornano come interfaccia privilegiata.

La domanda che mi faccio è: fino a quando saremo noi a decidere quali comandi eseguire, e non l'AI stessa a scegliere autonomamente cosa fare per ottimizzare i suoi obiettivi?

Se stai lavorando con Claude Code o altri agenti AI e vuoi ridurre drasticamente i costi di token, il mio consiglio è di partire da un tool che usi spesso, verificare se esiste già una CLI nella libreria di Printing Press, e testarla per un paio di giorni. Misura i token consumati, confronta con il tuo approccio attuale. I numeri parlano, e quando vedi il 97% di risparmio su un workflow reale, capisci che non è hype: è un cambio di paradigma concreto.