Strumenti MCP non pensati per gli LLM intasano il contesto

Colleghi più server MCP a un agente. Ogni server pubblica strumenti. Le definizioni entrano nel contesto del modello a ogni passo, anche se nessuno le userà. Prima della prima domanda, una quota di contesto è già occupata. Il ragionamento si accorcia. Le prestazioni calano¹.

Il punto non è il protocollo. È il design dei tool. Molti team espongono l’API “as‑is” e sperano che l’agente capisca. A volte funziona. Spesso no. Gli autori chiamano “bloat” l’ingombro inutile: ogni definizione compete con i token che servono al modello per pensare. Con più server collegati, l’ingombro cresce e la sessione perde qualità¹. Quando il ragionamento si accorcia, l’agente sbaglia di più l’uso degli strumenti: parametri incoerenti, chiamate fallite, retry che aggiungono testo e sottraggono ulteriore spazio. Il ciclo si autoalimenta¹.

La tesi è netta: progettare strumenti per come lavorano i modelli e i sistemi agentici, non accanto a loro. Non serve cambiare MCP. Servono tool pensati per il contesto limitato in cui vivono¹.

L’approccio è pratico: curare cosa entra nel contesto a ogni passo. Ridurre la verbosità. Evitare opzioni ambigue. Minimizzare il rischio di confusione nella scelta e nell’uso dello strumento. Obiettivo: preservare il ragionamento, limitando errori, parametri sbagliati e ritentativi costosi¹.

Micro‑esempio. Una definizione prolissa descrive un parametro con più formulazioni possibili. Il modello prova una variante, fallisce, tenta la seconda, poi la terza. Ogni retry aggiunge testo, riduce contesto utile e peggiora la scelta successiva. Il problema non è la chiamata in sé, ma la definizione che la induce¹.

Esporre un’API “as‑is” può bastare su percorsi lineari. Nella maggior parte dei casi no. Senza design centrato sul comportamento dei modelli, emergono attriti: chiamate che non vanno a buon fine, campi compilati male, ripetizioni che consumano contesto e degradano le risposte¹.

Gli autori parlano di “context engineering” pragmatico: decidere con precisione cosa il modello deve leggere, come selezionerà e combinerà le informazioni durante la scelta del tool e come limitare i pattern che inducono retry e degrado progressivo. Qui si gioca la differenza tra uno strumento che aiuta l’agente e uno che lo rallenta¹.

Tre mosse operative:

• Riduci la verbosità delle definizioni. Tieni solo ciò che serve alla scelta e all’uso.
• Elimina opzioni ambigue che aprono più interpretazioni e percorsi di retry.
• Nomina parametri e campi in modo univoco, così da prevenire compilazioni incoerenti¹.

Finché il contesto resta il vincolo, ogni server in più amplifica l’ingombro. Senza ripensare i tool, gli agenti spenderanno token a gestire definizioni invece di risolvere compiti¹.