MCP vs A2A vs ANP: protocolli agenti IA spiegati

Cosa sono i protocolli per agenti IA e perché sono importanti?

I protocolli per agenti IA sono standard aperti che definiscono come gli agenti si connettono agli strumenti, comunicano tra loro e scoprono peer nella rete. Senza di essi, ogni integrazione è un wrapper API su misura. Con essi, puoi sostituire il modello o lo strumento e tutto continua a funzionare.

Tre protocolli contano per gli sviluppatori che costruiscono sistemi di agenti: MCP (Model Context Protocol), A2A (Agent-to-Agent Protocol) e ANP (Agent Network Protocol). Non sono concorrenti. Sono livelli in uno stack.

MCP connette gli agenti a strumenti e dati. A2A permette agli agenti di delegare compiti ad altri agenti. ANP gestisce la scoperta tra reti. Se ospiti agenti su un VPS, sapere dove si colloca ogni protocollo ti evita di sovra-progettare configurazioni semplici o sotto-progettare quelle complesse.

Questo articolo è il modello mentale. Nessun codice. Solo la mappa di cui hai bisogno prima di iniziare a costruire.

Cos'è MCP (Model Context Protocol)?

MCP è uno standard aperto, creato originariamente da Anthropic, che definisce come gli agenti IA si connettono a strumenti e fonti dati esterne. I server MCP espongono capacità ai client MCP integrati nelle applicazioni IA. Immaginalo come una porta USB per l'IA: un'interfaccia unica tra qualsiasi agente e qualsiasi strumento. Anthropic ha donato MCP alla Agentic AI Foundation (AAIF) sotto la Linux Foundation nel dicembre 2025.

Prima di MCP, connettere un modello IA a un database significava scrivere un'integrazione su misura. Connetterlo a un secondo database richiedeva un'altra integrazione. MCP sostituisce questo schema con un protocollo universale. Costruisci un server MCP per il tuo database e ogni agente compatibile MCP può usarlo.

Come funziona MCP?

MCP definisce tre ruoli:

Host: L'applicazione IA (Claude Desktop, Cursor, la tua app personalizzata). Gestisce uno o più client MCP.
Client: Un connettore all'interno dell'host che mantiene una connessione 1:1 con un server MCP.
Server: Un servizio leggero che espone strumenti, risorse e prompt ai client.

La comunicazione usa JSON-RPC 2.0 su uno di due tipi di trasporto:

stdio: Input/output standard. Ideale per server locali sulla stessa macchina. L'host avvia il server come processo figlio.
Streamable HTTP: Trasporto basato su HTTP che permette ai server MCP di funzionare come servizi remoti. Il client invia richieste JSON-RPC via HTTP POST. Il server può restituire risposte in streaming. Questo rende possibile eseguire server MCP su un VPS e connettersi ad essi da remoto.

Il vecchio trasporto SSE (Server-Sent Events) funziona ancora ma viene sostituito da Streamable HTTP, che supporta operazioni stateless e scalabilità orizzontale senza sessioni persistenti.

I server MCP espongono tre tipi di primitive:

Primitiva	Funzione	Controllo
Tools	Funzioni che il modello IA può chiamare (interrogare un database, inviare un'email, eseguire uno script)	Guidato dal modello (il LLM decide quando invocare)
Resources	Dati che l'agente può leggere (file, record, risposte API)	Guidato dall'applicazione (l'host decide cosa esporre)
Prompts	Messaggi template e workflow	Guidato dall'utente (l'utente seleziona tra i prompt disponibili)

Le connessioni sono stateful. Client e server negoziano le capacità durante l'inizializzazione, poi scambiano messaggi su una connessione persistente. I server possono anche richiedere sampling (chiedere al LLM di generare testo) ed elicitation (chiedere input all'utente), abilitando comportamento agentico ricorsivo.

Com'è l'ecosistema MCP nel 2026?

MCP è il protocollo di integrazione predefinito per gli strumenti IA nel 2026:

