Integrare gli agenti senza adattatori su misura: i protocolli MCP e A2A

Un agente AI - il programma che usa un modello di linguaggio di grandi dimensioni, un LLM, per svolgere compiti e non solo per rispondere - vale quanto le cose a cui può accedere: gli archivi, i gestionali, i calendari, gli altri agenti. E fino a ieri ogni accesso aveva lo stesso prezzo: un adattatore scritto su misura, da rifare a ogni aggiornamento. Poi, in meno di due anni, il campo ha fatto quello che il software fa di rado così in fretta: si è dato una lingua comune. Le lingue rimaste sono due, diverse per mestiere e per maturità: MCP, il Model Context Protocol, per il dialogo fra un agente e i suoi strumenti, che il mercato ha già adottato dappertutto; e A2A, l’Agent2Agent, per il dialogo fra agenti, che ha raccolto un consenso larghissimo ma aspetta ancora la prova sul campo. Questo pezzo racconta cosa sono, chi li governa e dove si vede la differenza.

Il problema: ogni integrazione un progetto a sé

Senza uno standard, l’agente parla con ogni sistema in un dialetto diverso, e ogni dialetto è un costo.

Prima degli standard, collegare un agente a un sistema aziendale voleva dire scrivere l’adattatore: chi scrive ne ha costruiti, e ogni cambio di versione del sistema collegato li rompeva uno a uno. Il costo non stava tanto nello scriverli quanto nel mantenerli: dieci sistemi per dieci agenti fanno cento adattatori, ognuno con la sua manutenzione. Ancora all’inizio del 2025, del resto, il campo parlava di «standard emergenti» al plurale, e ogni produttore proponeva il suo formato. È lo stesso problema che le reti risolsero con TCP/IP e il web con HTTP e HTML: finché la lingua è privata, ogni conversazione ha bisogno del suo interprete, e ogni interprete va scritto e mantenuto.

Prima dei protocolli: l’agente, il contesto, gli strumenti

L’agente lavora a cicli fra modello, contesto e strumenti: lì si vede dove MCP si innesta.

Per capire dove si innestano i protocolli serve il quadro minimo di come lavora un agente; il disegno completo lo raccontano i pezzi di questa serie sull’architettura di un agente e sull’harness. Il cuore è un ciclo in quattro tempi. Arriva la domanda dell’utente. L’harness - l’impalcatura che circonda il modello - carica gli strumenti: le loro dichiarazioni, ognuna con nome, parametri e una descrizione di cosa fa, entrano nel contesto, la memoria di lavoro dove già stanno le istruzioni e la conversazione. Poi il modello analizza e chiama: legge il contesto, decide quale strumento serve, l’harness esegue davvero l’azione e rimette il risultato nel contesto - e il ciclo si ripete, una chiamata dopo l’altra, finché il modello ha ciò che gli serve. Infine compone la risposta con quello che ha raccolto.

Va tenuto fermo un fatto: il modello, di norma, è remoto - gira sui server del suo produttore - e da lì non vede né tocca nulla dei sistemi di chi lo usa. È l’harness a dargli occhi e mani: tutto ciò che il modello legge glielo porta l’harness nel contesto, e tutto ciò che fa passa dagli strumenti che l’harness esegue per lui - leggere un file, cercare sul web, eseguire un comando. Una volta scoperte e caricate, le dichiarazioni degli strumenti restano nel contesto per tutta la conversazione - il contesto cresce e non si svuota mai. E a ogni chiamata l’harness lo reinvia per intero, perché il modello non conserva memoria fra una chiamata e l’altra: ogni richiesta è nuova, e porta con sé istruzioni, dichiarazioni, conversazione e tutti i risultati già raccolti.

Qui si vede il punto esatto in cui MCP si innesta: un server MCP aggiunge strumenti a quella stessa dichiarazione, senza toccare l’harness. I server si registrano nella configurazione dell’harness, che li carica quando parte: all’avvio lancia come processi quelli locali e raggiunge via web quelli remoti, e da lì la connessione resta viva per tutta la sessione - l’architettura del protocollo definisce il client proprio come il componente che «mantiene la connessione» col server. L’agente che ieri sapeva leggere i file oggi sa anche interrogare il gestionale, perché il client MCP ha portato nel contesto le dichiarazioni del server - nome, parametri, descrizione - e l’esecuzione, quando il modello chiama, va al server invece che alla macchina. Tutto ciò che l’agente sa fare passa dal contesto: è la chiave per capire sia la forza dei protocolli sia il loro limite, che incontreremo più avanti.

