La necessità di questo sviluppo si è palesata lavorando in un contesto fortemente regolamentato come quello dell’AI nella PA, dove è importante fornire a ciascun assistente il set minimo di dati e documenti necessari alla risposta. Questo faceva sì che ogni nuovo assistente agentico per un cliente richiedesse tool dedicati, specialmente svariate tipologie di RAG che implementassero i filtri desiderati da ciascuno.
Ne conseguivano sviluppo e manutenzione moltiplicati e superficie di vulnerabilità crescente. L’alternativa diametralmente opposta, ovvero conferire un accesso pienamente agentico a sistemi e dati con il solo prompt a fare da confine, non regge in un contesto regolamentato su auditabilità e sicurezza. Anche l’utilizzo di MCP esterni non risolveva del tutto il problema, perché a parità di risorsa (ad esempio una collezione Weaviate) utenti diversi del sistema dovevano vedere parti diverse della documentazione, e non altre. I filtri e le tipologie di accesso alle risorse erano troppi per riuscire a tramutarli in una specifica di MCP associata al sistema da fruire.
Perciò, ho consolidato i tool frammentati in un unico server MCP interno (STDIO) che separa le primitive, mantenute centralmente (ricerca semantica, filtro esatto sui metadati, individuazione dei metadati, memoria conversazionale, chiamate API), dalla loro composizione in tool veri e propri, dichiarata in un file YAML: una decina di righe di configurazione per tool, senza scrivere codice. Il server consuma la configurazione e produce tool già calibrati sui confini del singolo agente.
Lo sviluppo di un agente per un nuovo cliente è passato da 4-5 giorni a mezza giornata, spesa sulla comprensione del dominio invece che sull’implementazione. La revisione di sicurezza si applica a un insieme ristretto di primitive centralizzate, le correzioni si propagano automaticamente a tutti i tool che le usano, e il collo di bottiglia si sposta dagli sviluppatori agli esperti di dominio, con una UI di back-office in arrivo per la composizione autonoma dei tool.
L’utilizzo del protocollo MCP per sviluppare questo layer di configurabilità dei tool ci permette di renderlo indipendente dall’orchestratore che lo avvolge, che può essere un loop agentico puro, un sistema a grafi come LangGraph e così via. L’importante è che il sistema di orchestrazione abbia un connettore per MCP, che è un requisito sempre più standard visto il successo che sta riscuotendo il protocollo proposto da Anthropic.
Il dettaglio dell’architettura e delle alternative scartate è nell’articolo su Agenda Digitale.