Agenti AI: MCP o CLI? Come scegliere per ogni attività

Agenti AI: quando scegliere MCP e quando la CLI?

Per chi sviluppa all'interno di un repository, conviene partire dalla CLI. Un'interfaccia a riga di comando è un programma che si utilizza impartendo comandi. Se l'agente dispone già di un ambiente autorizzato per eseguirli e lo strumento copre il compito, aggiungere un'integrazione può aumentare la manutenzione senza migliorare il risultato.

Per un assistente ospitato che serve utenti diversi, è preferibile un servizio MCP con permessi circoscritti a una shell condivisa con privilegi elevati. Model Context Protocol è uno standard con cui un'applicazione AI individua e richiama strumenti. Un server remoto può accettare l'autorizzazione di ciascun utente ed esporre le operazioni necessarie all'assistente. Resta comunque da far rispettare quei permessi.

In un team di sviluppo, i due approcci possono convivere se hanno responsabilità diverse. Il lavoro sul repository resta nell'ambiente di esecuzione dei comandi. Le operazioni aziendali condivise passano invece da un servizio che verifica identità e autorizzazioni del chiamante.

I criteri decisivi sono l'accesso all'ambiente di esecuzione, la titolarità delle credenziali, le operazioni disponibili e la quantità di informazioni che arriva al modello. Il nome del protocollo viene dopo.

La documentazione dei produttori su cui si basa questo confronto è stata verificata l'11 novembre 2026. Si tratta di flussi documentati e valutazioni architetturali, non di un benchmark o di risultati di prove pratiche.

CLI e MCP: come arrivano le operazioni al modello?

MCP fornisce all'agente la descrizione di uno strumento; una CLI gli dà un comando da eseguire. Nessuno dei due consente al modello di compiere da solo un'operazione. L'applicazione che lo ospita riceve la chiamata proposta, applica i propri controlli, la esegue e restituisce il risultato.

Con MCP, il client chiede al server quali strumenti sono disponibili. Ogni strumento indica nome, scopo e schema di input, ossia i campi che accetta. L'applicazione può presentare queste definizioni al modello, che seleziona uno strumento e fornisce argomenti strutturati. La specifica degli strumenti MCP definisce individuazione e invocazione, lasciando all'applicazione la modalità di interazione con l'utente.

Con una CLI, l'agente usa uno strumento di esecuzione dei comandi per avviare un programma installato. Può già conoscere un comando comune, ma può anche leggere --help per verificare la sintassi dello strumento installato. La risposta può essere testo, JSON strutturato o il percorso di un file. «Output della CLI» non significa «testo non strutturato».

Per esempio, «elenca le mie pull request aperte» può diventare una chiamata a uno strumento GitHub con relativi argomenti, oppure un comando gh pr list. L'account utilizzato deve comunque avere il permesso di leggere quelle pull request. Cambiare interfaccia non concede l'accesso.

Per il ruolo più ampio del protocollo, si veda che cos'è MCP.

Costo del contesto: la CLI prevale nel caso locale più semplice

Una CLI può tenere fuori dal contesto del modello i dettagli inutili degli strumenti, ma non azzera il consumo di contesto. Il contesto è l'insieme di informazioni che il modello riceve per decidere il passo successivo. Descrizioni degli strumenti e schemi dei parametri occupano token quando l'applicazione li include, proprio come il testo della guida e l'output dei comandi.

Un server MCP con molti strumenti può quindi consumare parecchio contesto prima che inizi il lavoro utile. La precisazione decisiva è quando l'applicazione include l'elenco. Non bisogna presumere che ogni applicazione carichi tutte le definizioni disponibili in ogni richiesta al modello. Selezionare meno strumenti o individuarli al bisogno cambia il confronto.

Il percorso CLI può partire dalla sola definizione dello strumento che esegue i comandi e caricare la guida specifica soltanto quando serve. Può anche filtrare i dati prima di restituirli al modello. Richiedere solo titoli e URL delle pull request è meglio che restituire record completi e chiedere al modello di ignorarne la maggior parte.

Una CLI che stampa un log enorme, però, o una skill che carica un lungo manuale, può annullare quel vantaggio. Allo stesso modo, uno strumento MCP che restituisce una risposta concisa può essere più efficiente di ripetute esplorazioni nella shell. Va misurato il compito completo: definizioni, guida, output, tentativi ripetuti e correttezza del risultato. La brevità di un comando, da sola, dimostra poco.