MCP: lo standard che collega l’agente agli strumenti

Un protocollo aperto per collegare le applicazioni AI a dati e strumenti: nato in casa Anthropic, oggi lo adottano anche i concorrenti.

La prima delle due lingue è il Model Context Protocol (MCP), presentato da Anthropic nel novembre 2024 come standard aperto «per collegare gli assistenti AI ai sistemi dove vivono i dati». Il sito ufficiale lo definisce oggi uno standard open source per connettere le applicazioni AI a fonti di dati, strumenti e flussi di lavoro: il paragone che la stessa documentazione usa è la presa USB-C, un attacco unico al posto di dieci spine diverse. In pratica: un sistema espone un server MCP che dichiara i propri strumenti - «cerca», «leggi», «crea», ognuno con nome e parametri - e qualunque agente compatibile li scopre e li usa, senza adattatori scritti apposta.

La prova che non è lo standard di un solo produttore sta nelle case dei concorrenti: il sito ufficiale elenca fra i client Claude e ChatGPT, Visual Studio Code e Cursor, e la documentazione di OpenAI dedica a MCP una sezione della propria piattaforma per agenti. E il protocollo è uscito dalla fase pionieristica anche nella sostanza: la specifica è già alla quarta revisione, e l’ultima, del 25 novembre 2025, è intervenuta proprio sui punti deboli dei primi anni - l’autorizzazione, i compiti di lunga durata che un agente può seguire nel tempo, e l’aggiornamento delle buone pratiche di sicurezza. Il governo è della stessa pasta: la tabella di marcia 2026, pubblicata dai manutentori, descrive gruppi di lavoro, proposte di modifica formalizzate e priorità dettate «dall’esperienza di produzione in aziende grandi e piccole».

MCP: cosa offre un server, i protocolli di colloquio e un limite

Un server offre più che strumenti, i protocolli di colloquio hanno un criterio netto, MCP avvolge le API senza sostituirle, e il limite è uno: il catalogo dichiarato intasa il contesto.

Vale la pena aprire il cofano, perché il protocollo è più ricco di come lo si racconta. Un server MCP non offre solo strumenti: la documentazione ufficiale ne descrive tre, distinte:

• gli strumenti sono le azioni che il modello può invocare, con ingressi e uscite tipizzati;
• le risorse sono dati - file, basi dati, API, cioè le interfacce di programmazione - che l’applicazione può leggere e dare al modello come contesto;
• le richieste pronte (i prompt del protocollo) sono modelli di interazione predisposti dal server, che l’utente richiama esplicitamente.

L’architettura prevede due trasporti, cioè due modi di parlarsi fra client e server. Il primo è lo stdio, il canale d’ingresso e uscita dei programmi - la console: il client avvia il server sulla propria macchina e i due si parlano lì, senza rete. Il secondo è lo Streamable HTTP: il server è un servizio remoto via web, e tipicamente serve molti client insieme. Il criterio di scelta è netto. Lo stdio è la via dei server che girano tipicamente in locale, accanto all’agente - i file, gli attrezzi di sviluppo - per un utente solo, con la sicurezza affidata alla macchina su cui girano. I server HTTP possono invece essere remoti e, soprattutto, possono implementare i meccanismi di sicurezza e di controllo degli accessi più evoluti che la specifica documenta: l’autorizzazione OAuth con la scoperta del servizio di autorizzazione, il consenso accordato per gradi (l’agente riceve gli ambiti man mano che servono, non tutto e subito), la registrazione standard dei client, e gli obblighi delle buone pratiche - ogni richiesta in ingresso verificata, sessioni sicure mai usate come autenticazione. Per questo, in azienda, la forma da preferire è l’HTTP: non a caso il server MCP di Dataverse - la piattaforma dati di Microsoft, che incontreremo nei casi d’uso - è un indirizzo web dell’organizzazione, e i server dei produttori sono in questa forma. Per trovarli esiste dal settembre 2025 un registro ufficiale, un catalogo aperto dei server disponibili pubblicamente.

Un equivoco da sciogliere subito: MCP non sostituisce le API - le avvolge. Per chi le pubblica, fra un’API REST tradizionale - lo stile con cui il web espone le interfacce - e la stessa API esposta come strumenti MCP cambiano tre cose:

• il destinatario: la REST è scritta per programmatori, che leggono la documentazione e scrivono codice per integrarla; lo strumento MCP è scritto per i modelli - schemi tipizzati e descrizioni in linguaggio naturale che un LLM capisce da solo, senza che nessuno scriva codice;
• dove viaggia la documentazione: per la REST sta su un portale, da leggere prima; con MCP arriva dentro il protocollo, al momento del collegamento, con la scoperta degli strumenti;
• il contratto: ogni REST ha le sue convenzioni - autenticazione, paginazione, errori, diverse per ogni fornitore, e da lì nascevano gli adattatori - mentre un client che parla MCP usa ogni server allo stesso modo.

Sotto, però, resta l’API: un server MCP è quasi sempre la traduzione di API esistenti in strumenti dichiarati (il gateway della SAP Integration Suite si costruisce proprio a partire da un’API), l’autorizzazione e la logica vengono da lì, e per questo la qualità delle API sottostanti resta decisiva.

Il protocollo ha anche un limite strutturale che chi adotta deve conoscere: l’agente riceve da un server tutti gli strumenti dichiarati, in blocco e non a richiesta. Le dichiarazioni entrano nel contesto dell’agente prima che il lavoro cominci, e basta un server che espone molti strumenti - o dieci server accesi insieme - per intasarlo: ogni descrizione occupa token - le unità di testo che il fornitore conta e fattura - e i token si pagano due volte, in denaro e in prestazioni, come il pezzo di questa serie sui costi ha già contato. E poiché l’harness reinvia tutto il contesto a ogni chiamata, un catalogo gonfio si paga ogni volta, per intero; il riuso del contesto, raccontato nello stesso pezzo, ne attenua il prezzo - il fornitore conserva per qualche tempo il lavoro già fatto sul prefisso identico della richiesta e lo rifattura a tariffa ridotta - ma il costo di fondo resta. La regola pratica è esporre poco e bene - pochi strumenti per server, descrizioni asciutte - e, dal lato di chi adotta, accendere pochi server scelti invece di tutto il catalogo. Qualche produttore aggira il limite: gli strumenti Action del server di Microsoft per Dynamics 365 fanno cercare all’agente l’azione che gli serve, invece di dichiarargliele tutte in partenza.

A2A: come gli agenti si parlano fra loro

Il protocollo per far collaborare agenti di produttori diversi: nato in Google, donato alla Linux Foundation.

Il secondo protocollo risponde a una domanda diversa: non come un agente usa gli strumenti, ma come due agenti - magari di produttori diversi, in aziende diverse - si passano un compito. È l’Agent2Agent (A2A), annunciato da Google il 9 aprile 2025 con il sostegno dichiarato di oltre cinquanta partner tecnologici - da Salesforce a SAP, da ServiceNow a Workday - e poi donato alla Linux Foundation: oggi lo mantiene un comitato tecnico con rappresentanti di AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP e ServiceNow, e la specifica è arrivata alla versione 1.0. Il protocollo definisce come un agente si presenta (le capacità che dichiara), come riceve e segue un compito nel tempo, e come lo scambio resta sicuro anche fra organizzazioni.

La maturità dei due, però, non è la stessa. A2A vive oggi nelle piattaforme con cui si costruiscono gli agenti: l’Agent Development Kit di Google lo integra nella propria libreria, e Microsoft Foundry permette di collegare un agente a un altro su un indirizzo A2A. Gli harness d’uso quotidiano, invece, parlano MCP e non dichiarano di parlare anche A2A nella loro documentazione: la verifica è registrata fra le fonti. È la differenza fra uno standard adottato e uno standard designato - per A2A il governo e la specifica ci sono, la diffusione capillare deve ancora venire. Il cantiere però è vivo: su GitHub il progetto pubblica in sei linguaggi gli SDK ufficiali, cioè le librerie con cui si programma, e un deposito di esempi con decine di agenti dimostrativi costruiti coi framework più diffusi - ADK, LangGraph, CrewAI, Semantic Kernel - ma restano esercizi da laboratorio. E la misura viene dal protocollo stesso: la pagina della sua comunità presenta i casi d’uso come «esempi di ciò che è possibile», non come casi già avvenuti, e una ricerca di casi di produzione documentati con nome e cognome, alla data di questa pubblicazione, non ne trova. La verifica è in fondo, fra le fonti, con l’impegno ad aggiornarla appena il primo caso vero arriverà.

