MCP vs A2A vs ANP: AI-agentprotocollen uitgelegd

Wat zijn AI-agentprotocollen en waarom zijn ze belangrijk?

AI-agentprotocollen zijn open standaarden die bepalen hoe agents verbinding maken met tools, met elkaar communiceren en peers op het netwerk vinden. Zonder deze protocollen is elke integratie een op maat geschreven API-wrapper. Met deze protocollen kun je het model of de tool vervangen en blijft alles werken.

Drie protocollen zijn relevant voor ontwikkelaars die agentsystemen bouwen: MCP (Model Context Protocol), A2A (Agent-to-Agent Protocol) en ANP (Agent Network Protocol). Ze zijn geen concurrenten. Het zijn lagen in een stack.

MCP verbindt agents met tools en data. A2A laat agents taken delegeren aan andere agents. ANP regelt ontdekking over netwerken heen. Als je agents op een VPS host, voorkomt kennis van de positie van elk protocol dat je eenvoudige opstellingen te complex maakt of complexe opstellingen te simpel houdt.

Dit artikel levert het mentale model. Geen code. Alleen de kaart die je nodig hebt voordat je begint te bouwen.

Wat is MCP (Model Context Protocol)?

MCP is een open standaard, oorspronkelijk gemaakt door Anthropic, die definieert hoe AI-agents verbinding maken met externe tools en databronnen. MCP-servers stellen mogelijkheden beschikbaar aan MCP-clients die zijn ingebed in AI-applicaties. Zie het als een USB-poort voor AI: één uniforme interface tussen elke agent en elke tool. Anthropic heeft MCP in december 2025 overgedragen aan de Agentic AI Foundation (AAIF) onder de Linux Foundation.

Vóór MCP betekende het koppelen van een AI-model aan een database het schrijven van een op maat gemaakte integratie. Koppelen aan een tweede database vereiste weer een nieuwe integratie. MCP vervangt dat patroon met een universeel protocol. Bouw één MCP-server voor je database en elke MCP-compatibele agent kan deze gebruiken.

Hoe werkt MCP?

MCP definieert drie rollen:

Host: De AI-applicatie (Claude Desktop, Cursor, je eigen app). Beheert één of meer MCP-clients.
Client: Een connector binnen de host die een 1:1-verbinding onderhoudt met een MCP-server.
Server: Een lichtgewicht dienst die tools, resources en prompts beschikbaar stelt aan clients.

Communicatie gebruikt JSON-RPC 2.0 over een van twee transporttypen:

stdio: Standaard input/output. Geschikt voor lokale servers op dezelfde machine. De host start de server als kindproces.
Streamable HTTP: HTTP-gebaseerd transport waarmee MCP-servers als remote diensten draaien. De client stuurt JSON-RPC-verzoeken via HTTP POST. De server kan antwoorden streamen. Dit maakt het mogelijk MCP-servers op een VPS te draaien en er op afstand mee te verbinden.

Het oudere SSE-transport (Server-Sent Events) werkt nog, maar wordt vervangen door Streamable HTTP, dat stateless operatie en horizontale schaalbaarheid zonder sticky sessions ondersteunt.

MCP-servers stellen drie typen primitieven beschikbaar:

Primitieve	Functie	Besturing
Tools	Functies die het AI-model kan aanroepen (database bevragen, e-mail versturen, script uitvoeren)	Modelgestuurd (het LLM beslist wanneer aan te roepen)
Resources	Data die de agent kan lezen (bestanden, records, API-antwoorden)	Applicatiegestuurd (de host beslist wat beschikbaar te stellen)
Prompts	Sjabloonberichten en workflows	Gebruikergestuurd (de gebruiker kiest uit beschikbare prompts)

Verbindingen zijn stateful. Client en server onderhandelen mogelijkheden tijdens initialisatie en wisselen vervolgens berichten uit over een persistente verbinding. Servers kunnen ook sampling (het LLM vragen tekst te genereren) en elicitation (de gebruiker om input vragen) aanvragen, wat recursief agentisch gedrag mogelijk maakt.

Hoe ziet het MCP-ecosysteem eruit in 2026?

MCP is in 2026 het standaard integratieprotocol voor AI-tooling:

97M+ maandelijkse SDK-downloads voor Python en TypeScript
10.000+ publieke MCP-servers in productie
Geadopteerd door alle grote AI-platforms: Claude, ChatGPT, Gemini, Copilot, Cursor, VS Code
Beheerd door de AAIF onder de Linux Foundation, medeopgericht door Anthropic, OpenAI en Block
Huidige specificatieversie: 2025-11-25

De roadmap voor 2026 richt zich op het productierijp maken van Streamable HTTP op schaal: stateless verwerking van verzoeken, vereenvoudigde horizontale schaalbaarheid en een standaardmethode voor registries om servermogelijkheden te ontdekken zonder verbinding te maken.

Wat is A2A (Agent-to-Agent Protocol)?

A2A (Agent-to-Agent Protocol) is een open protocol, oorspronkelijk gemaakt door Google, dat standaardiseert hoe AI-agents communiceren en samenwerken. Eén agent stuurt een taak naar een andere via JSON-RPC over HTTP. De ontvangende agent publiceert een Agent Card met zijn mogelijkheden, authenticatievereisten en endpoint-URL. A2A beheert de taaklevenscyclus, resultaatstreaming en pushnotificaties voor langlopende operaties.

MCP verbindt een agent met tools. A2A verbindt een agent met andere agents. MCP-servers zijn transparant: je ziet precies wat ze doen. A2A-agents zijn ondoorzichtig. De aanroepende agent weet niet en hoeft niet te weten welk model, framework of logica in de remote agent draait. Hij stuurt een taak en krijgt resultaten terug.

Hoe werkt A2A?

A2A definieert drie actoren:

User: De mens of geautomatiseerde dienst die werk aanvraagt.
A2A Client: De applicatie die taken verstuurt namens de gebruiker.
A2A Server: Een remote agent die een HTTP-endpoint beschikbaar stelt. Werkt als een black box.

Agent Cards zijn het ontdekkingsmechanisme. Elke A2A-server publiceert een JSON-document (meestal op /.well-known/agent-card.json) dat beschrijft:

Agentidentiteit (naam, beschrijving, aanbieder)
Service-endpoint-URL
Ondersteunde mogelijkheden (streaming, pushnotificaties)
Beschikbare skills met beschrijvingen
Authenticatievereisten
Optionele digitale handtekening ter verificatie

Een Task (taak) is de werkeenheid. Elke taak heeft een uniek ID en doorloopt een levenscyclus:

submitted → working → completed
                   → failed
                   → canceled
                   → rejected
           → input-required (multi-turn: agent heeft meer informatie nodig van de client)

Berichten bevatten Parts: tekst, bestandsreferenties of gestructureerde JSON-data. Taakresultaten heten Artifacts, die ook Parts bevatten. Een agent kan een codebestand, een samenvatting en een JSON-rapport retourneren in één antwoord.

A2A ondersteunt drie communicatiepatronen:

Request/Response: Client stuurt een taak, pollt status met GetTask.
Streaming (SSE): Incrementele realtime-updates over persistente HTTP-verbindingen. De client roept SendStreamingMessage aan en ontvangt events terwijl de agent werkt.
Push Notifications (Webhooks): Voor langlopende taken stuurt de agent statusupdates via POST naar een door de client geregistreerde webhook-URL.

Alle communicatie gebruikt JSON-RPC 2.0 over HTTPS. Versie 0.3 voegde gRPC-ondersteuning en ondertekende Agent Cards toe. De huidige versie is A2A v1.0.0.

Hoe zijn A2A en ACP gefuseerd?

IBM lanceerde het Agent Communication Protocol (ACP) in maart 2025 om zijn BeeAI-platform aan te drijven. Google kondigde A2A de volgende maand aan. Beide protocollen losten hetzelfde probleem op: communicatie tussen agents.

In augustus 2025 maakte de Linux Foundation bekend dat ACP zou opgaan in A2A. IBM's ACP-team onder leiding van Kate Blair trad toe tot het Technisch Stuurcomité van A2A, naast Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow en SAP. Het BeeAI-platform schakelde over van ACP naar A2A en ACP-specifieke ontwikkeling werd stopgezet.

Als je ACP apart aan het evalueren was: stop daarmee. Het antwoord is A2A.

Wat is ANP (Agent Network Protocol)?