Vincitore della categoria: CLI per le attività locali di routine con output selettivo. MCP resta competitivo quando l'insieme degli strumenti e i risultati sono contenuti. Qui non ci sono basi per affermare un rapporto universale di consumo dei token.

Autenticazione e permessi: MCP prevale se il servizio fa rispettare i limiti

L'autorizzazione per singolo utente conta più del formato usato dall'agente, che sia JSON o una stringa di comando. OAuth è un flusso di accesso delegato: l'utente autorizza un client senza consegnargli la propria password. Un'implementazione MCP remota può usare quell'identità per stabilire a quali account, record e azioni il client può accedere.

Si pensi a un assistente di supporto che serve organizzazioni clienti diverse. Dovrebbe recuperare i record del cliente autenticato senza ricevere la credenziale di uno sviluppatore che può leggere tutti gli account. Tra un servizio MCP remoto con permessi correttamente circoscritti e una shell amministrativa condivisa, la scelta è il servizio. È il caso in cui MCP può essere l'unica opzione accettabile tra quelle due implementazioni.

Non è l'unica architettura sicura possibile. Un'integrazione API diretta può far rispettare gli stessi limiti. Né basta aggiungere MCP per crearli automaticamente: la specifica di autorizzazione MCP rende l'autorizzazione facoltativa, definisce il flusso di autorizzazione HTTP e distingue i server STDIO locali, che ottengono le credenziali dal proprio ambiente.

Anche una CLI può usare l'accesso tramite browser e una credenziale con permessi limitati. Il rischio dipende da ciò a cui il suo processo può accedere: credenziali, file, destinazioni di rete e altri eseguibili. Un esecutore di comandi in sandbox con credenziali strettamente circoscritte è una soluzione ben diversa dall'accesso senza restrizioni al computer di uno sviluppatore.

Vincitore della categoria: MCP remoto con permessi circoscritti per l'accesso delegato di utenti diversi. Qualunque sia il percorso, il codice deve verificare le autorizzazioni su account e oggetti, tenere le credenziali fuori dall'output visibile al modello e registrare quale utente ha autorizzato ogni azione.

GitHub CLI o GitHub MCP: lavoro sul repository o accesso condiviso al servizio?

GitHub CLI, il client a riga di comando gh, è la scelta più diretta per un agente di sviluppo che lavora già su una copia locale del repository. Supponiamo di volere un riepilogo delle proprie pull request aperte. Dall'interno del repository, dopo l'autenticazione, si possono usare queste opzioni documentate:

gh pr list --author "@me" --json number,title,url

Il comando richiede solo i campi necessari al riepilogo. La CLI supporta anche --jq per filtrare il JSON prima che raggiunga il modello. È una tecnica concreta per risparmiare contesto, senza attribuirle risultati di un benchmark sui token.

Il limite della CLI è l'ambiente che la esegue. Un comando che funziona sul proprio portatile non diventa automaticamente un'interfaccia adatta a qualsiasi dipendente o cliente. Secondo il manuale di accesso di GitHub CLI, l'accesso tramite browser salva normalmente un token nell'archivio credenziali del sistema e ripiega sul testo in chiaro se l'archivio non è disponibile. Va verificata la gestione effettiva delle credenziali, senza presumere che «locale» significhi «isolato».

GitHub MCP Server, il server di strumenti ufficiale di GitHub, è adatto a un assistente che deve operare sui repository tramite MCP. Per ottenere lo stesso riepilogo, si espongono gli strumenti pertinenti alle pull request, si usa l'autorizzazione dell'utente previsto e si chiedono le sue richieste aperte. GitHub ospita un server remoto e offre anche un'opzione locale.

GitHub documenta i gruppi di strumenti e la selezione dei singoli strumenti, oltre a una modalità di sola lettura che omette quelli di scrittura. Il supporto OAuth remoto dipende anche dalla configurazione dell'app GitHub o OAuth appropriata nell'applicazione ospitante; la sola compatibilità del trasporto non risolve l'autenticazione.

Verdetto del confronto: usare gh per il riepilogo dello sviluppatore e gli script del repository. Preferire MCP per un assistente condiviso il cui client supporti il flusso di autenticazione necessario. Nessuna delle due scelte sostituisce i permessi del repository; selezionare meno strumenti MCP può migliorare sia la chiarezza sia l'uso del contesto.