Il colloquio A2A: la carta, i compiti, le tre andature

Come due agenti si trovano e si parlano davvero: la scoperta con la carta, il vocabolario del dialogo e le andature.

Tutto comincia con la scoperta reciproca. Ogni agente pubblica la sua carta dell’agente - il «biglietto da visita digitale»: identità, capacità, indirizzo del servizio e requisiti di autenticazione - e la documentazione prevede tre vie per trovarla:

• l’indirizzo convenzionale: la carta sta in un percorso fisso del dominio (/.well-known/agent-card.json, secondo una convenzione che il web usa già per altri servizi), così ogni client sa dove cercare. Questa via standardizza il dove, non il chi: il client deve già sapere che quel dominio ospita un agente, perché un meccanismo con cui un agente esplora la rete e trova gli altri da solo non esiste, e la comunità dichiara di stare ancora esplorando protocolli di scoperta più avanzati;
• i registri curati, i cataloghi interrogabili per capacità da cui un’azienda sceglie gli agenti ammessi; anche qui la specifica non prescrive un’API standard per i registri, e ogni registro ha la sua;
• la configurazione diretta - file di configurazione, indirizzi fissati a mano - che la specifica considera legittima per i rapporti già stabiliti.

La carta va servita e verificata in sicurezza, perché è ciò su cui l’altro agente fonderà la fiducia.

Le carte, poi, non si riscaricano a ogni scambio. Cambiano di rado - quando l’agente acquista una capacità o cambiano i requisiti di accesso - e la specifica raccomanda la cache normale del web: alla scadenza il client chiede soltanto «è cambiata rispetto a quella che ho?» invece di riscaricarla, e per le carte estese - quelle che dietro autenticazione mostrano i dettagli riservati - la memoria dura quanto la sessione.

Il colloquio corre su fondamenta che ogni azienda già possiede. La specifica 1.0 definisce tre trasporti - JSON-RPC su HTTP, il modo più comune di chiamare funzioni remote scambiando messaggi in formato JSON; gRPC; e la REST con JSON - e la carta dichiara quelli che l’agente sa parlare, in ordine di preferenza: il client sceglie il primo che conosce anche lui. L’autenticazione segue le pratiche standard del web: i requisiti dichiarati nella carta, le credenziali (OAuth, chiavi) nelle intestazioni.

Il vocabolario del dialogo ha tre parole:

• i messaggi, composti di parti che possono essere testo, file o dati strutturati;
• i compiti, che hanno una vita: stati intermedi in cui il lavoro avanza o chiede per strada un dato mancante (lo stato input-required) o un’autenticazione, e stati finali - completato, annullato, rifiutato, fallito. Un identificatore di contesto lega i compiti di una stessa conversazione, e a quello l’agente remoto può agganciare la propria memoria interna fra un’interazione e l’altra;
• gli artefatti, i risultati formali che il lavoro produce.

E il dialogo ha tre andature:

• la richiesta e risposta semplice, per le cose brevi;
• lo streaming con eventi dal server, per seguire in diretta un lavoro che avanza;
• le notifiche push verso un indirizzo di richiamo, per i compiti lunghi in cui i due agenti si disconnettono e si ritrovano - con le avvertenze di sicurezza che la documentazione dedica proprio a questo caso.

La differenza con MCP tocca anche il contesto del modello: dove un server MCP generoso riversa nel contesto decine di dichiarazioni, la carta è un documento compatto, e quanto ne arrivi al modello lo decide la piattaforma che orchestra - il protocollo governa il filo, non il contesto. L’orchestratore d’esempio pubblicato dal progetto lo mostra in pratica: legge gli indirizzi degli agenti remoti dalla configurazione, scarica le carte una volta all’avvio e le tiene in memoria, e al modello presenta soltanto un elenco compatto - nome e descrizione di ogni agente - più uno strumento per scrivergli.

MCP e A2A: due mestieri che si completano

MCP collega l’agente ai suoi strumenti, A2A lo collega agli altri agenti: la documentazione stessa li dichiara complementari.