97M+ download mensili dell'SDK per Python e TypeScript
10.000+ server MCP pubblici in produzione
Adottato da tutte le principali piattaforme IA: Claude, ChatGPT, Gemini, Copilot, Cursor, VS Code
Governato dall'AAIF sotto la Linux Foundation, co-fondata da Anthropic, OpenAI e Block
Versione attuale della specifica: 2025-11-25

La roadmap 2026 si concentra sul rendere Streamable HTTP pronto per la produzione su scala: gestione stateless delle richieste, scalabilità orizzontale semplificata e un metodo standard per i registry di scoprire le capacità dei server senza connettersi.

Cos'è A2A (Agent-to-Agent Protocol)?

A2A (Agent-to-Agent Protocol) è un protocollo aperto creato originariamente da Google che standardizza come gli agenti IA comunicano e collaborano. Un agente invia un compito a un altro usando JSON-RPC su HTTP. L'agente ricevente pubblica un'Agent Card che descrive le sue capacità, i requisiti di autenticazione e l'URL dell'endpoint. A2A gestisce il ciclo di vita dei compiti, lo streaming dei risultati e le notifiche push per operazioni di lunga durata.

MCP connette un agente agli strumenti. A2A connette un agente ad altri agenti. I server MCP sono trasparenti: vedi esattamente cosa fanno. Gli agenti A2A sono opachi. L'agente chiamante non sa e non ha bisogno di sapere quale modello, framework o logica gira nell'agente remoto. Invia un compito e riceve risultati.

Come funziona A2A?

A2A definisce tre attori:

User: L'umano o servizio automatizzato che richiede lavoro.
A2A Client: L'applicazione che invia compiti per conto dell'utente.
A2A Server: Un agente remoto che espone un endpoint HTTP. Opera come scatola nera.

Le Agent Card sono il meccanismo di scoperta. Ogni server A2A pubblica un documento JSON (tipicamente su /.well-known/agent-card.json) che descrive:

Identità dell'agente (nome, descrizione, fornitore)
URL dell'endpoint di servizio
Capacità supportate (streaming, notifiche push)
Skill disponibili con descrizioni
Requisiti di autenticazione
Firma digitale opzionale per la verifica

Un Task (compito) è l'unità di lavoro. Ogni task ha un ID unico e progredisce attraverso un ciclo di vita:

submitted → working → completed
                   → failed
                   → canceled
                   → rejected
           → input-required (multi-turno: l'agente ha bisogno di più informazioni dal client)

I messaggi contengono Parts: testo, riferimenti a file o dati JSON strutturati. I risultati dei compiti si chiamano Artifacts, che contengono anch'essi Parts. Un agente può restituire un file di codice, un riassunto testuale e un report JSON in una singola risposta.

A2A supporta tre modelli di comunicazione:

Request/Response: Il client invia un compito, interroga lo stato con GetTask.
Streaming (SSE): Aggiornamenti incrementali in tempo reale su connessioni HTTP persistenti. Il client chiama SendStreamingMessage e riceve eventi mentre l'agente lavora.
Push Notifications (Webhooks): Per compiti di lunga durata, l'agente invia aggiornamenti di stato via POST a un URL webhook registrato dal client.

Tutta la comunicazione usa JSON-RPC 2.0 su HTTPS. La versione 0.3 ha aggiunto il supporto gRPC e le Agent Card firmate. La versione attuale è A2A v1.0.0.

Come si sono fusi A2A e ACP?

IBM ha lanciato l'Agent Communication Protocol (ACP) nel marzo 2025 per alimentare la sua piattaforma BeeAI. Google ha annunciato A2A il mese successivo. Entrambi i protocolli risolvevano lo stesso problema: la comunicazione tra agenti.

Nell'agosto 2025, la Linux Foundation ha annunciato che ACP sarebbe confluito in A2A. Il team ACP di IBM, guidato da Kate Blair, è entrato nel Comitato di Direzione Tecnica di A2A insieme a Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow e SAP. La piattaforma BeeAI è passata da ACP ad A2A, e lo sviluppo specifico di ACP si è concluso.

Se stavi valutando ACP separatamente, fermati. La risposta è A2A.

Cos'è ANP (Agent Network Protocol)?

ANP (Agent Network Protocol) è un protocollo peer-to-peer che permette agli agenti IA di scoprirsi e comunicare attraverso reti aperte senza un'autorità centrale. A differenza del modello client-server di MCP e della delega di compiti client-server di A2A, ANP tratta ogni agente come un peer alla pari. Usa gli identificatori decentralizzati W3C (DIDs) per l'identità, JSON-LD per lo scambio dati e include un livello di meta-protocollo dove gli agenti negoziano come comunicheranno.

ANP affronta un problema diverso da MCP e A2A. Quei protocolli assumono che tu sappia quale server o agente vuoi contattare. ANP risponde alla domanda: come fa un agente a trovare altri agenti con cui non ha mai interagito, oltre i confini organizzativi, senza una directory centrale?

In cosa differisce ANP da A2A?

ANP ha un'architettura a tre livelli:

Livello 1: Identità e comunicazione crittografata. Ogni agente ottiene un identificatore decentralizzato W3C con il metodo did:wba (Web-Based Agent). Ogni DID corrisponde a un documento DID ospitato su HTTPS, quindi la risoluzione dell'identità usa l'infrastruttura web esistente. Due agenti possono verificare reciprocamente la propria identità e stabilire canali crittografati senza autorità centrale.

Livello 2: Meta-protocollo. Gli agenti negoziano dinamicamente i protocolli di comunicazione. Invece di dover supportare entrambi lo stesso protocollo fisso, scambiano requisiti in forma strutturata, concordano un protocollo e poi comunicano usandolo. Questo rende ANP adattabile a scenari che l'approccio JSON-RPC fisso di A2A non può gestire.

Livello 3: Protocollo applicativo. Le descrizioni degli agenti usano JSON-LD collegato alle ontologie di schema.org. La scoperta funziona in due modi:

Scoperta attiva: Interrogare l'endpoint /.well-known/agent-descriptions di un dominio.
Scoperta passiva: Gli agenti si registrano presso servizi di indicizzazione che scansionano e catalogano le descrizioni.

Confronto architetturale tra ANP e A2A:

Aspetto	A2A	ANP
Topologia	Client-server	Peer-to-peer
Identità	Agent Card (JSON auto-pubblicato)	W3C DIDs (decentralizzati, verificabili)
Scoperta	URL nota (`/.well-known/agent-card.json`)	Indicizzazione decentralizzata + endpoint well-known
Flessibilità del protocollo	Fisso (JSON-RPC 2.0)	Negoziazione meta-protocollo
Formato dati	JSON Parts (testo, file, dati strutturati)	JSON-LD con collegamento semantico

Stato attuale: ANP è ancora nella fase di proposta e sviluppo iniziale. Ha un repository GitHub e un white paper del W3C Community Group, ma nessun SDK di produzione né adozione diffusa. La specifica non è governata dall'AAIF.

Come si confrontano MCP, A2A e ANP?

I tre protocolli confrontati sulle dimensioni che contano quando si progetta un sistema di agenti:

	MCP	A2A	ANP
Problema risolto	Connessione agente-strumento	Delega di compiti agente-agente	Scoperta e comunicazione tra agenti su rete aperta
Architettura	Client-server (host → client → server)	Client-server (client → agente remoto)	Peer-to-peer (agente ↔ agente)
Trasporto	stdio, Streamable HTTP	HTTPS (JSON-RPC 2.0), SSE, gRPC	HTTPS, negoziabile via meta-protocollo
Modello di identità	Identità del server implicita (configurata dall'host)	Agent Card (JSON auto-pubblicato)	W3C DIDs (`did:wba`)
Formato dati	JSON-RPC 2.0	JSON-RPC 2.0 con Parts (testo, file, strutturato)	JSON-LD (semantico, dati collegati)
Scoperta	Configurazione manuale o consultazione registro	`/.well-known/agent-card.json`	Risoluzione DID + indicizzazione decentralizzata
Governance	AAIF / Linux Foundation	AAIF / Linux Foundation	W3C Community Group (indipendente)
Versione della spec	2025-11-25	v1.0.0	Fase white paper
Maturità	Produzione (97M+ download mensili dell'SDK)	Produzione (v1.0.0, SDK dei principali vendor)	Sviluppo iniziale (nessun SDK di produzione)
Caso d'uso	Dare al tuo agente accesso a database, API, file	Far delegare lavoro dal tuo agente ad agenti specializzati	Permettere agli agenti di trovarsi su internet aperto

Come funzionano insieme questi protocolli?

Questi protocolli non sono alternative. Sono livelli. Prendiamo un esempio concreto.

Supponiamo che tu esegua un agente di programmazione sul tuo VPS. Ha bisogno di:

Leggere file dal tuo repository Git
Interrogare il database del tuo progetto per informazioni sullo schema
Chiedere a un agente di revisione separato di controllare il suo lavoro
Trovare un agente di deploy gestito dal team infrastruttura del tuo cliente

I protocolli si sovrappongono così:

┌─────────────────────────────────────────────────────────┐
│                    Il tuo VPS                            │
│                                                         │
│  ┌──────────────┐    MCP     ┌───────────────────────┐  │
│  │              │◄──────────►│ MCP Server: Git tools  │  │
│  │  Agente di   │            └───────────────────────┘  │
│  │  program-    │    MCP     ┌───────────────────────┐  │
│  │  mazione     │◄──────────►│ MCP Server: DB schema  │  │
│  │  (Host)      │            └───────────────────────┘  │
│  │              │                                       │
│  │              │    A2A     ┌───────────────────────┐  │
│  │              │───────────►│ Review Agent (A2A)     │  │
│  └──────┬───────┘            └───────────────────────┘  │
│         │                                               │
└─────────┼───────────────────────────────────────────────┘
          │
          │  ANP (scoperta inter-rete)
          ▼
┌──────────────────────────┐
│ Agente di deploy del      │
│ cliente (scoperto via     │
│ risoluzione DID)          │
└──────────────────────────┘

Livello 1 (MCP): L'agente di programmazione usa client MCP per connettersi a server MCP locali per operazioni Git e query al database. Sono integrazioni di strumenti. L'agente chiama funzioni e legge dati.

Livello 2 (A2A): L'agente di programmazione delega la revisione del codice a un agente di revisione separato sullo stesso server (o su uno diverso). Invia un compito via A2A, l'agente di revisione lavora in modo asincrono e restituisce risultati in streaming. L'agente di programmazione non sa quale modello o framework usa l'agente di revisione.

Livello 3 (ANP): L'agente di programmazione deve trovare un agente di deploy con cui non ha mai interagito, gestito da un'organizzazione diversa. La scoperta basata su DID di ANP localizza l'agente, verifica la sua identità e negozia un protocollo di comunicazione.

Per la maggior parte delle configurazioni self-hosted oggi, MCP è sufficiente. Aggiungi A2A quando hai più agenti specializzati che devono collaborare. ANP non è ancora utile in produzione, ma conterà quando gli ecosistemi di agenti supereranno i confini organizzativi.

Quale protocollo dovresti usare?

Inizia con il protocollo più semplice che risolve il tuo problema. Aggiungi livelli solo quando raggiungi un limite.

Guida decisionale:

Il tuo agente deve accedere a strumenti, database o API? Sì → Implementa MCP. Costruisci o installa server MCP per le tue fonti dati. Questo copre l'80% delle esigenze di integrazione degli agenti.
Hai più agenti che devono delegarsi compiti a vicenda? Sì → Aggiungi A2A. Pubblica Agent Card per ogni agente. Usa A2A per la delega dei compiti e lo streaming dei risultati. No → Non hai bisogno di A2A. Se un agente chiama API tramite MCP, è sufficiente.
I tuoi agenti devono scoprire agenti sconosciuti oltre i confini organizzativi? Sì → Valuta ANP quando saranno disponibili SDK di produzione. Oggi gestiresti la cosa con un registro manuale o una directory A2A condivisa. No → Ignora ANP per ora.

Pattern comuni:

Configurazione	Protocolli necessari
Agente singolo + strumenti (la maggior parte dei progetti)	Solo MCP
Più agenti specializzati su un server	MCP + A2A
Collaborazione inter-organizzazione	MCP + A2A + ANP (a maturità)
Marketplace di agenti / scoperta aperta	A2A + ANP

Se stai iniziando con gli agenti IA su un VPS, parti con MCP. Connetti un agente a uno strumento. Fallo funzionare. Poi scala l'architettura man mano che le tue esigenze crescono.

Quali sono i rischi di sicurezza di ogni protocollo?

Ogni protocollo apre una superficie di attacco diversa. Se ospiti agenti tu stesso, queste sono le minacce che contano.

Protocollo	Minaccia	Conseguenza	Mitigazione
MCP	Server-Side Request Forgery (SSRF)	Un prompt malevolo induce l'agente a chiamare uno strumento MCP che invia richieste a servizi interni (endpoint di metadati, database, pannelli di amministrazione).	Esegui i server MCP in namespace di rete isolati. Limita le connessioni in uscita con regole firewall. Valida gli input degli strumenti lato server.
MCP	Descrizioni di strumenti non affidabili	Le annotazioni degli strumenti MCP (descrizioni, schemi dei parametri) provengono dal server. Un server compromesso può mentire su cosa fa uno strumento per manipolare il LLM.	Connetti solo server MCP che controlli o di cui ti fidi. Verifica le descrizioni. La specifica MCP segna esplicitamente le annotazioni degli strumenti come non affidabili.
A2A	Impersonificazione dell'agente	Senza Agent Card firmate, un attaccante può pubblicare un'Agent Card falsa a un URL noto e intercettare compiti destinati a un agente legittimo.	Usa la firma digitale delle Agent Card di A2A (aggiunta nella v0.3). Verifica le firme prima di inviare compiti. Fissa gli endpoint degli agenti noti.
A2A	Esfiltrazione dati dei compiti	I compiti possono contenere dati sensibili (codice, credenziali, logica di business). Se l'agente remoto è compromesso, quei dati vengono esposti.	Crittografa i dati sensibili a livello applicativo. Usa TLS mutuo tra agenti. Minimizza i dati inviati nei compiti.
ANP	Bootstrap della fiducia DID	Il metodo `did:wba` si basa su documenti DID ospitati su HTTPS. Se un dominio viene compromesso, tutte le identità degli agenti su quel dominio sono compromesse.	Usa domini separati per l'identità degli agenti. Monitora le modifiche ai documenti DID. Implementa il pinning dei documenti DID per agenti noti.
ANP	Abuso del meta-protocollo	Il livello di negoziazione potrebbe essere sfruttato per ingannare un agente e fargli usare un protocollo di comunicazione insicuro o malevolo.	Limita la negoziazione del meta-protocollo a una whitelist di protocolli noti. Registra e controlla tutte le negoziazioni di protocollo.

Per una guida completa sulla messa in sicurezza del tuo server di agenti, consulta .

Dove sta andando la governance?

Sia MCP che A2A sono sotto l'Agentic AI Foundation (AAIF), parte della Linux Foundation. L'AAIF è stata fondata nel dicembre 2025 da tre co-fondatori: Anthropic, OpenAI e Block. Google, Microsoft, AWS, Bloomberg e Cloudflare si sono uniti come membri platinum. Nessun singolo vendor controlla la direzione del protocollo.

L'AAIF ospita anche goose (il framework di agenti open source di Block) e AGENTS.md (lo standard di OpenAI per dare agli agenti IA indicazioni specifiche per progetto).

ANP è governato in modo indipendente attraverso un W3C Community Group. Non fa parte dell'AAIF. Che ANP si unisca all'AAIF o resti indipendente influenzerà la sua traiettoria di adozione.

La divisione della governance conta per una ragione pratica: MCP e A2A evolveranno insieme sotto una direzione coordinata. ANP evolverà secondo il proprio calendario. Se stai facendo scommesse architetturali, MCP e A2A comportano un rischio di governance inferiore.

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto è un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta è vietata.