Wir werden das in etwa jedem zweiten Discovery-Call gefragt: „Sollen wir uns auf A2A oder MCP standardisieren?"
Die Prämisse der Frage ist falsch. Sie sind keine Konkurrenten. Sie lösen unterschiedliche Probleme auf unterschiedlichen Ebenen, und ein gesundes agentisches System verwendet beide.
Wofür MCP da ist
MCP (Model Context Protocol) ist ein Standard für Tool-Surfaces. Es beantwortet: Wie entdeckt und ruft ein LLM-basierter Agent Tools auf, die nicht Teil seines Trainings sind? Dokumenten-Retrieval, Datenbankabfragen, Kalender-APIs, interne Services — jedes Tool veröffentlicht einen MCP-Server, der Agent verbindet sich, listet Capabilities auf, ruft auf.
Die Form ist: ein Agent ↔ viele Tools. Das Tool ist passiv; der Agent entscheidet, wann er es aufruft.
MCP liefert: Schema-Discovery, typisierte Parameter, strukturierte Returns, Authentifizierungsgrenzen, Sandboxing. Es ist im Wesentlichen ein RPC-Standard, abgestimmt auf agentische Clients.
Wofür A2A da ist
A2A (Agent-to-Agent-Protokolle, von denen es mehrere gibt — Googles A2A, AGNTCY, andere) ist ein Standard für Agent-Zusammenarbeit. Es beantwortet: Wie koordinieren mehrere semi-autonome Agenten, übergeben Teilaufgaben und aggregieren Ergebnisse?
Die Form ist: Agent ↔ Agent, mit State. Beide Seiten haben ihre eigenen Reasoning-Loops. Handoffs enthalten Kontext, Zwischenergebnisse, manchmal Ownership einer Teilaufgabe.
A2A liefert: Agent-Cards (Capability-Anzeigen), Task-Lifecycles, Message-Passing, optionales Streaming und Human-in-the-Loop. Es ist kein RPC — es ist näher an einem typisierten Actor-System.
Warum die Verwechslung
Beide beinhalten Agenten, die über ein Protokoll mit strukturierten Payloads mit etwas sprechen. Beide produzieren JSON. Beide haben Client- und Server-Rollen. Aus 30.000 Fuß Höhe sehen sie wie dasselbe aus.
Aber der Grad der Autonomie auf jeder Seite ist der eigentliche Unterschied:
- MCP-Server: passiv. Antwortet auf Calls. Hat keinen eigenen Reasoning-Loop.
- A2A-Agent: aktiv. Kann Tasks ablehnen, Alternativen vorschlagen, an andere Agenten übergeben, Klärung anfordern.
Wenn die andere Seite „hol diese Zeile aus einer Datenbank" ist, ist das MCP. Wenn die andere Seite „untersuche diese Anomalie und sag mir, was du findest" ist, ist das A2A.
Die Architektur, die tatsächlich funktioniert
In jedem Multi-Agent-System, das wir ausgeliefert haben, sieht die Aufteilung so aus:
- Top of the stack: ein Orchestrator (oft selbst ein Agent) routet Nutzeranfragen an Spezialisten-Agenten.
- Spezialisten-Agenten kommunizieren über A2A. Handoffs erhalten Kontext; Supervisoren tracken Task-State.
- Spezialisten nutzen Tools über MCP. Der Retrieval-Agent hat eine MCP-Verbindung zu einer Vektor-DB und eine MCP-Verbindung zu einem Fulltext-Search-Service. Der „Ops-Agent" hat eine MCP-Verbindung zu einem Ticket-System.
A2A ist, wie die Agenten koordinieren. MCP ist, wie jeder Agent handelt.
Die pragmatische Sicht
Adoptieren Sie MCP zuerst — es löst das unmittelbarste Problem (mit Tools sprechen), hat heute das breitere Ökosystem (die meisten LLM-Anbieter liefern nativen MCP-Support) und der Upgrade-Pfad von „ad-hoc Tool-Calls" zu MCP ist geradlinig.
Adoptieren Sie A2A, wenn Sie mehr als einen Agenten haben, der Arbeit übergeben muss. Wenn Ihr System einen einzelnen Agenten + viele Tools hat, ist A2A overkill — Sie koordinieren niemanden. In dem Moment, in dem Sie einen zweiten Spezialisten-Agenten hinzufügen, der mit dem ersten sprechen muss, beginnt A2A, sich zu lohnen.
Wählen Sie nicht. Stacken Sie sie.