I due protocolli non sono concorrenti, e lo dice la documentazione stessa di A2A, che tratta in una sezione il rapporto con MCP: MCP collega un agente ai suoi strumenti, A2A collega un agente agli altri agenti. Un’azienda avveduta li userà entrambi, come oggi usa insieme HTTP e la posta elettronica: mestieri diversi, con una zona di confine - un agente si può esporre anche come strumento MCP, e per ora gli harness lo raggiungono da lì - ma per il dialogo alla pari, fra organizzazioni, il disegno è quello di A2A.

Che cosa ci si fa: quattro casi concreti

Due casi per MCP, già quotidiani, e due per A2A, dove i cantieri sono aperti.

Con MCP, il caso più quotidiano è l’assistente che risponde sui dati del gestionale, e sta tutto dentro il perimetro degli strumenti che le pagine ufficiali documentano per nome. Il server MCP di Dataverse dichiara fra i suoi quindici strumenti la ricerca sui dati e un’interrogazione SQL in sola lettura: «quanto abbiamo venduto a questo cliente nel trimestre?» passa esattamente da lì. Il server di Microsoft per l’ERP dichiara gli strumenti Data per creare, leggere e aggiornare i record attraverso le entità: «prepara l’ordine per questo cliente» è una creazione su un’entità, con la revisione umana prima della conferma. Il secondo caso è l’azienda che espone le proprie API come strumenti: con un gateway come quello della SAP Integration Suite, un servizio interno già esistente - il listino, il calcolo delle provvigioni - diventa uno strumento MCP, e da quel momento ogni assistente compatibile lo usa senza che nessuno scriva un adattatore.

Con A2A i casi vivono dove vive il protocollo, nelle piattaforme. Il primo è il compito che attraversa due piattaforme: un agente costruito con l’ADK di Google delega un passo a un agente specialista che gira su Microsoft Foundry, perché entrambi espongono e capiscono lo stesso protocollo - le due documentazioni descrivono proprio questo scenario. Il secondo, più ambizioso, è il dialogo fra organizzazioni: l’agente degli acquisti di un’azienda interroga l’agente del fornitore sullo stato di una consegna, con l’autenticazione e la sicurezza che la specifica prevede per gli scambi fra organizzazioni diverse. Oggi è il caso d’uso che la specifica disegna e i primi cantieri esplorano, non ancora la pratica diffusa: la distinzione fra adottato e designato vale anche qui.

La prova del loro successo: anche i gestionali iniziano a usarli

Quando uno standard arriva nel software più conservativo che esista, la fase emergente è finita.

Il segnale più forte che la fase emergente è finita non viene dai laboratori: viene dagli ERP, i gestionali d’impresa, il software più conservativo che esista. Microsoft espone per Dynamics 365 due server MCP ufficiali che danno agli agenti i dati, le pagine e le azioni del sistema; SAP documenta nella propria Integration Suite il server MCP come componente a pieno titolo, costruito esponendo come strumenti le API del cliente; Oracle ha messo nel proprio studio per agenti un client MCP verso server esterni e un capitolo dedicato ad A2A. Chi volesse la storia completa, con le versioni minime e i costi d’accesso, la trova nell’articolo della serie gemella sugli ERP dedicato a dove personalizzare un gestionale: qui basta il fatto - quando i fornitori più prudenti del mercato espongono un protocollo nei loro prodotti, quel protocollo ha smesso di essere una scommessa. Anche qui, però, il divario si ripete: MCP i gestionali lo espongono già; A2A, per ora, lo documentano - il capitolo di Oracle è una promessa messa a catalogo, coerente con lo standard designato.

La parte difficile: fidarsi

Dare strumenti a un agente è dare potere a un programma: servono permessi minimi, una persona sulle azioni che scrivono e diffidenza verso il testo; l’opacità reciproca protegge chi dialoga.

Una lingua comune moltiplica le connessioni, e ogni connessione è una fiducia concessa. La specifica MCP riserva al tema un documento di buone pratiche di sicurezza che non nasconde i rischi: descrive l’attacco del «delegato confuso» (un server intermedio indotto a usare le proprie credenziali per conto del client sbagliato, fino a ottenere autorizzazioni senza il vero consenso dell’utente) e il dirottamento di sessione, con obblighi precisi per chi implementa - verificare ogni richiesta in ingresso, non usare mai la sessione come autenticazione. Per chi adotta, le regole pratiche vengono da concetti che questa serie ha già introdotto: i permessi minimi (l’agente vede solo gli strumenti che il compito richiede, e un elenco approvato decide quali server sono ammessi), l’essere umano nel ciclo sulle azioni che scrivono, e la diffidenza verso il testo: le descrizioni degli strumenti entrano nel contesto del modello come qualunque altro testo, e sono quindi una via possibile per l’iniezione di istruzioni - il motivo per cui un server MCP si adotta da fonti fidate, come si fa con le librerie di codice.

