MCP, CLI e Agent Skills: una lettura di ricerca sul tool use negli agent LLM
La domanda centrale non è quale interfaccia “vince”. La domanda interessante è più precisa: quale confine deve gestire protocollo, esecuzione, conoscenza procedurale e governance in un sistema di agent LLM?
Gli agent basati su LLM falliscono in modi che sembrano strani finché non si guarda al tool use come a un problema di carico cognitivo.
Un agent può avere a disposizione il tool corretto e scegliere comunque quello sbagliato. Può ricevere l'informazione rilevante e perderla dentro un prompt troppo lungo. Può produrre una chiamata formalmente valida ma fraintendere il workflow che dovrebbe circondarla. Può funzionare meglio con cinque tool che con venti.
Questi non sono solo errori del modello. Sono anche errori di interfaccia.
Model Context Protocol, interfacce a riga di comando e Agent Skills rispondono a parti diverse dello stesso problema. MCP standardizza discovery e invocazione. Le CLI offrono operazioni eseguibili e ispezionabili. Gli Skills codificano procedura, esempi, vincoli e recovery. API HTTP e gateway governati centralizzano autorizzazione e osservabilità.
Il problema nasce quando si prova a far portare tutti questi compiti a un unico registro locale di tool.
Questo articolo propone una lettura di ricerca del dibattito su MCP, CLI e Agent Skills. La conclusione è circoscritta: MCP via stdio è spesso un default debole per agent locali complessi; MCP via HTTP resta adatto a piattaforme governate; CLI + Skills è spesso un'architettura locale migliore perché separa esecuzione e conoscenza procedurale, e supporta la disclosure progressiva.
Background: il tool use è un problema a più stadi
Molte descrizioni del tooling per agent comprimono tutto in un passaggio: il modello chiama un tool.
Nella pratica, il tool use contiene almeno cinque stadi:
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 mostra spesso che questi stadi sono separabili. MetaTool studia se i modelli sanno quando usare strumenti e quali scegliere. WTU-EVAL valuta se un tool debba essere usato oppure no, invece di assumere che il tool use sia sempre necessario. ToolRet tratta il recupero dei tool come un problema autonomo, con un corpus ampio ed eterogeneo. ToolLLM ha esplorato training e valutazione su migliaia di API reali.
L'implicazione è netta: un'interfaccia che espone soltanto funzioni chiamabili risolve la superficie di esecuzione, non l'intero problema.
Un agent deve sapere cosa esiste, cosa conta in quel momento, quale ordine seguire, cosa significa un errore e quando non chiamare nulla. Per questo metadata, layout del contesto, discoverability dei comandi e istruzioni procedurali non sono dettagli implementativi. Sono parte dell'ambiente di ragionamento dell'agent.
MCP: uno standard, non un'architettura completa
MCP è importante perché standardizza un confine reale di integrazione. Il protocollo offre ai client un modo comune per scoprire capability, chiamare tool, leggere risorse e interagire con sistemi esterni. La specifica ufficiale definisce trasporti come stdio e Streamable HTTP, e l'ecosistema MCP ha creato un vocabolario condiviso per connettere agent e strumenti.
Questa standardizzazione ha valore. Prima di protocolli condivisi, ogni integrazione rischiava di diventare un ponte custom: un plugin per una app, un connettore per un client, un adapter scritto a mano per ogni workflow.
Ma MCP non è un'architettura completa per agent. Definisce come comunicano client e server. Non risolve automaticamente retrieval dei tool, budget di prompt, sequenziamento dei workflow, debuggabilità umana o la domanda più importante: quanta superficie di tool dovrebbe entrare nel contesto del modello?
La distinzione tra stdio e HTTP è fondamentale.
MCP via stdio è comodo per integrazioni locali. Il client avvia un subprocess e scambia messaggi JSON-RPC su stdin/stdout. Questa comodità rende semplice sperimentare, ma crea anche un confine delicato: stdout deve restare pulito per il protocollo, i log devono andare altrove, le credenziali passano spesso dall'ambiente e il debug attraversa log del client, log del server, interpretazione dello schema e comportamento del modello.
MCP via HTTP è più adatto a piattaforme governate. Un deployment HTTP può stare dietro OAuth, policy, identità di servizio, audit log, telemetry e gestione centralizzata del ciclo di vita. In quel contesto il confine di protocollo svolge un lavoro organizzativo reale.
Il contesto non è gratis
La principale obiezione tecnica ai grandi registri locali di tool riguarda il carico di contesto.
Schema, descrizioni, esempi e parametri dei tool non sono neutrali. Quando entrano nel prompt, competono con task dell'utente, codice, evidenze recuperate, decisioni precedenti e vincoli di sicurezza. Più contesto non significa automaticamente più capacità.
La ricerca sui long context lo mostra da anni. In Lost in the Middle, i modelli usano peggio l'informazione quando l'evidenza rilevante si trova nella parte centrale di contesti lunghi. Large Language Models Can Be Easily Distracted by Irrelevant Context mostra che informazioni irrilevanti possono ridurre l'accuratezza nel problem solving. Lavori più recenti su come la sola lunghezza del contesto possa peggiorare la performance nonostante retrieval perfetta suggeriscono che input più lunghi possono degradare le risposte anche quando l'informazione utile è presente.
La stessa logica vale per le definizioni dei tool. Se un agent vede decine o centinaia di affordance irrilevanti per il task corrente, l'interfaccia ha creato un problema di distrazione prima ancora che il modello inizi a ragionare.
Microsoft Research descrive questo fenomeno come tool-space interference: aggiungere tool singolarmente ragionevoli può ridurre la performance end-to-end quando lo spazio complessivo diventa più difficile da navigare. 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 in ogni contesto. Offrono una scomposizione diversa del problema locale.
La CLI è il substrato di esecuzione. Dà a umani e agent la stessa superficie operativa: subcommand, help, flag, exit code, output strutturato, autenticazione e composabilità nella shell. Una buona CLI si usa nel terminale, in uno script, in CI, nella documentazione e in una sessione agent senza cambiare interfaccia.
Lo Skill è il livello procedurale. Il post tecnico di Anthropic su Agent Skills descrive un modello di disclosure progressiva: prima sono disponibili solo metadata leggeri, le istruzioni complete vengono caricate quando servono, e riferimenti o script di supporto vengono consultati solo se necessari.
Questo conta perché evita di caricare nel prompt base troppa conoscenza procedurale. L'agent parte da un indice, non da un manuale completo.
Il pattern è coerente con una lezione ricorrente della ricerca sul tool use: selezione ed esecuzione sono problemi diversi. Una CLI può essere eccellente nell'esecuzione, mentre uno Skill aiuta il modello a selezionare, ordinare e interpretare le operazioni.
Per esempio, una CLI può esporre:
statusper lo stato correntelistper l'inventariocreateper il provisioningdeleteper operazioni distruttive--jsonper output strutturato--helpper discovery on demand
Uno Skill può codificare:
- ispeziona prima di mutare
- usa modalità dry-run quando disponibili
- chiedi conferma prima di operazioni distruttive
- ritenta solo su errori transitori specifici
- riassumi l'output invece di incollarlo tutto
- fermati quando mancano credenziali o permessi
MCP può esporre capacità simili, ma MCP via stdio tende spesso a renderle funzioni passive. CLI + Skills rende esplicita la separazione.
Dove MCP resta utile
Una lettura orientata alla ricerca deve evitare di sostituire una risposta universale con un'altra.
MCP via HTTP rimane un buon candidato quando il sistema ha bisogno di governance centralizzata. Le grandi organizzazioni richiedono spesso autenticazione, autorizzazione, audit log, telemetry, policy e ownership di servizio coerenti. Una collezione frammentata di CLI locali non fornisce naturalmente queste garanzie.
MCP via stdio resta ragionevole per piccoli bridge locali con superfici ristrette. Se un tool ha due o tre azioni stabili, nessun workflow complesso e nessuna necessità di essere usato direttamente da umani, l'overhead può essere accettabile.
Il default debole non è MCP in sé. Il default debole è usare MCP locale come wrapper universale per ogni comando, servizio, sorgente documentale, helper database, automazione browser e procedura interna.
Principi di design per interfacce agent-tool
I principi pratici sono semplici.
Ridurre il contesto sempre caricato. Nel contesto base dovrebbero entrare solo indici, nomi e descrizioni di trigger. Procedure complete e materiale di riferimento andrebbero caricati quando servono.
Separare esecuzione e istruzione. Le superfici di esecuzione dovrebbero essere deterministiche, scriptabili e ispezionabili. La guida procedurale dovrebbe vivere in Skills, documentazione, policy o prompt specifici del task.
Preservare la debuggabilità umana. Se un agent lancia un comando, un umano dovrebbe poterlo rilanciare, ispezionare l'output e capire perché è stato scelto.
Trattare il retrieval dei tool come un problema di primo livello. Corpus ampi richiedono retrieval, routing, ranking o scoping prima della selezione. Scaricare ogni tool possibile nel contesto del modello è una baseline fragile.
Scegliere 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 è in realtà un dibattito sulla gestione del contesto.
Gli agent LLM non diventano affidabili solo perché possono chiamare più tool. Diventano affidabili quando lo spazio dei tool è delimitato, le informazioni rilevanti vengono caricate al momento giusto, la conoscenza del workflow è esplicita e l'esecuzione resta ispezionabile.
Per gli agent locali di sviluppo, CLI + Skills offre spesso una scomposizione migliore: la CLI esegue il lavoro, lo Skill insegna il workflow e l'agent non porta nel contesto dettagli irrilevanti finché non servono. Per piattaforme enterprise, MCP via HTTP mantiene un ruolo forte perché la governance è parte del sistema.
Lo stato finale non è “tutto diventa un server MCP”. È un'architettura a livelli in cui ogni confine viene scelto per il lavoro che deve davvero svolgere.
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.