MCP di dominio: la governance delle fonti per agenti aziendali

Un agente che naviga il web per rispondere a una domanda clinica può finire su PubMed, su un blog, su Reddit o su un articolo SEO — e nel testo finale non si vede la differenza. Un MCP di dominio elimina quell'ambiguità non perché "cerca meglio", ma perché restringe per costruzione lo spazio delle fonti possibili: è una decisione di governance, non un'ottimizzazione tecnica.

Due modi di procurare dati a un agente, non uno

Quando si progetta un agente aziendale con accesso a fonti esterne, la domanda che conta non è "quale strumento di ricerca è più bravo" ma "quale spazio di fonti l'agente può attraversare". Ci sono due modi strutturalmente diversi di rispondere.

Web browsing come discovery tool vs. MCP di dominio come data access tool

Il web browsing è uno strumento di scoperta: l'agente interroga un motore di ricerca, riceve pagine HTML eterogenee — blog, forum, siti istituzionali, aggregatori SEO — e deve interpretarle per estrarne informazione. È potente perché lo spazio di ricerca è enorme, ma proprio per questo imprevedibile: la stessa domanda posta due volte può restituire fonti diverse.

Un MCP (Model Context Protocol) di dominio funziona diversamente: espone un set dichiarato di tool — tipicamente ricerca e recupero — su una singola fonte strutturata. Non naviga il web: interroga direttamente un'API o un database, e riceve dati già normalizzati (campi distinti per titolo, autore, data, identificativo) invece di pagine da interpretare.

Perché la differenza non è "quale cerca meglio" ma "quale spazio di fonti è ammesso"

Il punto non è la qualità del singolo risultato. Con il web browsing lo spazio delle fonti possibili è, di fatto, tutto il web indicizzato: non c'è modo di garantire a priori che l'agente non finisca su un blog o un contenuto sponsorizzato. Con un MCP di dominio lo spazio è dichiarato e fisso: solo quella fonte, solo quei tipi di record. Non è una garanzia di qualità del contenuto — un MCP non valuta se uno studio è buono — ma è una garanzia di provenienza: si sa sempre da dove viene il dato.

Un esempio fra i tanti: pubmedmcp

Un esempio concreto di questo pattern è pubmedmcp (progetto community sviluppato dall'autore indipendente grll, non uno standard ufficiale), che espone due sole capacità — ricerca e recupero di articoli — su PubMed, appoggiandosi a una libreria client (pubmedclient) per dialogare con le API NCBI. Non è un motore medico intelligente: è un adapter minimale.

Con web browsing, rispondere a una richiesta clinica come "trova gli studi degli ultimi 5 anni su un certo trattamento, poi confronta RCT, review e case report" richiede all'agente di cercare, aprire risultati, interpretare HTML, individuare identificativi ed estrarre dati a mano. Con un MCP di dominio lo stesso compito diventa: interroga la fonte → ricevi una lista di identificativi → recupera i record → ragiona su dati già strutturati.

Lo stesso pattern esiste per altri domini: esistono MCP community per fonti come Crossref, ClinicalTrials o Zotero — nessuno di questi progetti ha uno status di standard ufficiale, sono iniziative indipendenti con adozione variabile, ma il principio architetturale è lo stesso: un perimetro di fonte dichiarato, non un web aperto.

Quattro motivi per cui questo conta a livello di governance

Provenienza controllabile

Lo spazio delle fonti è dichiarato in anticipo, non emerge dal comportamento dell'agente in runtime. Chi audita un output sa già, prima ancora di leggerlo, da quale insieme di fonti può provenire.

Determinismo e riproducibilità

Le chiamate a un MCP di dominio seguono uno schema stabile (cerca, recupera); una pagina web può cambiare struttura, contenuto, persino sparire. La stessa interrogazione ripetuta nel tempo è più prevedibile.

Metadati strutturati = output auditabile

Un MCP restituisce campi distinti — identificativo, titolo, autori, data — non prosa da cui estrarre a mano. L'output finale può citare quei campi in modo verificabile, non solo raccontare una fonte.

Superficie di rischio ridotta

Meno testo non controllato (pagine web arbitrarie, contenuti SEO, istruzioni nascoste in una pagina) entra nel contesto del modello. Non è un argomento sulla qualità dei contenuti, è un argomento sulla superficie di attacco.

Il limite onesto: quando un MCP di dominio non serve

Ricerca occasionale singola

Per una domanda isolata, non ripetuta, un buon agente con web browsing produce probabilmente un risultato comparabile — resta una valutazione di buon senso più che un dato misurato, ma è ragionevole assumerla come punto di partenza. Il valore di un MCP di dominio non sta nel singolo utilizzo.

Il vero spartiacque è il tipo di workflow

Il vantaggio cresce con la ripetitività e la criticità: pipeline automatiche, dataset di centinaia di record, filtri sistematici, output che devono reggere un audit. Per un workflow occasionale, il costo di integrare e mantenere un MCP dedicato può non giustificarsi.

Imporre una policy epistemica all'agente

Da "tool comodo" a requisito di governance

Un MCP di dominio permette di scrivere regole esplicite: "per claim clinici, interroga solo questa fonte, privilegia studi controllati e review sistematiche, cita sempre l'identificativo del record". Non è più una scelta lasciata all'agente in runtime: è una policy imposta a monte, verificabile a valle.

Composabilità controllata

Più MCP di dominio (una fonte scientifica, un registro di citazioni, un archivio interno) si compongono in pipeline dove ciascuno resta un perimetro dichiarato. Il web browsing resta invece una capacità generica, difficile da vincolare allo stesso modo.

Checklist: cosa chiedere in fase di procurement/design di un agente

• Quali classi di claim (clinici, legali, finanziari) richiedono una fonte vincolata, e quali possono restare su ricerca aperta?
• Esistono MCP di dominio disponibili per le fonti rilevanti al proprio settore, e chi li mantiene?
• Come si verifica, per ogni output, la provenienza del dato citato?
• L'output finale espone identificativi verificabili (non solo prosa) per ogni claim che lo richiede?
• Chi decide, e con quale criterio, quando un workflow giustifica l'integrazione di un MCP dedicato invece del web browsing generico?

Conclusione

Il web browsing massimizza il recall: trova di tutto, in cambio di un'ambiguità di fondo sulla fonte. Un MCP di dominio massimizza struttura, provenienza e controllabilità, al costo di uno spazio di ricerca più stretto. Nessuno dei due è "meglio" in assoluto: la scelta va fatta a monte, in fase di design e procurement dell'agente, non lasciata decidere all'agente stesso in runtime.

Se stai valutando un agente aziendale con accesso a fonti esterne, la domanda da mettere per iscritto non è "che tool di ricerca usa", ma "quale spazio di fonti è disposto ad attraversare, e chi lo ha deciso".

Fonti

• grll/pubmedmcp — server MCP per PubMed usato come esempio (progetto community, licenza MIT).
• grll/pubmedclient — libreria Python client delle API NCBI usata da pubmedmcp.
• Model Context Protocol — specification, sezione "Tools": definizione di tool e di server MCP.
• kujenga/zotero-mcp — esempio di MCP di dominio per Zotero.
• cyanheads/clinicaltrialsgov-mcp-server — esempio di MCP di dominio per ClinicalTrials.gov.