L’essere umano nel ciclo, in particolare, è passato dalla buona pratica dell’harness al protocollo. La specifica prevede la richiesta all’utente (l’elicitation del protocollo): un server può chiedere all’utente, attraverso il client, un dato mancante o una conferma a metà operazione - e la revisione di novembre 2025 l’ha potenziata, con le scelte guidate a opzione singola o multipla e la conferma attraverso una pagina web. Le piattaforme aggiungono il resto: la documentazione OpenAI prevede politiche di approvazione sulle chiamate agli strumenti MCP, e lo studio per agenti di Oracle mette su ogni strumento la spunta «richiedi approvazione umana». La regola, a quel punto, si scrive da sola: gli strumenti che modificano l’applicazione che li espone - creare un cliente nuovo, cambiare l’IBAN di un fornitore - si pubblicano con l’approvazione obbligatoria, e prima che l’azione parta una persona la rivede e la firma. Anche A2A ha la sua superficie da proteggere, a cominciare dalla carta dell’agente.

Il colloquio fra agenti, in compenso, porta con sé una garanzia che vale quanto tutti gli obblighi: i due agenti sono opachi l’uno per l’altro. La documentazione lo dice apertamente: dal punto di vista del richiedente, l’agente remoto è una scatola nera - i suoi meccanismi interni, la sua memoria e i suoi strumenti non sono esposti. Sul filo viaggiano solo i messaggi, i compiti e gli artefatti: ogni agente si tiene il proprio contesto, e dell’altro vede soltanto ciò che l’altro decide di mandargli. È la risposta pronta per chi, in azienda, chiederà che fine fanno i dati interni quando due organizzazioni mettono i loro agenti a parlarsi. Tutto questo dice una cosa sola: i protocolli sono diventati infrastruttura, e l’infrastruttura si governa.

La domanda da capitolato

«Che protocolli parla?» è diventata una domanda da fare prima di comprare, e le risposte si verificano sui documenti.

La conseguenza pratica riguarda anche, e forse soprattutto, chi compra software. Se gli standard esistono, la qualità con cui un prodotto li espone diventa un criterio di scelta: c’è un server MCP ufficiale, o solo un annuncio? Gli strumenti dichiarati coprono i dati e le azioni che servono, o una vetrina? Da quale versione, con quali costi, con quale impegno nel tempo? Sono le stesse domande che la serie sugli ERP ha messo in capitolato per le personalizzazioni, e valgono identiche qui: i protocolli sono interfacce, e le interfacce hanno versioni - si scelgono documentate e stabili nel tempo, e si sorvegliano come il calendario degli aggiornamenti. La lingua comune è arrivata; il mestiere, adesso, è parlarla per contratto.

I concetti che questo articolo introduce

Quattro voci nuove - A2A, la carta dell’agente, lo standard designato e la richiesta all’utente - tutte agganciate al Model Context Protocol.

---

Fonti