ANP (Agent Network Protocol) is een peer-to-peerprotocol dat AI-agents in staat stelt elkaar te ontdekken en te communiceren over open netwerken zonder centrale autoriteit. Anders dan het client-servermodel van MCP en de client-server taakdelegatie van A2A, behandelt ANP elke agent als een gelijkwaardige peer. Het gebruikt W3C Decentralized Identifiers (DIDs) voor identiteit, JSON-LD voor gegevensuitwisseling en bevat een metaprotocollaag waarin agents onderhandelen over hoe ze zullen communiceren.

ANP richt zich op een ander probleem dan MCP en A2A. Die protocollen veronderstellen dat je weet welke server of agent je wilt bereiken. ANP beantwoordt de vraag: hoe vindt een agent andere agents waarmee hij nooit eerder heeft gecommuniceerd, over organisatiegrenzen heen, zonder centraal register?

Hoe verschilt ANP van A2A?

ANP heeft een architectuur met drie lagen:

Laag 1: Identiteit en versleutelde communicatie. Elke agent krijgt een W3C Decentralized Identifier met de did:wba (Web-Based Agent) methode. Elke DID verwijst naar een via HTTPS gehost DID-document, zodat identiteitsresolutie bestaande webinfrastructuur gebruikt. Twee agents kunnen elkaars identiteit verifiëren en versleutelde kanalen opzetten zonder centrale autoriteit.

Laag 2: Metaprotocol. Agents onderhandelen dynamisch over communicatieprotocollen. In plaats van dat beide agents hetzelfde vaste protocol moeten ondersteunen, wisselen ze voorgestelde vereisten uit in gestructureerde vorm, bereiken overeenstemming over een protocol en communiceren er vervolgens mee. Dit maakt ANP aanpasbaar voor scenario's die de vaste JSON-RPC-aanpak van A2A niet aankan.

Laag 3: Applicatieprotocol. Agentbeschrijvingen gebruiken JSON-LD gekoppeld aan schema.org-ontologieën. Ontdekking werkt op twee manieren:

Actieve ontdekking: Het /.well-known/agent-descriptions-endpoint van een domein bevragen.
Passieve ontdekking: Agents registreren zich bij indexeringsdiensten die beschrijvingen crawlen en catalogiseren.

Architectuurvergelijking tussen ANP en A2A:

Aspect	A2A	ANP
Topologie	Client-server	Peer-to-peer
Identiteit	Agent Cards (zelf-gepubliceerd JSON)	W3C DIDs (gedecentraliseerd, verifieerbaar)
Ontdekking	Bekende URL (`/.well-known/agent-card.json`)	Gedecentraliseerde indexering + well-known endpoints
Protocolflexibiliteit	Vast (JSON-RPC 2.0)	Metaprotocolonderhandeling
Gegevensformaat	JSON Parts (tekst, bestanden, gestructureerde data)	JSON-LD met semantische koppeling

Huidige status: ANP bevindt zich nog in de voorstel- en vroege ontwikkelfase. Er is een GitHub-repository en een whitepaper van de W3C Community Group, maar geen productie-SDK's of brede adoptie. De specificatie wordt niet beheerd door de AAIF.

Hoe verhouden MCP, A2A en ANP zich tot elkaar?

De drie protocollen vergeleken op de dimensies die ertoe doen bij het ontwerpen van een agentsysteem:

	MCP	A2A	ANP
Opgelost probleem	Agent-naar-tool verbinding	Agent-naar-agent taakdelegatie	Netwerkoverkoepelende agentontdekking en communicatie
Architectuur	Client-server (host → client → server)	Client-server (client → remote agent)	Peer-to-peer (agent ↔ agent)
Transport	stdio, Streamable HTTP	HTTPS (JSON-RPC 2.0), SSE, gRPC	HTTPS, onderhandelbaar via metaprotocol
Identiteitsmodel	Serveridentiteit impliciet (geconfigureerd door host)	Agent Cards (zelf-gepubliceerd JSON)	W3C DIDs (`did:wba`)
Gegevensformaat	JSON-RPC 2.0	JSON-RPC 2.0 met Parts (tekst, bestanden, gestructureerd)	JSON-LD (semantisch, gekoppelde data)
Ontdekking	Handmatige configuratie of registry-opvraag	`/.well-known/agent-card.json`	DID-resolutie + gedecentraliseerde indexering
Governance	AAIF / Linux Foundation	AAIF / Linux Foundation	W3C Community Group (onafhankelijk)
Specificatieversie	2025-11-25	v1.0.0	Whitepaper-stadium
Volwassenheid	Productie (97M+ maandelijkse SDK-downloads)	Productie (v1.0.0, SDK's van grote leveranciers)	Vroege ontwikkeling (geen productie-SDK's)
Gebruiksscenario	Je agent toegang geven tot databases, API's, bestanden	Je agent werk laten delegeren aan gespecialiseerde agents	Agents elkaar laten vinden op het open internet