Playwright CLI o MCP: attività di sviluppo o esplorazione nel browser?

Playwright CLI, l'interfaccia a comandi di Microsoft per le azioni nel browser, è la scelta predefinita per un agente di sviluppo che verifica una modifica web. I suoi autori raccomandano CLI e skill per gli agenti di sviluppo perché i comandi possono evitare di caricare nel contesto schemi estesi e dati della pagina. È una loro indicazione progettuale, non una misura di velocità ottenuta in questo articolo.

Per chi verifica un modulo, il flusso consiste nell'aprire la pagina, esaminare gli elementi pertinenti, interagire e controllare il risultato. L'agente non deve leggere ogni dettaglio della pagina dopo ogni azione.

playwright-cli install: partire dai comandi del produttore

L'installazione documentata e un'ispezione della pagina in sola lettura sono:

npm install -g @playwright/cli@latest
playwright-cli --help
playwright-cli open https://playwright.dev
playwright-cli snapshot
playwright-cli close

Questi comandi esaminano una pagina pubblica; non sono una suite di test. Lo snapshot ottenuto serve a individuare gli elementi su cui agire prima di aggiungere interazioni con la propria applicazione.

Skill di Playwright CLI: aggiungere le istruzioni operative

Una volta installata la CLI, il comando documentato per le skill è:

playwright-cli install --skills

Il limite importante è ciò che bisogna predisporre attorno allo strumento: un ambiente in grado di eseguirlo, una sessione del browser appropriata e istruzioni che definiscano il successo del compito. Una skill aiuta a seguire la procedura; non può stabilire se una transazione reale di un cliente sia autorizzata.

Playwright MCP, il server di strumenti per browser di Microsoft, è più adatto quando il client MCP trae vantaggio dall'ispezione strutturata della pagina durante un ciclo esplorativo. Per supportare l'interazione con il browser usa snapshot di accessibilità, ossia descrizioni strutturate degli elementi della pagina.

Contano due limiti. Primo, lo stato persistente del browser non è un'esclusiva di MCP: Playwright CLI conserva cookie e dati di archiviazione tra le chiamate della stessa sessione e offre profili persistenti tra i riavvii del browser. Secondo, il repository MCP dichiara esplicitamente che il server non costituisce un confine di sicurezza. Anche le avvertenze sui controlli delle origini precisano che non creano quel confine e non influiscono sui reindirizzamenti.

Verdetto del confronto: CLI e skill per le verifiche di routine in un flusso di sviluppo; MCP per un client e un compito che traggono vantaggio dai suoi strumenti di interazione con il browser. Non cambiare soltanto per ottenere la persistenza della sessione. La guida alla configurazione di Playwright MCP e ai test nel browser approfondisce questo percorso.

Stripe CLI o Stripe MCP: sviluppo dei webhook o operazioni sull'account?

Stripe CLI, lo strumento da terminale di Stripe, prevale nello sviluppo e nel debug di un'integrazione di pagamento. Un compito tipico consiste nel ricevere su un'applicazione locale gli eventi webhook, le notifiche che Stripe invia quando succede qualcosa. La documentazione della CLI indica stripe listen per ricevere e inoltrare quegli eventi e stripe trigger per generare eventi di esempio.

Questo flusso va mantenuto in una sandbox. Attivare eventi crea oggetti API e può generare ulteriori eventi; non equivale a stampare un semplice payload di esempio. La CLI supporta anche operazioni API e l'ispezione dei log delle richieste, quindi la sua utilità va oltre l'inoltro dei webhook.

La distinzione sull'autenticazione è più sottile di «CLI significa copiare una chiave API». Stripe documenta l'accesso tramite browser per singolo utente, l'archiviazione locale sicura delle credenziali dove disponibile, il rinnovo della sessione e la revoca. Per gli sviluppatori può essere una soluzione adatta. Per un assistente ospitato, scegliendo la CLI serve comunque un modo per isolare ambiente di esecuzione e credenziali di ogni utente.