• Model Context Protocol, sito ufficiale, aperto e consultato - la definizione (standard open source per connettere le applicazioni AI a dati, strumenti e flussi), il paragone con la presa USB-C, e l’ecosistema dichiarato: Claude, ChatGPT, Visual Studio Code, Cursor.
• Anthropic, Introducing the Model Context Protocol, 25 novembre 2024, annuncio ufficiale, aperto e consultato - la nascita del protocollo come standard aperto.
• Model Context Protocol Blog, The 2026 MCP Roadmap, 9 marzo 2026, dei manutentori del progetto, aperto e consultato - la specifica di novembre 2025, i gruppi di lavoro, il processo formale delle proposte e le priorità dettate dall’esperienza di produzione.
• OpenAI, Model context protocol (MCP) nella documentazione dell’Agents SDK, aperta e consultata - il supporto di MCP nella piattaforma per agenti di OpenAI, con la citazione della definizione ufficiale.
• Model Context Protocol, documentazione ufficiale, aperta e consultata: Understanding MCP servers - ciò che un server offre (strumenti con ingressi e uscite tipizzati, risorse come contesto, richieste pronte richiamate dall’utente) - e Architecture overview - host, client e server, il trasporto locale e quello remoto via web che serve molti client.
• Model Context Protocol, Security Best Practices, parte della specifica, aperta e consultata - l’attacco del delegato confuso, il dirottamento di sessione e gli obblighi di mitigazione (verifica di ogni richiesta in ingresso, la sessione mai usata come autenticazione).
• Model Context Protocol, Key Changes della specifica del 25 novembre 2025, aperta e consultata - la quarta revisione del protocollo: le modifiche maggiori all’autorizzazione (scoperta del servizio, consenso incrementale, registrazione standard dei client), il potenziamento dell’elicitation (scelte guidate e conferma via pagina web), il sostegno sperimentale ai compiti di lunga durata e l’aggiornamento delle buone pratiche di sicurezza.
• Model Context Protocol Blog, Introducing the MCP Registry, 8 settembre 2025, dei manutentori, aperto e consultato - il registro ufficiale come catalogo aperto dei server pubblici, con l’istanza attiva.
• A2A Protocol, documentazione ufficiale, aperta e consultata: Agent Discovery - la carta dell’agente come biglietto da visita digitale, le tre vie di pubblicazione (con l’ammissione che l’API dei registri non è standardizzata e che la scoperta avanzata è terreno futuro), la cache delle carte con le regole normali del web e la sezione sulla protezione; Life of a Task - gli stati intermedi e finali di un compito e l’identificatore di contesto; Core Concepts - HTTP con JSON-RPC come formato, l’autenticazione dichiarata nella carta, messaggi, parti e artefatti, e l’agente remoto descritto come sistema opaco che non espone meccanismi interni, memoria né strumenti; e Streaming & Asynchronous Operations - lo streaming con eventi dal server e le notifiche push per gli scenari disconnessi, con le relative avvertenze di sicurezza.
• A2A Protocol, sito ufficiale, aperto e consultato - la donazione alla Linux Foundation, il comitato tecnico (AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, ServiceNow), la specifica 1.0 e la sezione sul rapporto fra A2A e MCP.
• A2A Project su GitHub, deposito principale e a2a-samples, aperti e consultati - il testo della specifica 1.0 (i tre trasporti JSON-RPC, gRPC e REST; la sezione 8.6 sulla cache delle carte; le regole sull’identificatore di contesto), gli SDK ufficiali in sei linguaggi e gli agenti d’esempio; letto il codice dell’orchestratore hosts/multiagent, che scarica le carte all’avvio, le tiene in memoria e presenta al modello un elenco compatto degli agenti con uno strumento per scrivergli.
• Google Developers Blog, Announcing the Agent2Agent Protocol (A2A), 9 aprile 2025, annuncio ufficiale, aperto e consultato - il lancio con oltre cinquanta partner tecnologici e di servizi.
• Per i server MCP dei produttori di ERP: le pagine ufficiali di Microsoft (e del server MCP di Dataverse, con la tabella dei quindici strumenti citata nei casi d’uso), SAP e Oracle, tutte aperte e consultate; il quadro completo, con versioni e costi, è nell’articolo sugli ERP della serie gemella.
• Google, ADK with Agent2Agent (A2A) Protocol, documentazione ufficiale dell’Agent Development Kit, aperta e consultata - il protocollo integrato negli strumenti della piattaforma. Microsoft, Connect to an A2A agent endpoint from Foundry Agent Service, documentazione ufficiale, aperta e consultata - il collegamento fra agenti su endpoint A2A.
• A2A Protocol, pagina della comunità, aperta e consultata - i casi d’uso presentati come «esempi di ciò che è possibile», gli SDK della comunità e le integrazioni.
• Due assenze cercate senza esito il 14 agosto 2026, entrambe da aggiornare se il quadro cambierà: il supporto A2A nella documentazione ufficiale degli harness d’uso quotidiano, come Claude Code e Codex CLI (le guide trovate raggiungono A2A passando da MCP, il che conferma quale delle due lingue parlino quegli strumenti); e casi di produzione A2A documentati con nome da una fonte primaria - circolano conteggi di terze parti sulle organizzazioni che sostengono il protocollo, ma sostenere non è usare, e un caso reale e verificabile non è ancora stato trovato.
• Il costo degli adattatori scritti su misura prima degli standard viene dall’esperienza diretta di chi scrive, e come tale va letto.