Hoe werken deze protocollen samen?

Deze protocollen zijn geen alternatieven. Het zijn lagen. Neem een concreet voorbeeld.

Stel dat je een coding-agent draait op je VPS. Hij moet:

Bestanden lezen uit je Git-repository
De database van je project bevragen voor schema-informatie
Een aparte review-agent vragen zijn werk te controleren
Een deployment-agent vinden die wordt beheerd door het infrastructuurteam van je klant

De protocollen stapelen als volgt:

┌─────────────────────────────────────────────────────────┐
│                    Jouw VPS                              │
│                                                         │
│  ┌──────────────┐    MCP     ┌───────────────────────┐  │
│  │              │◄──────────►│ MCP Server: Git tools  │  │
│  │  Coding-     │            └───────────────────────┘  │
│  │  agent       │    MCP     ┌───────────────────────┐  │
│  │  (Host)      │◄──────────►│ MCP Server: DB schema  │  │
│  │              │            └───────────────────────┘  │
│  │              │                                       │
│  │              │    A2A     ┌───────────────────────┐  │
│  │              │───────────►│ Review Agent (A2A)     │  │
│  └──────┬───────┘            └───────────────────────┘  │
│         │                                               │
└─────────┼───────────────────────────────────────────────┘
          │
          │  ANP (ontdekking over netwerken)
          ▼
┌──────────────────────────┐
│ Deployment-agent van de   │
│ klant (ontdekt via        │
│ DID-resolutie)            │
└──────────────────────────┘

Laag 1 (MCP): De coding-agent gebruikt MCP-clients om verbinding te maken met lokale MCP-servers voor Git-operaties en databasequeries. Dit zijn toolintegraties. De agent roept functies aan en leest data.

Laag 2 (A2A): De coding-agent delegeert code review aan een aparte review-agent op dezelfde server (of een andere). Hij stuurt een taak via A2A, de review-agent werkt asynchroon en streamt resultaten terug. De coding-agent weet niet welk model of framework de review-agent gebruikt.

Laag 3 (ANP): De coding-agent moet een deployment-agent vinden waarmee hij nooit eerder heeft gecommuniceerd, beheerd door een andere organisatie. De DID-gebaseerde ontdekking van ANP lokaliseert de agent, verifieert zijn identiteit en onderhandelt een communicatieprotocol.

Voor de meeste zelfgehoste opstellingen is MCP vandaag voldoende. Voeg A2A toe wanneer je meerdere gespecialiseerde agents hebt die moeten samenwerken. ANP is nog niet bruikbaar voor productie, maar wordt relevant wanneer agentecosystemen organisatiegrenzen overschrijden.

Welk protocol moet je gebruiken?

Begin met het eenvoudigste protocol dat je probleem oplost. Voeg lagen pas toe wanneer je een beperking tegenkomt.

Beslissingsgids:

Moet je agent toegang hebben tot tools, databases of API's? Ja → Implementeer MCP. Bouw of installeer MCP-servers voor je databronnen. Dit dekt 80% van de integratiebehoeften van agents.
Heb je meerdere agents die taken aan elkaar moeten delegeren? Ja → Voeg A2A toe. Publiceer Agent Cards voor elke agent. Gebruik A2A voor taakdelegatie en resultaatstreaming. Nee → Je hebt A2A niet nodig. Als één agent API's aanroept via MCP, is dat voldoende.
Moeten je agents onbekende agents ontdekken over organisatiegrenzen heen? Ja → Evalueer ANP wanneer productie-SDK's beschikbaar zijn. Vandaag zou je dit oplossen met een handmatig register of een gedeelde A2A-agentdirectory. Nee → Sla ANP voorlopig over.

Veelvoorkomende patronen:

Opstelling	Benodigde protocollen
Enkele agent + tools (de meeste projecten)	Alleen MCP
Meerdere gespecialiseerde agents op één server	MCP + A2A
Samenwerking over organisaties	MCP + A2A + ANP (bij volwassenheid)
Agentmarktplaats / open ontdekking	A2A + ANP

