MCP, CLI e Agent Skills: una lettura di ricerca sul tool use negli agent LLM

La domanda giusta non è quale interfaccia "vince". È più precisa, e più scomoda: in un sistema di agent LLM, quale confine deve farsi carico di protocollo, esecuzione, conoscenza procedurale e governance?

Gli agent LLM falliscono in modi che sembrano bizzarri — finché non si inizia a trattare il tool use per quello che è: un problema di carico cognitivo.

Un agent può avere a disposizione il tool giusto e sceglierne comunque un altro. Può ricevere l'informazione che gli serve e smarrirla in un prompt chilometrico. Può produrre una chiamata formalmente impeccabile avendo frainteso il workflow che doveva starci attorno. E può lavorare meglio con cinque tool che con venti.

Non sono soltanto errori del modello. Sono errori di interfaccia.

Model Context Protocol, interfacce a riga di comando e Agent Skills rispondono ciascuno a un pezzo diverso dello stesso problema. MCP standardizza discovery e invocazione. Le CLI mettono sul tavolo operazioni eseguibili e ispezionabili. Gli Skills codificano procedure, esempi, vincoli, strategie di recovery. Le API HTTP e i gateway governati accentrano autorizzazione e osservabilità.

Il guaio comincia quando si pretende che un unico registro locale di tool faccia tutti questi mestieri insieme.

Questo articolo prova a dare una lettura di ricerca al dibattito su MCP, CLI e Agent Skills. La conclusione è volutamente circoscritta: MCP via stdio è spesso un default debole per agent locali complessi; MCP via HTTP resta la scelta giusta per piattaforme governate; CLI + Skills è di frequente l'architettura locale migliore, perché separa l'esecuzione dalla conoscenza procedurale e sostiene la disclosure progressiva.

Background: il tool use è un problema a più stadi

Quasi tutte le descrizioni del tooling per agent comprimono la faccenda in un unico passaggio: il modello chiama un tool. Fine.

Nella pratica, di stadi ce ne sono almeno cinque:

loop di tool use
├── decidere se serve davvero un tool
├── recuperare o notare i tool candidati
├── scegliere il tool adatto al task
├── compilare argomenti validi
└── interpretare il risultato dentro un workflow più ampio

La ricerca sul tool learning continua a dimostrare che questi stadi si possono studiare — e sbagliare — separatamente. MetaTool misura se i modelli sanno quando usare uno strumento e quale scegliere. WTU-EVAL si chiede se un tool vada usato o no, invece di dare per scontato che serva sempre. ToolRet tratta il recupero dei tool come un problema a sé, con un corpus ampio ed eterogeneo. ToolLLM ha esplorato training e valutazione su migliaia di API reali.

La conseguenza è netta: un'interfaccia che si limita a esporre funzioni chiamabili risolve la superficie di esecuzione. Tutto il resto del problema rimane lì.

Un agent deve sapere cosa esiste, cosa conta in questo momento, in che ordine muoversi, cosa significa un errore e quando la mossa giusta è non chiamare niente. Ecco perché metadata, layout del contesto, discoverability dei comandi e istruzioni di workflow non sono dettagli implementativi: sono l'ambiente in cui l'agent ragiona.

MCP: uno standard, non un'architettura completa

MCP conta perché standardizza un confine di integrazione reale. Dà ai client un modo comune per scoprire capability, chiamare tool, leggere risorse, dialogare con sistemi esterni. La specifica ufficiale definisce trasporti come stdio e Streamable HTTP, e attorno a MCP si è formato un vocabolario condiviso per collegare agent e strumenti.

È un valore vero. Prima dei protocolli condivisi, ogni integrazione rischiava di diventare un ponte artigianale: un plugin per quell'app, un connettore per quel client, un adapter scritto a mano per ogni workflow.

Ma MCP non è un'architettura completa per agent. Definisce come si parlano client e server — e basta. Non risolve il retrieval dei tool, il budget di prompt, il sequenziamento dei workflow, la debuggabilità umana, né la domanda che sta sopra tutte le altre: quanta superficie di tool deve davvero entrare nel contesto del modello?

