MCP e A2A

In breve

MCP e A2A separano due relazioni che in un sistema agentico vengono spesso confuse. Con MCP un’applicazione usa una capacità: legge una risorsa, invoca un tool o applica un prompt esposto da un server. Con A2A un partecipante collabora con un agente: ne scopre le capacità, gli affida un task, mantiene una conversazione e riceve aggiornamenti o artefatti. I protocolli sono complementari; il criterio di scelta è la natura dell’interlocutore, non il fatto che dietro ci sia o meno un modello (A2A and MCP: Detailed Comparison).

La distinzione operativa

Dimensione	MCP	A2A
Interlocutore	Server che espone capacità delimitate	Agente autonomo, spesso opaco
Unità di lavoro	Invocazione o lettura con schema	Task, messaggi e artefatti
Forma tipica	Input e output strutturati	Conversazione e avanzamento anche multi-turn
Stato	Il core 2026-07-28 è stateless; lo stato vive fuori o in estensioni	Il lavoro può mantenere contesto applicativo nel tempo
Scoperta	Primitive e schemi del server	Capacità dichiarate dall’agente
Esito parziale	Risultato o errore della capacità	Stato del task, aggiornamenti, richieste di chiarimento, artefatti
Confine di fiducia	Host, client e server applicano policy proprie	Ogni peer deve autenticare e autorizzare l’altro

Una capacità agentica stretta e stateless può essere esposta come tool MCP. Questo non converte automaticamente l’intero agente in una funzione.

Un caso concreto: diagnosi e ricambio

Il confronto ufficiale usa un’officina. Ridotto ai passaggi che contano:

1. Un coordinatore riceve un problema non ancora diagnosticato.
2. Via A2A affida il task a un agente meccanico e ne riceve stato e artefatti.
3. Il meccanico usa MCP per interrogare uno scanner e consultare il manuale.
4. Se serve un ricambio, collabora via A2A con l’agente del fornitore.

Cliente
  └─ A2A → coordinatore
       └─ A2A → agente specialista
            ├─ MCP → scanner diagnostico
            ├─ MCP → manuale tecnico
            └─ A2A → agente fornitore

Due errori di modellazione

Un agente compresso in un tool

Supponiamo di esporre resolve_incident come tool MCP e di aspettarsi che completi un’indagine lunga, chieda chiarimenti, coordini specialisti e produca più artefatti. Lo schema può descrivere l’input iniziale, ma nasconde il vero contratto: stato del task, progressi, responsabilità e possibili richieste al chiamante. Se quelle proprietà sono essenziali, il problema è una collaborazione A2A, anche se l’agente usa internamente molti tool MCP.

Un tool promosso ad agente

Al contrario, modellare una conversione di valuta o una query deterministica come peer A2A introduce discovery, task e conversazione dove bastano input e output strutturati. L’autonomia dichiarata non aggiunge capacità; rende più costosi timeout, errori e test.

La domanda discriminante è: il chiamante vuole un risultato delimitato o sta affidando un obiettivo?

Dallo strumento al sistema

Quattro livelli separano le responsabilità:

Livello	Proprietario del contratto	Responsabilità
Tool di vendor	Fornitore	Funzione concreta e API originaria
Connettore	Integratore	Capacità stabile, adattamento e limiti dichiarati
MCP	Host e server	Scoperta e invocazione standardizzata della capacità
A2A	Agenti partecipanti	Delega, collaborazione e scambio di artefatti

Il connettore evita che un cambio di vendor si propaghi fino all’agente; MCP rende quella capacità accessibile con un contratto dichiarato; A2A coordina chi decide quando e perché usarla. Non tutti i sistemi necessitano di tutti i livelli. Se esiste un solo tool locale, aggiungere un agente remoto e un protocollo di collaborazione non crea valore.

Questo modello si collega all’architettura a tre piani: governo, orchestrazione ed esecuzione devono restare distinguibili anche quando i protocolli attraversano più processi.

Fallimenti da non confondere

Fallimento	Chi deve renderlo visibile
Input MCP non conforme allo schema	Client/server della capacità
Tool rifiutato per autorizzazione	Servizio che possiede l’operazione
Agente A2A non accetta il task	Peer che riceve la delega
Task fermo in attesa di chiarimento	Protocollo e orchestratore del task
Risultato parziale non sufficiente	Agente responsabile dell’obiettivo
Tool disponibile ma inadatto al caso	Agente o host che seleziona la capacità

Un errore MCP non dovrebbe diventare “l’agente non collabora”; un task A2A incompleto non dovrebbe apparire come una chiamata tool riuscita.

Il confine da mantenere

MCP e A2A si compongono bene quando il confine coincide con la responsabilità: A2A affida lavoro, MCP concede capacità. La composizione non trasferisce automaticamente fiducia. L’agente delegato resta responsabile del task; il server MCP resta responsabile di autorizzazione, validazione ed effetti della propria operazione; l’orchestratore deve conservare la provenienza degli artefatti.

Limiti

Prodotti e gateway possono tradurre tra protocolli. Un adattatore dimostra compatibilità tecnica, non equivalenza semantica. Versioni, binding ed estensioni vanno verificati prima di assumere interoperabilità.

Voci correlate

• Model Context Protocol
• Architettura a tre piani
• Protocollo di delega dei worker

Fonti

• A2A Protocol, documentazione pubblica ufficiale.
• A2A and MCP: Detailed Comparison, confronto ufficiale tra i domini.
• A2A development specification, fonte primaria corrente alla revisione del 2026-09-02; usare una release versionata per decisioni implementative.
• MCP Architecture, specification 2026-07-28, ruoli e dominio MCP.