MCP und A2A: Wo liegt der Unterschied?

Suchen Sie nach einem der beiden Protokolle, und Sie finden sie als Rivalen dargestellt, MCP gegen A2A, als müssten Sie auf eines setzen. Müssen Sie nicht. Sie konkurrieren nicht um dieselbe Aufgabe. Sie arbeiten auf verschiedenen Achsen desselben Systems, und ein produktiver Agenten-Stack betreibt in der Regel beide.

Die Verwechslung liegt nahe. Beide erschienen innerhalb eines Jahres, beide führen „Agent“ im Titel, und beide beschreiben, wie ein KI-System etwas außerhalb seiner selbst erreicht. Der Unterschied liegt darin, was sie verbinden und in welche Richtung. Das Model Context Protocol (MCP) verbindet einen Agenten nach unten, mit den Werkzeugen und Daten, mit denen er arbeitet. Das Agent2Agent-Protokoll (A2A) verbindet Agenten zur Seite, untereinander. Das eine ist senkrecht, das andere waagerecht.

Diese Unterscheidung entscheidet, wie Sie bauen, und sie entscheidet, wo eine Datenplattform wie Dawiso hineingehört. MCP ist das Protokoll, das geregelten Kontext zu einem Agenten trägt, und damit dasjenige, das die Data Governance unmittelbar berührt. A2A sitzt eine Schicht darüber und stimmt Agenten ab, die ihren Kontext bereits bekommen haben. Hält man die beiden Achsen auseinander, treten die nützlichen Fragen hervor, etwa wann man zu welchem greift und was keines von beiden allein erledigt.

Anthropic hat das Model Context Protocol im November 2024 vorgestellt, um ein Verbindungsproblem zu lösen. Ein KI-Modell für sich allein ist abgeschnitten. Es kann Ihre Datenbank nicht lesen, Ihre interne API nicht aufrufen und kein Dokument öffnen, solange nicht jemand diese Fähigkeit von Hand verdrahtet, und jedes Modell und jedes Werkzeug braucht seine eigene maßgeschneiderte Verdrahtung. MCP standardisiert diese Verdrahtung. Es gibt jedem Modell einen einheitlichen Weg, externe Werkzeuge, Datenquellen und Prompts zu entdecken und zu nutzen, sodass die Anbindung einmal geschrieben wird und überall funktioniert.

Die Form von MCP ist ein Client, der mit einem Server spricht. Ihr Agent betreibt einen MCP Client, ein Werkzeug oder eine Datenquelle stellt einen MCP Server bereit, und beide tauschen Nachrichten über ein festgelegtes Protokoll auf Basis von JSON-RPC aus. Der Server kündigt an, was er anbietet, und das Modell ruft es auf. Das ist die senkrechte Achse: ein einzelner Agent greift nach unten auf die Ressourcen zu, die er braucht, um eine Frage zu beantworten oder einen Schritt zu erledigen. Wenn von MCP als dem „USB-C für KI“ die Rede ist, ist genau dieses Bild gemeint. Ein Anschluss, viele Werkzeuge.

Was MCP nicht leistet, ist, diesen Agenten mit einem anderen Agenten zu verbinden. Es kennt keinen zweiten eigenständigen Akteur mit eigenen Zielen. Es ist die Leitung zwischen einem Modell und der Welt der Werkzeuge darunter, und in diesem Rahmen ist es zum Standard geworden. Bis 2026 gibt es Tausende von MCP Servern, von lokalen Dateisystemen bis zu Datenplattformen im Unternehmen.

Google hat das Agent2Agent-Protokoll im April 2025 angekündigt und es im Juni 2025 der Linux Foundation übergeben, wo es zu einem herstellerneutralen offenen Projekt wurde. Zum Einjährigen im April 2026 meldete die Linux Foundation, es sei von den ursprünglich gut 50 Startpartnern auf mehr als 150 Organisationen gewachsen, darunter AWS, Microsoft, IBM, Salesforce und SAP, mit produktivem Einsatz in den großen Clouds. A2A beantwortet eine Frage, die MCP nicht berührt: Wie arbeiten zwei Agenten zusammen, die von verschiedenen Teams auf verschiedenen Frameworks gebaut wurden, ohne dass einer das Innenleben des anderen kennt?

A2A behandelt jeden Agenten als gleichrangig und lässt ihn eine Fähigkeitskarte veröffentlichen, ein kleines maschinenlesbares Profil, das beschreibt, was er kann und wie man ihn erreicht. Ein Agent liest die Karte eines anderen, übergibt ihm eine Aufgabe und verfolgt sie über ihren Lebenszyklus bis zum Ergebnis, alles über gewöhnliches HTTP. Keiner der beiden muss offenlegen, wie er arbeitet. Ein Agent für Terminplanung kann eine Preisfrage an einen Finanzagenten abgeben und der Antwort trauen, ohne Gedächtnis, Werkzeuge oder Modell zu teilen. Auf dieser waagerechten Achse stimmen sich Agenten als eigenständige Gleichrangige über die Grenzen von Organisationen und Anbietern hinweg ab.

Was A2A nicht leistet, ist, einen dieser Agenten mit den darunterliegenden Werkzeugen und Daten zu verbinden. Es setzt voraus, dass jeder Agent seine eigene Arbeit bereits beherrscht. Es regelt den Austausch zwischen Agenten, nicht die Ressourcen darunter. Genau für diese untere Verbindung wurde MCP gebaut.

