MCP vs A2A vs ANP: KI-Agent-Protokolle erklärt

Was sind KI-Agent-Protokolle und warum sind sie wichtig?

KI-Agent-Protokolle sind offene Standards, die festlegen, wie Agents sich mit Tools verbinden, miteinander kommunizieren und Peers in Netzwerken finden. Ohne sie ist jede Integration ein individueller API-Wrapper. Mit ihnen können Sie das Modell oder das Tool austauschen, und alles funktioniert weiter.

Drei Protokolle sind für Entwickler relevant, die Agent-Systeme bauen: MCP (Model Context Protocol), A2A (Agent-to-Agent Protocol) und ANP (Agent Network Protocol). Sie sind keine Konkurrenten. Sie sind Schichten in einem Stack.

MCP verbindet Agents mit Tools und Daten. A2A ermöglicht Agents, Aufgaben an andere Agents zu delegieren. ANP übernimmt die netzwerkübergreifende Entdeckung. Wenn Sie Agents auf einem VPS selbst hosten, bewahrt Sie das Wissen um die Position jedes Protokolls davor, einfache Setups zu überplanen oder komplexe zu unterschätzen.

Dieser Artikel liefert das mentale Modell. Kein Code. Nur die Karte, die Sie brauchen, bevor Sie anfangen zu bauen.

Was ist MCP (Model Context Protocol)?

MCP ist ein offener Standard, ursprünglich von Anthropic entwickelt, der definiert, wie KI-Agents sich mit externen Tools und Datenquellen verbinden. MCP-Server stellen Fähigkeiten für MCP-Clients bereit, die in KI-Anwendungen eingebettet sind. Stellen Sie sich MCP wie einen USB-Port für KI vor: eine einheitliche Schnittstelle zwischen jedem Agent und jedem Tool. Anthropic hat MCP im Dezember 2025 an die Agentic AI Foundation (AAIF) unter der Linux Foundation übertragen.

Vor MCP bedeutete die Anbindung eines KI-Modells an eine Datenbank eine individuelle Integration. Die Anbindung an eine zweite Datenbank erforderte eine weitere. MCP ersetzt dieses Muster durch ein universelles Protokoll. Sie bauen einen MCP-Server für Ihre Datenbank, und jeder MCP-kompatible Agent kann ihn nutzen.

Wie funktioniert MCP?

MCP definiert drei Rollen:

Host: Die KI-Anwendung (Claude Desktop, Cursor, Ihre eigene App). Er verwaltet einen oder mehrere MCP-Clients.
Client: Ein Connector innerhalb des Hosts, der eine 1:1-Verbindung zu einem MCP-Server aufrechterhält.
Server: Ein leichtgewichtiger Dienst, der Tools, Resources und Prompts für Clients bereitstellt.

Die Kommunikation nutzt JSON-RPC 2.0 über einen von zwei Transporttypen:

stdio: Standard-Ein-/Ausgabe. Optimal für lokale Server auf derselben Maschine. Der Host startet den Server als Kindprozess.
Streamable HTTP: HTTP-basierter Transport, mit dem MCP-Server als entfernte Dienste laufen können. Der Client sendet JSON-RPC-Anfragen per HTTP POST. Der Server kann Antworten streamen. Das ermöglicht den Betrieb von MCP-Servern auf einem VPS mit Remote-Zugriff.

Der ältere SSE-Transport (Server-Sent Events) funktioniert noch, wird aber durch Streamable HTTP abgelöst. Dieses unterstützt zustandslosen Betrieb und horizontale Skalierung ohne Sticky Sessions.

MCP-Server stellen drei Typen von Primitiven bereit:

Primitive	Funktion	Steuerung
Tools	Funktionen, die das KI-Modell aufrufen kann (Datenbank abfragen, E-Mail senden, Skript ausführen)	Modellgesteuert (das LLM entscheidet, wann aufgerufen wird)
Resources	Daten, die der Agent lesen kann (Dateien, Datensätze, API-Antworten)	Anwendungsgesteuert (der Host entscheidet, was bereitgestellt wird)
Prompts	Vorlagen für Nachrichten und Workflows	Benutzergesteuert (der Benutzer wählt aus verfügbaren Prompts)

