MCP o CLI: come collegare strumenti a un agente AI
La scelta dipende da contesto, manutenzione, permessi e bisogno di governance
Entra nell'analisi
Risposta breve
Una CLI è il default leggero per far usare a un agente comandi locali, build, test e script. MCP è il livello più strutturato per esporre strumenti e dati a più agenti con un contratto stabile. Scegli in base a contesto, permessi e manutenzione, non alla novità della tecnologia.
- MCP: scegli per API remote, database condivisi, risorse, prompt, auth e permessi centralizzati.
- CLI: scegli per script locali, build, test, migrazioni e strumenti che hanno già --help chiaro.
- Regola di promozione: parti da CLI, misura uso e rischi, poi crea MCP solo per ciò che deve essere stabile e condiviso.
Differenze
Il confronto che orienta la scelta
| Criterio | Server MCP | CLI documentata |
|---|---|---|
| Costo in contesto | Dipende dal client: Claude Code carica all'avvio solo nomi dei tool e istruzioni del server e recupera gli schemi quando servono; Codex costruisce all'avvio un catalogo dei tool che puoi restringere con una lista di tool abilitati | L'agente può scoprire uso e opzioni con --help, README o esempi mirati quando servono |
| Setup e manutenzione | Richiede server, configurazione client, versioni, auth, transport e osservabilità | Richiede comandi stabili, help chiaro, exit code affidabili e documentazione nelle istruzioni di progetto |
| Sicurezza e permessi | Buono per permessi centralizzati, ma ogni server aggiunge superficie e va considerato attendibile | Più semplice da auditare localmente, ma va limitata con sandbox, allowlist, conferme e log |
| Portabilità tra agenti | Alta se gli agenti supportano MCP e il server segue lo standard | Alta su ambienti con shell, meno uniforme su agenti cloud senza accesso locale o con permessi limitati |
| Servizi remoti | Scelta naturale per API, SaaS, database, OAuth, bearer token e risorse condivise | Possibile tramite tool CLI o SDK, ma spesso meno governabile quando entrano credenziali e policy |
| Strumenti locali | Utile se devi standardizzare uno strumento locale per molti agenti o client | Scelta più rapida per script di repo, test, build, codegen, lint, export e automazioni personali |
Applicazione
Scenari di integrazione
Il costo principale non è solo sviluppo iniziale: è contesto consumato, manutenzione, superficie di sicurezza e attrito per ogni agente che userà lo strumento.
Database aziendale condiviso
Query, schema e policy · Risultati filtrati
- Scelta consigliata
- Server MCP
- Motivo
- Auth, permessi e audit sono più importanti della comodità locale
Un database condiviso non dovrebbe dipendere da una CLI privata sul laptop di una persona. Serve controllo centrale.
Script di build locali
package.json e README · Exit code e log
- Scelta consigliata
- CLI documentata
- Motivo
- Il comando esiste già, costa poco contesto e produce un segnale verificabile
Per build e test, una CLI con exit code puliti è spesso più utile di un server MCP creato apposta.
API esterna con auth
Token, scope e operazioni · Dati o azioni remote
- Scelta consigliata
- Server MCP
- Motivo
- Gestisce meglio credenziali, scope, risorse e controlli riusabili tra agenti
Quando l'integrazione tocca servizi esterni, MCP aiuta a separare capacità e permessi dal prompt del singolo agente.
Automazioni personali
Comandi frequenti · File, report o task
- Scelta consigliata
- CLI prima, MCP dopo
- Motivo
- Inizia leggero e promuovi solo ciò che diventa condiviso o critico
Una automazione n8n o uno script locale può partire da CLI. Se diventa una capacità del team, allora vale impacchettarla meglio.
Cosa sono MCP e CLI
MCP, Model Context Protocol, è un protocollo aperto per collegare applicazioni AI a sistemi esterni: tool, risorse, prompt, dati e workflow. Una CLI, command line interface, è invece un programma usabile da terminale: l'agente lancia un comando, passa flag o file, legge stdout e stderr, poi decide dal codice di uscita se l'operazione è riuscita. Entrambi servono a dare capacità operative all'agente, ma con costi e controlli diversi.
- MCP rende espliciti tool, schema degli argomenti, risorse e prompt attraverso un server.
- Una CLI rende esplicito un contratto operativo: comando, flag, input, output, exit code.
- Se il problema è locale e già automatizzato, la CLI è spesso sufficiente.
- Se il problema è condiviso, remoto o sensibile, MCP diventa più interessante.
Il criterio centrale: contesto e manutenzione
Ogni capacità data a un agente costa qualcosa. Un server MCP deve descrivere tool, schemi e istruzioni in modo che il modello li scopra e li usi. Quanto pesa dipende dal client: Claude Code ha la ricerca dei tool attiva di default e all'avvio carica solo i nomi dei tool e le istruzioni del server, mentre Codex costruisce un catalogo iniziale dei tool che puoi restringere con una lista di tool abilitati. Una CLI ben fatta sposta comunque molta complessità fuori dal prompt: l'agente legge --help, esegue un comando e interpreta un exit code. Questo non rende la CLI sempre migliore, ma la rende un ottimo default quando il tool vive nel repository.
- Se l'agente userà lo strumento raramente e il tuo client carica tutti i tool all'avvio, non riempire ogni sessione di descrizioni MCP inutili.
- Se lo strumento è critico e condiviso, il costo di un server MCP può essere giustificato.
- Se il comando cambia spesso, tenerlo come CLI può essere più economico che aggiornare client, schema e server.
- Se l'interfaccia deve essere stabile per più agenti, MCP riduce lavoro duplicato nel tempo.
Quando MCP vince
MCP vince quando vuoi un confine chiaro tra agente e sistema esterno. Il protocollo documenta tools, resources e prompts, prevede due trasporti standard (stdio per processi locali e Streamable HTTP per server raggiungibili via rete) e consente a client diversi di collegarsi a un server con lo stesso contratto. Questo conta molto quando entrano credenziali, dati condivisi o operazioni che non vuoi trasformare in comandi shell generici.
- Servizi remoti con OAuth, bearer token, policy e audit.
- Database o knowledge base aziendali che più agenti devono interrogare.
- Risorse che non sono semplici output testuali da terminale.
- Prompt o procedure che l'utente deve poter richiamare in modo esplicito, per esempio come slash command.
- Integrazioni che devono funzionare in Claude Code, Codex, Cursor o altri client MCP.
Quando la CLI vince
La CLI vince quando il lavoro è vicino al codice e ha già una semantica da sviluppatore. Test, lint, build, script di migrazione, export e piccoli tool interni spesso sono già pensati per la shell. In questi casi l'agente non ha bisogno di un protocollo nuovo: ha bisogno di comandi affidabili, esempi e limiti chiari in AGENTS.md o CLAUDE.md.
- Il tool gira localmente e deve vedere filesystem, repo o ambiente di test.
- Il comando ha --help, esempi, exit code e output leggibile.
- Vuoi permettere composizione libera: pipe, file temporanei, diff, grep, script.
- Installare e mantenere un server MCP sarebbe più lavoro del valore prodotto.
- Il rischio si gestisce meglio con sandbox, conferme e allowlist sui comandi.
La via di mezzo usata dai team
Molti team non decidono una volta per sempre. Partono con CLI e documentazione perché è la strada più veloce per validare il workflow. Quando uno script diventa usato da più agenti, richiede credenziali o produce dati che vanno governati, lo promuovono a MCP. È una progressione sana: prima impari il contratto reale, poi lo standardizzi.
- Fase 1: script locale con help, esempi e test.
- Fase 2: documentazione in AGENTS.md o CLAUDE.md con casi d'uso e limiti.
- Fase 3: wrapper o CLI più stabile se l'agente sbaglia spesso.
- Fase 4: server MCP se serve condivisione, policy, auth o integrazione multi-client.
Dove entrano le skill
Le skill non sostituiscono né MCP né CLI. Una skill impacchetta una procedura riusabile: quando cercare, quali file leggere, che controlli fare, come presentare il risultato. MCP e CLI danno capacità operative all'agente; la skill gli insegna quando e come usarle. Da settembre 2026 MCP ha anche un'estensione ufficiale per le skill: un server può distribuire, insieme ai propri tool, le procedure che spiegano come usarli. Il supporto nei client è ancora in corso, quindi controlla il tuo prima di contarci.
- Usa una skill per workflow ripetuti che richiedono giudizio e passi ordinati.
- Usa una CLI per eseguire operazioni locali e verificabili.
- Usa MCP per esporre capacità esterne in modo standard e governabile.
- Combinali quando serve: skill che decide, CLI che esegue, MCP che collega sistemi esterni.
- Se più team usano lo stesso server MCP, valuta di distribuire da lì anche la skill che spiega come usarlo, se i vostri client supportano l'estensione.
Regola pratica finale
Se stai decidendo oggi, parti da questa domanda: lo strumento è una scorciatoia locale per un progetto o una capacità condivisa della tua organizzazione? Nel primo caso, scrivi una buona CLI e documentala nel file di istruzioni. Nel secondo, progetta un server MCP con permessi, log e schema pulito.
- Locale, frequente, vicino al repo: CLI.
- Remoto, condiviso, sensibile o multi-agente: MCP.
- Procedura lunga che coordina più passi: skill più CLI o MCP.
- Quando non sai ancora se servirà davvero, non costruire server: prova prima con CLI.
La newsletter di QualeAI
Le novità che meritano il tuo tempo.
Aggiornamenti editoriali su tool, modelli, prezzi e workflow. Solo quando c’è qualcosa di utile da capire.
Prima di chiudere
Domande frequenti
MCP funziona solo con Claude?
No. MCP è uno standard aperto: il sito ufficiale cita il supporto in Claude, ChatGPT, Visual Studio Code e Cursor. Codex lo supporta nella CLI, nell'estensione per IDE e nell'app desktop di ChatGPT, con configurazione condivisa in config.toml.
Posso usare sia MCP sia CLI nello stesso agente?
Sì. È spesso la scelta migliore: CLI per comandi locali e verifiche di progetto, MCP per servizi remoti, database, risorse e integrazioni condivise.
Una CLI è sicura da dare a un agente?
Dipende dai permessi. Una CLI va limitata con sandbox, conferme, allowlist, output chiaro e comandi non distruttivi di default. La shell libera non è una policy di sicurezza.
Quando vale la pena creare un server MCP?
Quando lo stesso strumento serve a più agenti o persone, quando gestisce credenziali, quando espone dati remoti o quando vuoi permessi e audit centralizzati.
MCP consuma più contesto di una CLI?
Dipende dal client. Claude Code rimanda il caricamento degli schemi con la ricerca dei tool, attiva di default, quindi ogni server aggiunge al contesto iniziale solo nomi dei tool e istruzioni. Con client che caricano tutti gli schemi all'avvio, molti server MCP occupano spazio a ogni sessione. Una CLI ben documentata resta la via più leggera: l'agente legge --help solo quando serve.
Prossime letture