Das eine Protokoll zeigt nach unten, das andere zur Seite. Die Tabelle stellt sie über die Merkmale gegenüber, auf die es ankommt, wenn Sie entscheiden, zu welchem Sie greifen.

Weil sie auf verschiedenen Achsen arbeiten, ergänzen sich MCP und A2A, statt zu konkurrieren. Der Vergleich aus der Branche, zu dem die meisten greifen, ist der Web-Stack: HTTP, WebSocket und gRPC bestehen nebeneinander, weil sie verschiedene Transportprobleme lösen, und niemand fragt, welches davon „gewonnen“ hat. Bei den Agentenprotokollen stellt sich dieselbe Wirklichkeit mit mehreren Protokollen ein.

Ein konkretes Beispiel zeigt die Schichtung. Ein Agent im Betrieb bekommt die Aufgabe, einen Umsatzrückgang zu untersuchen. Er greift über MCP nach unten ins Data Warehouse, holt die einschlägigen Zahlen und liest ein paar interne Dokumente. Dann greift er über A2A zur Seite zu einem spezialisierten Finanzagenten und gibt die Frage ab, ob eine Vertragsänderung den Rückgang erklärt. Der Finanzagent nutzt seinerseits seine eigenen MCP-Verbindungen, um seine eigenen Systeme abzufragen, und liefert ein Ergebnis. MCP hat die senkrechte Arbeit in jedem Agenten erledigt. A2A die waagerechte zwischen ihnen. Nehmen Sie eines der beiden Protokolle weg, und der Ablauf bricht an einer anderen Stelle.

Deshalb ist „MCP oder A2A“ die falsche Kaufentscheidung. Sie wählen nicht eines aus. Sie entscheiden, wo jedes in einer Architektur hingehört, die vermutlich beide betreiben wird, neben den Assistenten und Copilots, die in Ihrem Warehouse ohnehin schon stecken. Wie dieser Wildwuchs an Werkzeugen die Bedeutung zersplittert, haben wir unter Kontextsilos: Datensilos, neu geboren im KI-Zeitalter auseinandergenommen.

MCP und A2A sind beide Transport. Sie legen fest, wie Kontext und Aufgaben zwischen Systemen wandern. Was keines von beiden festlegt, ist, was dieser Kontext bedeutet, ob er aktuell ist, wer ihn sehen darf und ob ihm zu trauen ist. Compliance mit dem Protokoll ist nicht dasselbe wie ein genauer Kontext.

Ein MCP Server kann eine Tabelle namens revenue getreulich an einen Agenten ausliefern, ohne dass irgendetwas im Protokoll sagt, welche Ihrer drei Umsatzdefinitionen sie abbildet, ob die Zahlen abgestimmt sind oder ob eine Zeile für den anfragenden Nutzer maskiert werden müsste. Ein Austausch über A2A kann eine formal einwandfreie Aufgabe zwischen zwei Agenten weitergeben, während beide mit widersprüchlichen Definitionen von „aktiver Kunde“ arbeiten. Die Protokolle tragen die Fracht korrekt und schweigen dazu, ob die Fracht stimmt.

Bei A2A wiegt das schwerer als bei einem Chatbot, weil Agenten handeln. Eine falsch verstandene Definition führt nicht mehr zu einem falschen Satz, den ein Mensch prüft. Sie führt zu einer falschen Handlung, über Systeme hinweg abgegeben und ausgeführt, bevor es jemand bemerkt. Je schneller und stärker vernetzt Ihre Agenten werden, desto mehr entscheidet die Qualität des Kontexts darunter über das Ergebnis. Die vollständige Begründung für diese fehlende Schicht steht unter Context Engineering für Enterprise-KI.

Dawiso sitzt in der Schicht, die beide Protokolle offen lassen, im geregelten Kontext darunter. Es bindet mehr als 40 Plattformen an und baut darüber ein Fundament: einen Data Catalog dessen, was es gibt, ein Business Glossary dessen, was jeder Begriff bedeutet, eine Klassifizierung dessen, was sensibel ist, und Interactive Data Lineage dessen, woher alles kommt. Eine Definition von „aktiver Kunde“, einmal geregelt, statt einer anderen in jedem Werkzeug.

Von den beiden Protokollen spricht Dawiso MCP. Über den Context Layer und seinen MCP Server stellt Dawiso diesen geregelten Kontext jedem MCP-fähigen Assistenten oder Agenten bereit, sodass der Agent verlässliche Definitionen, Klassifizierungen und Lineage aus einer Schicht liest, die Ihnen gehört, statt sich eigene zusammenzureimen. A2A setzt Dawiso nicht um, und das muss es auch nicht. Wenn ein Agent A2A nutzt, um sich mit anderen Agenten abzustimmen, war der Kontext, den er weitergibt, bereits an der Quelle geregelt, über MCP. MCP trägt ihn, A2A stimmt sich darum herum ab, und Dawiso sorgt dafür, dass das Getragene stimmt.

Wenn die Wahl also als „MCP oder A2A“ auftaucht, lautet die ehrliche Antwort „beides, und noch etwas“. Die Protokolle sind der Transport. Die Agenten sind die Akteure. Geregelter Kontext ist das, was das System belastbar hält, und das Protokoll, das ihn ausliefert, ist MCP.