Verbindungen sind zustandsbehaftet. Client und Server verhandeln Fähigkeiten während der Initialisierung und tauschen dann Nachrichten über eine persistente Verbindung aus. Server können auch Sampling (das LLM zur Textgenerierung auffordern) und Elicitation (den Benutzer um Eingabe bitten) anfordern, was rekursives agentisches Verhalten ermöglicht.

Wie sieht das MCP-Ökosystem 2026 aus?

MCP ist 2026 das Standard-Integrationsprotokoll für KI-Tooling:

97M+ monatliche SDK-Downloads für Python und TypeScript
10.000+ öffentliche MCP-Server in Produktion
Übernommen von allen großen KI-Plattformen: Claude, ChatGPT, Gemini, Copilot, Cursor, VS Code
Verwaltet durch die AAIF unter der Linux Foundation, mitgegründet von Anthropic, OpenAI und Block
Aktuelle Spezifikationsversion: 2025-11-25

Die Roadmap für 2026 konzentriert sich darauf, Streamable HTTP produktionsreif zu skalieren: zustandslose Anfrageverarbeitung, vereinfachte horizontale Skalierung und eine Standardmethode, mit der Registries Serverfähigkeiten entdecken können, ohne sich zu verbinden.

Was ist A2A (Agent-to-Agent Protocol)?

A2A (Agent-to-Agent Protocol) ist ein offenes Protokoll, ursprünglich von Google entwickelt, das standardisiert, wie KI-Agents kommunizieren und zusammenarbeiten. Ein Agent sendet eine Aufgabe an einen anderen per JSON-RPC über HTTP. Der empfangende Agent veröffentlicht eine Agent Card mit seinen Fähigkeiten, Authentifizierungsanforderungen und Endpoint-URL. A2A verwaltet den Aufgabenlebenszyklus, das Ergebnis-Streaming und Push-Benachrichtigungen für lang laufende Operationen.

MCP verbindet einen Agent mit Tools. A2A verbindet einen Agent mit anderen Agents. MCP-Server sind transparent: Sie sehen genau, was sie tun. A2A-Agents sind opak. Der aufrufende Agent weiß nicht und muss nicht wissen, welches Modell, Framework oder welche Logik im entfernten Agent läuft. Er sendet eine Aufgabe und bekommt Ergebnisse zurück.

Wie funktioniert A2A?

A2A definiert drei Akteure:

User: Der Mensch oder automatisierte Dienst, der Arbeit anfordert.
A2A Client: Die Anwendung, die Aufgaben im Auftrag des Benutzers sendet.
A2A Server: Ein entfernter Agent, der einen HTTP-Endpoint bereitstellt. Er operiert als Black Box.

Agent Cards sind der Entdeckungsmechanismus. Jeder A2A-Server veröffentlicht ein JSON-Dokument (typischerweise unter /.well-known/agent-card.json), das beschreibt:

Agent-Identität (Name, Beschreibung, Anbieter)
Service-Endpoint-URL
Unterstützte Fähigkeiten (Streaming, Push-Benachrichtigungen)
Verfügbare Skills mit Beschreibungen
Authentifizierungsanforderungen
Optionale digitale Signatur zur Verifizierung

Eine Task (Aufgabe) ist die Arbeitseinheit. Jede Task hat eine eindeutige ID und durchläuft einen Lebenszyklus:

submitted → working → completed
                   → failed
                   → canceled
                   → rejected
           → input-required (Multi-Turn: Agent braucht mehr Informationen vom Client)

Nachrichten enthalten Parts: Text, Dateireferenzen oder strukturierte JSON-Daten. Aufgabenergebnisse heißen Artifacts, die ebenfalls Parts enthalten. Ein Agent kann eine Code-Datei, eine Textzusammenfassung und einen JSON-Bericht in einer einzigen Antwort zurückgeben.

A2A unterstützt drei Kommunikationsmuster:

Request/Response: Client sendet eine Aufgabe, fragt den Status mit GetTask ab.
Streaming (SSE): Inkrementelle Echtzeit-Updates über persistente HTTP-Verbindungen. Der Client ruft SendStreamingMessage auf und empfängt Events, während der Agent arbeitet.
Push Notifications (Webhooks): Für lang laufende Aufgaben sendet der Agent Statusupdates per POST an eine vom Client registrierte Webhook-URL.

Alle Kommunikation nutzt JSON-RPC 2.0 über HTTPS. Version 0.3 fügte gRPC-Unterstützung und signierte Agent Cards hinzu. Die aktuelle Version ist A2A v1.0.0.

Wie sind A2A und ACP fusioniert?

IBM startete das Agent Communication Protocol (ACP) im März 2025, um seine BeeAI-Plattform zu betreiben. Google kündigte A2A im folgenden Monat an. Beide Protokolle lösten dasselbe Problem: Agent-zu-Agent-Kommunikation.

Im August 2025 gab die Linux Foundation bekannt, dass ACP in A2A aufgehen würde. IBMs ACP-Team unter Kate Blair trat dem technischen Lenkungsausschuss von A2A bei, zusammen mit Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow und SAP. Die BeeAI-Plattform wechselte von ACP zu A2A, und die ACP-spezifische Entwicklung wurde eingestellt.

Falls Sie ACP separat evaluiert haben: Hören Sie damit auf. Die Antwort ist A2A.

Was ist ANP (Agent Network Protocol)?

ANP (Agent Network Protocol) ist ein Peer-to-Peer-Protokoll, das KI-Agents ermöglicht, sich gegenseitig zu entdecken und über offene Netzwerke zu kommunizieren, ohne zentrale Autorität. Anders als MCPs Client-Server-Modell und A2As Client-Server-Aufgabendelegierung behandelt ANP jeden Agent als gleichberechtigten Peer. Es nutzt W3C Decentralized Identifiers (DIDs) für Identität, JSON-LD für Datenaustausch und enthält eine Metaprotokoll-Schicht, in der Agents ihre Kommunikationsweise verhandeln.

ANP adressiert ein anderes Problem als MCP und A2A. Diese Protokolle setzen voraus, dass Sie wissen, welchen Server oder Agent Sie ansprechen wollen. ANP beantwortet die Frage: Wie findet ein Agent andere Agents, mit denen er noch nie interagiert hat, über Organisationsgrenzen hinweg, ohne zentrales Verzeichnis?

Wie unterscheidet sich ANP von A2A?

ANP hat eine Drei-Schichten-Architektur:

Schicht 1: Identität und verschlüsselte Kommunikation. Jeder Agent erhält einen W3C Decentralized Identifier mit der Methode did:wba (Web-Based Agent). Jede DID wird einem HTTPS-gehosteten DID-Dokument zugeordnet, sodass die Identitätsauflösung bestehende Web-Infrastruktur nutzt. Zwei Agents können gegenseitig ihre Identität verifizieren und verschlüsselte Kanäle aufbauen, ohne zentrale Autorität.

Schicht 2: Metaprotokoll. Agents verhandeln Kommunikationsprotokolle dynamisch. Statt dass beide Agents dasselbe feste Protokoll unterstützen müssen, tauschen sie Anforderungen in strukturierter Form aus, einigen sich auf ein Protokoll und kommunizieren dann darüber. Das macht ANP anpassungsfähig für Szenarien, die A2As fester JSON-RPC-Ansatz nicht abdecken kann.

Schicht 3: Anwendungsprotokoll. Agent-Beschreibungen nutzen JSON-LD, verknüpft mit schema.org-Ontologien. Entdeckung funktioniert auf zwei Wegen:

Aktive Entdeckung: Den /.well-known/agent-descriptions-Endpoint einer Domain abfragen.
Passive Entdeckung: Agents registrieren sich bei Indexierungsdiensten, die Beschreibungen crawlen und katalogisieren.

Architekturvergleich zwischen ANP und A2A:

Aspekt	A2A	ANP
Topologie	Client-Server	Peer-to-Peer
Identität	Agent Cards (selbst veröffentlichtes JSON)	W3C DIDs (dezentral, verifizierbar)
Entdeckung	Bekannte URL (`/.well-known/agent-card.json`)	Dezentrale Indexierung + Well-Known-Endpoints
Protokollflexibilität	Fest (JSON-RPC 2.0)	Metaprotokoll-Verhandlung
Datenformat	JSON Parts (Text, Dateien, strukturierte Daten)	JSON-LD mit semantischer Verknüpfung

Aktueller Status: ANP befindet sich noch im Vorschlags- und frühen Entwicklungsstadium. Es gibt ein GitHub-Repository und ein Whitepaper der W3C Community Group, aber keine produktionsreifen SDKs oder breite Adoption. Die Spezifikation wird nicht von der AAIF verwaltet.

Wie vergleichen sich MCP, A2A und ANP?

Die drei Protokolle verglichen anhand der Dimensionen, die beim Entwurf eines Agent-Systems zählen:

	MCP	A2A	ANP
Gelöstes Problem	Agent-zu-Tool-Verbindung	Agent-zu-Agent-Aufgabendelegierung	Netzwerkübergreifende Agent-Entdeckung und Kommunikation
Architektur	Client-Server (Host → Client → Server)	Client-Server (Client → entfernter Agent)	Peer-to-Peer (Agent ↔ Agent)
Transport	stdio, Streamable HTTP	HTTPS (JSON-RPC 2.0), SSE, gRPC	HTTPS, verhandelbar über Metaprotokoll
Identitätsmodell	Server-Identität implizit (vom Host konfiguriert)	Agent Cards (selbst veröffentlichtes JSON)	W3C DIDs (`did:wba`)
Datenformat	JSON-RPC 2.0	JSON-RPC 2.0 mit Parts (Text, Dateien, strukturiert)	JSON-LD (semantisch, verknüpfte Daten)
Entdeckung	Manuelle Konfiguration oder Registry-Abfrage	`/.well-known/agent-card.json`	DID-Auflösung + dezentrale Indexierung
Governance	AAIF / Linux Foundation	AAIF / Linux Foundation	W3C Community Group (unabhängig)
Spezifikationsversion	2025-11-25	v1.0.0	Whitepaper-Stadium
Reife	Produktion (97M+ monatliche SDK-Downloads)	Produktion (v1.0.0, SDKs der großen Anbieter)	Frühe Entwicklung (keine Produktions-SDKs)
Anwendungsfall	Ihrem Agent Zugriff auf Datenbanken, APIs, Dateien geben	Ihren Agent Arbeit an spezialisierte Agents delegieren lassen	Agents über das offene Internet finden lassen

Wie arbeiten diese Protokolle zusammen?

Diese Protokolle sind keine Alternativen. Sie sind Schichten. Nehmen wir ein konkretes Beispiel.

Angenommen, Sie betreiben einen Coding-Agent auf Ihrem VPS. Er muss:

Dateien aus Ihrem Git-Repository lesen
Die Datenbank Ihres Projekts nach Schema-Informationen abfragen
Einen separaten Review-Agent bitten, seine Arbeit zu prüfen
Einen Deployment-Agent finden, der vom Infrastruktur-Team Ihres Kunden betrieben wird

Die Protokolle stapeln sich so:

┌─────────────────────────────────────────────────────────┐
│                    Ihr VPS                               │
│                                                         │
│  ┌──────────────┐    MCP     ┌───────────────────────┐  │
│  │              │◄──────────►│ MCP Server: Git tools  │  │
│  │  Coding-     │            └───────────────────────┘  │
│  │  Agent       │    MCP     ┌───────────────────────┐  │
│  │  (Host)      │◄──────────►│ MCP Server: DB schema  │  │
│  │              │            └───────────────────────┘  │
│  │              │                                       │
│  │              │    A2A     ┌───────────────────────┐  │
│  │              │───────────►│ Review Agent (A2A)     │  │
│  └──────┬───────┘            └───────────────────────┘  │
│         │                                               │
└─────────┼───────────────────────────────────────────────┘
          │
          │  ANP (netzwerkübergreifende Entdeckung)
          ▼
