MCP o CLI: come collegare strumenti a un agente AI

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. Una CLI ben fatta può invece spostare 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, 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, supporta trasporti locali o remoti 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 vuoi esporre come comandi controllati dal client.
• 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. Sono pezzi dello stesso sistema, ma rispondono a domande diverse.

• 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.

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.

Domande frequenti