Als je net begint met AI-agents op een VPS, begin met MCP. Verbind één agent met één tool. Laat het werken. Schaal daarna de architectuur naarmate je behoeften groeien.

Wat zijn de beveiligingsrisico's van elk protocol?

Elk protocol opent een ander aanvalsoppervlak. Als je agents zelf host, zijn dit de bedreigingen die ertoe doen.

Protocol	Bedreiging	Gevolg	Mitigatie
MCP	Server-Side Request Forgery (SSRF)	Een kwaadaardige prompt verleidt de agent om een MCP-tool aan te roepen die verzoeken stuurt naar interne diensten (metadata-endpoints, databases, beheerpanelen).	Draai MCP-servers in geïsoleerde netwerknamespaces. Beperk uitgaande verbindingen met firewallregels. Valideer toolinvoer aan de serverzijde.
MCP	Onbetrouwbare toolbeschrijvingen	MCP-toolannotaties (beschrijvingen, parameterschema's) komen van de server. Een gecompromitteerde server kan liegen over wat een tool doet om het LLM te manipuleren.	Verbind alleen MCP-servers die je beheert of vertrouwt. Controleer toolbeschrijvingen. De MCP-specificatie markeert toolannotaties expliciet als onbetrouwbaar.
A2A	Agentimitatie	Zonder ondertekende Agent Cards kan een aanvaller een valse Agent Card publiceren op een bekende URL en taken onderscheppen die bedoeld zijn voor een legitieme agent.	Gebruik de digitale handtekeningfunctie van A2A voor Agent Cards (toegevoegd in v0.3). Verifieer handtekeningen vóór het verzenden van taken. Pin bekende agentendpoints.
A2A	Exfiltratie van taakgegevens	Taken kunnen gevoelige gegevens bevatten (code, inloggegevens, bedrijfslogica). Als de remote agent gecompromitteerd is, lekken die gegevens.	Versleutel gevoelige taakgegevens op applicatieniveau. Gebruik wederzijds TLS tussen agents. Minimaliseer gegevens in taken.
ANP	DID-vertrouwensopbouw	De `did:wba`-methode vertrouwt op via HTTPS gehoste DID-documenten. Als een domein gecompromitteerd is, zijn alle agentidentiteiten op dat domein gecompromitteerd.	Gebruik aparte domeinen voor agentidentiteit. Monitor wijzigingen in DID-documenten. Implementeer DID-documentpinning voor bekende agents.
ANP	Misbruik van metaprotocol	De onderhandelingslaag kan worden misbruikt om een agent te verleiden een onveilig of kwaadaardig communicatieprotocol te gebruiken.	Beperk metaprotocolonderhandeling tot een whitelist van bekende protocollen. Log en audit alle protocolonderhandelingen.

Voor een volledige gids over het beveiligen van je agentserver, zie .

Waar gaat de governance naartoe?

Zowel MCP als A2A vallen onder de Agentic AI Foundation (AAIF), onderdeel van de Linux Foundation. De AAIF is in december 2025 opgericht door drie medeoprichters: Anthropic, OpenAI en Block. Google, Microsoft, AWS, Bloomberg en Cloudflare zijn toegetreden als platinumleden. Geen enkele leverancier bepaalt alleen de protocoldirectie.

De AAIF host ook goose (Block's open-source agentframework) en AGENTS.md (OpenAI's standaard om AI-agents projectspecifieke richtlijnen te geven).

ANP wordt onafhankelijk beheerd via een W3C Community Group. Het maakt geen deel uit van de AAIF. Of ANP uiteindelijk toetreedt tot de AAIF of onafhankelijk blijft, zal zijn adoptietraject beïnvloeden.

De governance-splitsing is om één praktische reden van belang: MCP en A2A zullen samen evolueren onder gecoördineerd beheer. ANP evolueert op zijn eigen tijdlijn. Als je architecturale keuzes maakt, dragen MCP en A2A een lager governance-risico.

Copyright 2026 Virtua.Cloud. Alle rechten voorbehouden. Deze inhoud is een origineel werk van het Virtua.Cloud-team. Reproductie, herpublicatie of herdistributie zonder schriftelijke toestemming is verboden.