Quando i tool MCP funzionano male, di solito il problema non è il protocollo ma il modo in cui i tool sono progettati. È un articolo AWS, e parte da un’osservazione onesta: la strada più naturale è esporre una API esistente così com’è e sperare che l’agent capisca il resto. Per i casi semplici a volte basta. Spesso no, e le conseguenze sono tool call fallite, parametri sbagliati e retry che consumano context.
Gli autori riconducono quasi tutti i fallimenti a due cause. La prima è il bloat: le definizioni dei tool entrano nel context a ogni chiamata, usate o meno. Con più server MCP collegati, buona parte della finestra è già occupata prima ancora della domanda dell’utente, e man mano che il context si riempie la capacità di ragionamento del modello degrada. La seconda è la confusion: quando il ragionamento peggiora, l’LLM sceglie il tool sbagliato o passa valori errati, e ogni retry aggiunge altro bloat. Nomi ambigui e tool troppo simili tra loro peggiorano la situazione. Arricchire le descrizioni riduce la confusion, ma gonfia il context: è un equilibrio, non una soluzione a senso unico.
Il cuore pratico dell’articolo è una progressione di sei versioni che espongono lo stesso backend simulato di ricerca contenuti K-12, ciascuna con un design diverso. Vale la pena seguirne la logica.
Dalle descrizioni allo schema
Il punto di partenza è migliorare descrizioni, risposte ed errori. Un dettaglio concreto: se un tool restituisce cinquanta campi ma ne bastano cinque per decidere, conviene mandare di default solo quelli e offrire una vista dettagliata a richiesta. Anthropic stima che questo approccio on-demand tagli i token di risposta di circa due terzi. Allo stesso modo, un errore utile guida il tentativo successivo, mentre un secco “nessun risultato” lascia il modello a indovinare.
Il passo seguente sposta il lavoro sullo schema: rinominare i parametri secondo il dominio e non secondo le colonne del database, usare enum per i campi a valori finiti, impostare default sensati così che l’LLM specifichi solo ciò che varia. La AWS Prescriptive Guidance suggerisce di restare intorno a otto parametri o meno per tool. Poi arriva il lazy loading: tenere nel context solo hint brevi e spostare tassonomie e valori validi dietro un tool separato, caricato solo quando serve. Anthropic riporta fino all’ottantacinque percento di token in meno caricando le definizioni solo quando rilevanti.
Quando serve più controllo
Le ultime due versioni alzano il controllo: un tool di introspection appoggiato a un modello server-side che interpreta la richiesta e propone i filtri, e infine l’agent-as-tool, dove un intero agent con i suoi tool interni sta dietro un’unica interfaccia in linguaggio naturale. Più coerenza tra client diversi, in cambio di costo e latenza.
Nessuna versione vince su tutti i fronti. La scelta dipende dal numero di campi, dalla stabilità del vocabolario, dal budget di latenza e da quanto serve un comportamento coerente tra client diversi.
In sintesi
- Il collo di bottiglia dei tool MCP è il design, non il protocollo: bloat e confusion sono i due nemici da bilanciare.
- Le leve pratiche vanno dalle descrizioni e dagli errori utili fino a enum, default, lazy loading e introspection server-side.
- Più controllo significa più costo: l’agent-as-tool dà comportamento coerente tra client ma è la scelta con l’infrastruttura più pesante.
Hai qualcosa da aggiungere? Unisciti alla discussione.