Esporre ogni operazione API come strumento MCP non scala nelle enterprise

Creare uno strumento del Model Context Protocol per ogni singola operazione API non regge alla scala di un’azienda grande¹.

Negli ultimi anni le organizzazioni hanno costruito programmi API completi per gestire i servizi interni. Oggi molte gestiscono migliaia di API interne, ognuna con un owner preciso e uno schema di autenticazione proprio. Questi sistemi custodiscono il contesto essenziale che serve agli agenti quando entrano in produzione: anagrafiche clienti, inventario, ticket di supporto¹.

MCP ha definito un modo standard per collegare gli agenti a strumenti esterni. La pratica comune, quando si espongono API tramite MCP, è creare uno strumento per ogni operazione API. Questa strategia può funzionare con pochi endpoint. Crolla quando si applica a un patrimonio enterprise ampio. Sistemi tipici, come CRM o ERP, contengono centinaia di operazioni. Se un agente deve usarne diverse, si ritrova davanti centinaia di definizioni di strumenti differenti. Il risultato è un sovraccarico già in partenza, prima ancora che l’agente inizi a lavorare sul caso d’uso¹.

L’approccio uno a uno produce tre problemi principali. Il primo è economico. Ogni definizione di strumento deve essere caricata nel contesto del modello prima che inizi il lavoro. Ogni risultato intermedio poi rientra attraverso il modello. In pratica l’organizzazione paga ogni passaggio in token. Il conto cresce con la moltiplicazione degli strumenti e con la necessità di passare attraverso il modello per orchestrare ogni singola chiamata¹.

L’effetto di scala emerge presto. Un sistema interno con centinaia di operazioni genera, con il mapping uno a uno, centinaia di strumenti. Ognuno contribuisce ad allargare il contesto iniziale che il modello deve caricare. Ognuno aumenta il numero potenziale di passaggi in cui i risultati intermedi tornano nel modello. La combinazione tra volume di definizioni e passaggi intermedi si traduce in costi che aumentano in fretta, proprio mentre l’agente dovrebbe concentrarsi sull’uso delle risorse interne per risolvere il compito¹.

La standardizzazione fornita da MCP risolve la connessione tra agenti e strumenti. Non riduce però la granularità delle operazioni esposte quando si adotta il mapping uno a uno. Se ogni operazione diventa uno strumento separato, l’agente deve comunque gestire un numero elevato di definizioni. In un contesto enterprise con molti sistemi e molte operazioni, il carico cognitivo aumenta perché l’agente si trova di fronte a un catalogo ampio di strumenti equivalenti per livello di dettaglio, ma diversi per definizione¹.

Per le aziende con un’estesa base di API interne, il punto critico è la scala. La combinazione tra molte operazioni per sistema, molte definizioni di strumenti da caricare e molti passaggi intermedi che attraversano il modello rende il mapping uno a uno costoso e ingombrante per gli agenti. È qui che l’approccio comune mostra i suoi limiti, non nel collegamento in sé, ma nella quantità di strumenti che finisce per produrre¹.