┌─────────────────────────┐
│ Deployment-Agent des     │
│ Kunden (entdeckt via     │
│ DID-Auflösung)           │
└─────────────────────────┘

Schicht 1 (MCP): Der Coding-Agent nutzt MCP-Clients, um sich mit lokalen MCP-Servern für Git-Operationen und Datenbankabfragen zu verbinden. Das sind Tool-Integrationen. Der Agent ruft Funktionen auf und liest Daten.

Schicht 2 (A2A): Der Coding-Agent delegiert Code-Review an einen separaten Review-Agent auf demselben Server (oder einem anderen). Er sendet eine Aufgabe via A2A, der Review-Agent arbeitet asynchron und streamt Ergebnisse zurück. Der Coding-Agent weiß nicht, welches Modell oder Framework der Review-Agent nutzt.

Schicht 3 (ANP): Der Coding-Agent muss einen Deployment-Agent finden, mit dem er noch nie interagiert hat, betrieben von einer anderen Organisation. ANPs DID-basierte Entdeckung lokalisiert den Agent, verifiziert seine Identität und verhandelt ein Kommunikationsprotokoll.

Für die meisten selbst gehosteten Setups reicht heute MCP. Fügen Sie A2A hinzu, wenn Sie mehrere spezialisierte Agents haben, die zusammenarbeiten müssen. ANP ist für die Produktion noch nicht nützlich, wird aber relevant, wenn Agent-Ökosysteme Organisationsgrenzen überschreiten.

Welches Protokoll sollten Sie verwenden?

Beginnen Sie mit dem einfachsten Protokoll, das Ihr Problem löst. Fügen Sie Schichten erst hinzu, wenn Sie an eine Grenze stoßen.

Entscheidungshilfe:

Muss Ihr Agent auf Tools, Datenbanken oder APIs zugreifen? Ja → Implementieren Sie MCP. Bauen oder installieren Sie MCP-Server für Ihre Datenquellen. Das deckt 80 % der Agent-Integrationsbedürfnisse ab.
Haben Sie mehrere Agents, die sich gegenseitig Aufgaben delegieren müssen? Ja → Fügen Sie A2A hinzu. Veröffentlichen Sie Agent Cards für jeden Agent. Nutzen Sie A2A für Aufgabendelegierung und Ergebnis-Streaming. Nein → Sie brauchen A2A nicht. Wenn ein Agent APIs über MCP aufruft, genügt das.
Müssen Ihre Agents unbekannte Agents über Organisationsgrenzen hinweg entdecken? Ja → Evaluieren Sie ANP, wenn Produktions-SDKs verfügbar sind. Heute würden Sie das mit einem manuellen Register oder einem gemeinsamen A2A-Agent-Verzeichnis lösen. Nein → Überspringen Sie ANP vorerst.

Gängige Muster:

Setup	Benötigte Protokolle
Einzelner Agent + Tools (die meisten Projekte)	Nur MCP
Mehrere spezialisierte Agents auf einem Server	MCP + A2A
Organisationsübergreifende Zusammenarbeit	MCP + A2A + ANP (bei Reife)
Agent-Marktplatz / offene Entdeckung	A2A + ANP

Wenn Sie gerade mit KI-Agents auf einem VPS anfangen, beginnen Sie mit MCP. Verbinden Sie einen Agent mit einem Tool. Bringen Sie es zum Laufen. Dann skalieren Sie die Architektur, wenn Ihre Anforderungen wachsen.

Welche Sicherheitsrisiken hat jedes Protokoll?

Jedes Protokoll eröffnet eine andere Angriffsfläche. Wenn Sie Agents selbst hosten, sind das die relevanten Bedrohungen.