E la distinzione tra stdio e HTTP non è un dettaglio.

MCP via stdio è comodo per le integrazioni locali. Il client lancia un subprocess e scambia messaggi JSON-RPC su stdin/stdout. La comodità però ha un rovescio: quel confine di processo è fragile. Stdout deve rimanere pulito per il protocollo, i log devono trovare casa altrove, le credenziali finiscono quasi sempre nelle variabili d'ambiente, e un bug si insegue attraverso log del client, log del server, interpretazione dello schema e comportamento del modello. Quattro strati per un solo errore.

MCP via HTTP gioca un altro campionato: le piattaforme governate. Un deployment HTTP può stare dietro OAuth, policy, identità di servizio, audit log, telemetry, gestione centralizzata del ciclo di vita. Lì il confine di protocollo svolge un lavoro organizzativo che nessuna CLI locale può offrire.

Il contesto non è gratis

L'obiezione tecnica più solida ai grandi registri locali di tool riguarda il carico di contesto.

Schema, descrizioni, esempi e parametri dei tool non sono neutri. Una volta dentro il prompt, competono per l'attenzione del modello con il task dell'utente, il codice, le evidenze recuperate, le decisioni già prese, i vincoli di sicurezza. Più contesto non vuol dire più capacità. A volte vuol dire il contrario.

La ricerca sui long context lo ripete da anni. In Lost in the Middle, i modelli usano peggio l'informazione quando l'evidenza rilevante finisce nella parte centrale di un contesto lungo. Large Language Models Can Be Easily Distracted by Irrelevant Context mostra che l'informazione irrilevante abbassa l'accuratezza nel problem solving. E lavori più recenti su come la sola lunghezza del contesto peggiori la performance anche con retrieval perfetta suggeriscono che input più lunghi degradano le risposte perfino quando l'informazione utile c'è tutta.

Per le definizioni dei tool vale la stessa logica. Se un agent si trova davanti decine o centinaia di affordance che non c'entrano nulla con il task corrente, l'interfaccia gli ha creato un problema di distrazione prima ancora che inizi a ragionare.

Microsoft Research ha dato un nome al fenomeno: tool-space interference — aggiungere tool singolarmente ragionevoli può peggiorare la performance end-to-end, perché lo spazio complessivo diventa più difficile da navigare. Attenzione: non è un argomento contro i tool. È un argomento a favore del design dello spazio dei tool.

CLI + Skills come disclosure progressiva

CLI e Agent Skills non sostituiscono i protocolli sempre e comunque. Propongono una scomposizione diversa del problema locale — e, spesso, migliore.

La CLI è il substrato di esecuzione. Offre a umani e agent la stessa identica superficie operativa: subcommand, help, flag, exit code, output strutturato, autenticazione, composabilità nella shell. Una buona CLI si usa nel terminale, in uno script, in CI, nella documentazione e in una sessione agent senza cambiare di una virgola.

Lo Skill è il livello procedurale. Il post tecnico di Anthropic sugli Agent Skills descrive un modello di disclosure progressiva: prima sono visibili solo metadata leggeri, le istruzioni complete si caricano quando diventano pertinenti, e riferimenti o script di supporto si consultano solo se servono davvero.

È il punto che cambia la partita: la conoscenza procedurale sta fuori dal prompt base. L'agent parte da un indice, non da un manuale da cinquecento pagine.

Il pattern combacia con una lezione ricorrente della ricerca sul tool use: selezione ed esecuzione sono problemi diversi. Una CLI può essere eccellente nell'eseguire; uno Skill è quello che aiuta il modello a scegliere, ordinare e interpretare le operazioni.

Un esempio concreto. Una CLI può esporre:

• status per lo stato corrente
• list per l'inventario
• create per il provisioning
• delete per le operazioni distruttive
• --json per l'output strutturato
• --help per la discovery on demand

E uno Skill può codificare le regole del mestiere:

• ispeziona prima di mutare
• preferisci il dry-run quando esiste
• chiedi conferma prima di distruggere qualcosa
• ritenta solo su errori transitori specifici
• riassumi l'output invece di incollarlo per intero
• fermati se mancano credenziali o permessi

MCP può esporre capacità simili, ma via stdio tende a ridurle a funzioni passive in un elenco. CLI + Skills rende la separazione esplicita — e visibile a chiunque debba metterci le mani.

Dove MCP resta la scelta giusta

Una lettura seria deve evitare la trappola di sostituire una risposta universale con un'altra.

MCP via HTTP resta un ottimo candidato quando il sistema ha bisogno di governance centralizzata. Le grandi organizzazioni vogliono autenticazione, autorizzazione, audit log, telemetry, policy e ownership di servizio coerenti — e una manciata di CLI locali sparse non offre nulla di tutto questo per costruzione.

MCP via stdio resta ragionevole per piccoli bridge locali dalla superficie ristretta. Due o tre azioni stabili, nessun workflow complesso, nessun bisogno di esecuzione condivisa con gli umani: in quel perimetro, l'overhead si può accettare.

Il default debole, insomma, non è MCP. Il default debole è usare MCP locale come wrapper universale attorno a ogni comando, servizio, sorgente documentale, helper di database, automazione browser e procedura interna. Tutto, indiscriminatamente.

Principi di design per interfacce agent-tool

I principi operativi stanno in cinque righe.

Riduci il contesto sempre caricato. Nel contesto base entrano indici, nomi e descrizioni di trigger. Le procedure complete e il materiale di riferimento si caricano quando servono, non prima.

Separa esecuzione e istruzione. Le superfici di esecuzione devono essere deterministiche, scriptabili, ispezionabili. La guida procedurale vive negli Skills, nella documentazione, nelle policy o nei prompt specifici del task.

Preserva la debuggabilità umana. Se un agent ha lanciato un comando, un umano deve poterlo rilanciare, guardarne l'output e capire perché è stato scelto proprio quello.

Tratta il retrieval dei tool come un problema di prima classe. I corpus ampi richiedono retrieval, routing, ranking o scoping prima della selezione. Rovesciare ogni tool possibile nel contesto del modello è una baseline fragile.

Scegli il trasporto in base al confine di governance. Stdio è una comodità di processo locale. HTTP è un confine di piattaforma. La CLI è un confine di esecuzione. Gli Skills sono un confine di workflow.

Conclusione

Il dibattito su MCP, CLI e Agent Skills, a guardarlo da vicino, è un dibattito sulla gestione del contesto travestito da guerra di standard.

Gli agent LLM non diventano affidabili perché possono chiamare più tool. Diventano affidabili quando lo spazio dei tool è delimitato, l'informazione giusta arriva al momento giusto, la conoscenza del workflow è esplicita e l'esecuzione si può ispezionare.

Per gli agent locali di sviluppo, CLI + Skills offre quasi sempre la scomposizione migliore: la CLI fa il lavoro, lo Skill insegna il mestiere, e l'agent tiene fuori dal contesto tutto ciò che non serve — finché non serve. Per le piattaforme enterprise, MCP via HTTP conserva un ruolo forte, perché lì la governance non è un accessorio: è parte del sistema.

Il punto d'arrivo non è "tutto diventa un server MCP". È un'architettura a livelli in cui ogni confine viene scelto per il lavoro che deve davvero svolgere. Come in ogni sistema ben progettato, del resto.

Fonti: specifiche MCP su trasporti e autorizzazione; annuncio Anthropic sulla donazione di MCP e nota tecnica su Agent Skills; Microsoft Research su tool-space interference; Liu et al. sul fenomeno lost-in-the-middle nei long context; Shi et al. sulla distrazione da contesto irrilevante; lavori Amazon Science/arXiv su lunghezza del contesto e performance; MetaTool, WTU-EVAL, ToolRet, ToolLLM, MCP-Atlas e letteratura survey sul tool learning negli LLM.