Stripe MCP, l'interfaccia di servizio di Stripe rivolta agli agenti, prevale nelle operazioni sull'account da un assistente compatibile senza un esecutore di comandi locale. Per esempio, un operatore autorizzato può chiedere all'assistente di trovare e leggere i dati pertinenti delle API Stripe. Il server offre strumenti per cercare nelle API, individuare parametri, leggere e scrivere, invece di richiedere una definizione distinta per ogni operazione.

Stripe supporta OAuth per l'accesso per conto di un utente e chiavi API per agenti per l'accesso indipendente. Lo strumento generico stripe_api_write può coprire molte operazioni. I requisiti di conferma umana di Stripe dipendono dall'azione e sono separati dall'impostazione di approvazione degli strumenti del client. Approvare una categoria di strumenti non equivale quindi ad approvare ogni azione aziendale che può eseguire.

Verdetto del confronto: CLI per sviluppare webhook in locale; MCP per il lavoro delegato sugli account tramite un assistente. Va confrontata l'operazione necessaria, non il numero di comandi o strumenti. Una connessione MCP che legge dati dell'account non sostituisce il listener locale dei webhook nel flusso di sviluppo.

MCP o skill: le istruzioni operano su un altro livello

Una skill dice all'agente come lavorare; MCP e CLI gli danno modi per agire. Nel formato Agent Skills, un file SKILL.md contiene nome, descrizione e istruzioni per il compito, eventualmente affiancati da script e file di riferimento. Gli agenti individuano prima i metadati e caricano le istruzioni complete quando servono.

Nel confronto «MCP vs CLI vs skills», una combinazione spesso utile è CLI più skill. La CLI esegue l'operazione; la skill specifica quali comandi usare, quale ambiente selezionare, quali evidenze esaminare e quando fermarsi. Una skill può allo stesso modo guidare un agente che usa strumenti MCP.

Per un riepilogo delle pull request, la skill potrebbe richiedere solo quelle aperte, selezionare pochi campi essenziali e vietare la pubblicazione di commenti durante la preparazione del rapporto. Credenziali e ambiente di esecuzione devono far rispettare i limiti effettivi di accesso. Le istruzioni scritte aiutano l'agente a comportarsi correttamente; non gli tolgono permessi.

Vincitore della categoria: le skill per le procedure ripetibili. Affiancano entrambe le interfacce e, quando vengono caricate, aggiungono a loro volta contesto.

MCP, API e CLI: mantenere unita la logica del servizio

Le regole di business vanno tenute nel servizio, esponendo poi le interfacce necessarie agli utenti. Un'API è l'interfaccia programmatica di un'applicazione. Può essere chiamata da una CLI come da un server MCP, come mostrano le interfacce di Stripe.

Se si mantengono entrambe, conviene riutilizzare autorizzazione e validazione anziché creare implementazioni concorrenti della regola «chi può modificare questo record». Il confronto MCP vs API spiega quando vale la pena aggiungere il livello di protocollo.

Un wrapper che accetta testo di shell arbitrario è una motivazione debole per migrare. Può rendere raggiungibile via MCP un esecutore di comandi esistente, ma ne conserva i poteri. Un adattatore utile espone un'operazione delimitata, ne valida gli input e restituisce soltanto le evidenze necessarie all'agente.

Tabella di scelta: partire dal contesto di utilizzo

Scegliere l'interfaccia minima che copre il compito senza ampliare i poteri disponibili. Queste sono configurazioni di partenza, non scelte irrevocabili.

Passare da MCP alla CLI, o viceversa

Migrare un flusso di lavoro, non l'intero inventario degli strumenti. La parte costosa è spesso preservare permessi, output e gestione degli errori, più che tradurre il nome di uno strumento in un comando.

Passare alla CLI significa predisporre installazione, credenziali, un esecutore di comandi, filtri per l'output e istruzioni riproducibili. Passare a MCP significa scegliere o gestire un server, configurare l'autenticazione del client, definire gli strumenti esposti e gestire gli errori tramite quell'interfaccia. Nei flussi che usano il browser va anche deciso esplicitamente a chi appartengono sessione e profilo.

Non cambiare un flusso CLI funzionante solo per aggiungere il supporto a un protocollo. Non eliminare un'integrazione MCP remota che serve persone senza shell soltanto perché un comando sembra più breve.

Altre guide pratiche per scegliere i flussi di lavoro degli agenti e delimitarne i permessi sono disponibili nella newsletter.

Domande frequenti