Protokoll	Bedrohung	Auswirkung	Gegenmaßnahme
MCP	Server-Side Request Forgery (SSRF)	Ein bösartiger Prompt bringt den Agent dazu, ein MCP-Tool aufzurufen, das Anfragen an interne Dienste sendet (Metadaten-Endpoints, Datenbanken, Admin-Panels).	Betreiben Sie MCP-Server in isolierten Netzwerk-Namespaces. Beschränken Sie ausgehende Verbindungen per Firewall. Validieren Sie Tool-Eingaben serverseitig.
MCP	Nicht vertrauenswürdige Tool-Beschreibungen	MCP-Tool-Annotationen (Beschreibungen, Parameterschemata) kommen vom Server. Ein kompromittierter Server kann lügen, was ein Tool tut, um das LLM zu manipulieren.	Verbinden Sie nur MCP-Server, die Sie kontrollieren oder denen Sie vertrauen. Prüfen Sie Tool-Beschreibungen. Die MCP-Spezifikation kennzeichnet Tool-Annotationen ausdrücklich als nicht vertrauenswürdig.
A2A	Agent-Identitätsdiebstahl	Ohne signierte Agent Cards kann ein Angreifer eine gefälschte Agent Card an einer bekannten URL veröffentlichen und Aufgaben abfangen, die für einen legitimen Agent bestimmt sind.	Nutzen Sie A2As digitale Signatur für Agent Cards (hinzugefügt in v0.3). Verifizieren Sie Signaturen vor dem Senden von Aufgaben. Pinnen Sie bekannte Agent-Endpoints.
A2A	Exfiltration von Aufgabendaten	Aufgaben können sensible Daten enthalten (Code, Zugangsdaten, Geschäftslogik). Wird der entfernte Agent kompromittiert, werden diese Daten geleakt.	Verschlüsseln Sie sensible Aufgabendaten auf Anwendungsebene. Nutzen Sie gegenseitiges TLS zwischen Agents. Minimieren Sie die in Aufgaben gesendeten Daten.
ANP	DID-Vertrauensaufbau	Die Methode `did:wba` basiert auf HTTPS-gehosteten DID-Dokumenten. Wird eine Domain kompromittiert, sind alle Agent-Identitäten auf dieser Domain kompromittiert.	Verwenden Sie separate Domains für Agent-Identität. Überwachen Sie Änderungen an DID-Dokumenten. Implementieren Sie DID-Dokument-Pinning für bekannte Agents.
ANP	Metaprotokoll-Missbrauch	Die Verhandlungsschicht könnte ausgenutzt werden, um einen Agent zur Nutzung eines unsicheren oder bösartigen Kommunikationsprotokolls zu verleiten.	Beschränken Sie die Metaprotokoll-Verhandlung auf eine Whitelist bekannter Protokolle. Protokollieren und auditieren Sie alle Protokollverhandlungen.

Einen vollständigen Leitfaden zur Absicherung Ihres Agent-Servers finden Sie unter .

Wohin entwickelt sich die Governance?

Sowohl MCP als auch A2A liegen unter der Agentic AI Foundation (AAIF), Teil der Linux Foundation. Die AAIF wurde im Dezember 2025 von drei Mitgründern gegründet: Anthropic, OpenAI und Block. Google, Microsoft, AWS, Bloomberg und Cloudflare traten als Platinum-Mitglieder bei. Kein einzelner Anbieter kontrolliert die Protokollrichtung.

Die AAIF beherbergt auch goose (Blocks Open-Source-Agent-Framework) und AGENTS.md (OpenAIs Standard, um KI-Agents projektspezifische Anleitungen zu geben).

ANP wird unabhängig durch eine W3C Community Group verwaltet. Es ist nicht Teil der AAIF. Ob ANP der AAIF beitritt oder unabhängig bleibt, wird seine Adoptionstrajektorie beeinflussen.

Die Governance-Teilung hat eine praktische Konsequenz: MCP und A2A werden unter koordinierter Steuerung gemeinsam weiterentwickelt. ANP wird nach eigenem Zeitplan evolvieren. Wenn Sie architektonische Entscheidungen treffen, tragen MCP und A2A ein geringeres Governance-Risiko.

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.