--- title: "A2A vs. MCP: Agent-zu-Tool und Agent-zu-Agent im Vergleich" description: "A2A und MCP sind zwei komplementäre offene Protokolle für KI-Agenten: MCP (Model Context Protocol, Anthropic) verbindet einen Agenten mit Werkzeugen, Daten und Kontext (Agent-zu-Tool). A2A (Agent2Agent, Google) lässt eigenständige Agenten miteinander kooperieren (Agent-zu-Agent). Sie konkurrieren nicht, sie ergänzen sich." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen/a2a-vs-mcp-unterschied" category: "KI Agenten" topic: "Agent-to-Agent (A2A) Protocol" updated: "2026-07-29T08:52:53.543Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # A2A vs. MCP: Agent-zu-Tool und Agent-zu-Agent im Vergleich A2A und MCP sind zwei komplementäre offene Protokolle für KI-Agenten: MCP (Model Context Protocol, Anthropic) verbindet einen Agenten mit Werkzeugen, Daten und Kontext (Agent-zu-Tool). A2A (Agent2Agent, Google) lässt eigenständige Agenten miteinander kooperieren (Agent-zu-Agent). Sie konkurrieren nicht, sie ergänzen sich. ## Kernaussagen - MCP regelt Agent-zu-Tool, A2A regelt Agent-zu-Agent, die offizielle Faustformel von Google, Salesforce und Microsoft lautet: MCP für Capabilities, A2A für Collaboration. - Beide Protokolle nutzen JSON-RPC 2.0, stehen seit 2025 unter dem Dach der Linux Foundation und sind als komplementär konzipiert, nicht als Konkurrenten. - MCP gibt einem Agenten Hände (Tools, Datenbanken, APIs); A2A gibt mehreren Agenten eine gemeinsame Sprache, ohne dass sie ihre Prompts, Modelle oder Speicher offenlegen müssen. - Der konvergente Stack 2026 ist eindeutig: MCP + A2A. ACP ist im August 2025 in A2A aufgegangen, AGNTCY ist eine Identitäts-/Observability-Schicht darüber, NANDA bleibt Forschung. - In DACH-Architekturen entsteht bei jedem A2A-Hop und jeder MCP-Anbindung eine eigene Auftragsverarbeitungs- und ggf. Datentransfer-Frage. Komplementarität auf Protokollebene bedeutet längere AVV-Ketten in der Praxis. A2A und [MCP](/de/glossar/mcp) sind zwei komplementäre offene Protokolle für [KI](/de/glossar/ki)-Agenten. MCP ([Model Context Protocol](/de/glossar/mcp), ursprünglich von Anthropic, November 2024) verbindet einen Agenten mit Werkzeugen, Daten und Kontext, das ist die [Agent](/de/glossar/agent)-zu-Tool-Ebene. A2A (Agent2Agent, ursprünglich von Google, April 2025) lässt eigenständige Agenten miteinander kooperieren, das ist die Agent-zu-Agent-Ebene. Sie konkurrieren nicht. Sie lösen unterschiedliche Probleme und werden in der Praxis gemeinsam eingesetzt. Wer einmal verinnerlicht hat, dass es sich um [zwei Schichten desselben Stacks](/de/wissen/ki-agenten/a2a-protocol-grundlagen/linux-foundation-aaif-bedeutung) handelt, nicht um zwei Lager in einem Standardkrieg, trifft schnell bessere Architekturentscheidungen. - **MCP gibt einem Agenten Werkzeuge.** Es standardisiert, wie ein Agent eine Datenbank abfragt, ein [CRM](/de/glossar/crm) ausliest, eine Datei öffnet oder eine Web-Suche auslöst. - **A2A lässt Agenten zusammenarbeiten.** Es standardisiert, wie ein Agent eine Aufgabe an einen anderen, eigenständigen Agenten delegiert, auch über System- und Anbietergrenzen hinweg. - **Beide ergänzen sich.** Die offizielle Faustformel von Google, Salesforce und Microsoft lautet: „MCP ist für Capabilities (agent-to-tool). A2A ist für Collaboration (agent-to-agent)." IBM bestätigt nach dem Merge seines ACP-Projekts dieselbe Linie. ## Das mentale Modell: Hände versus gemeinsame Sprache Ein einprägsames Bild: MCP gibt einem Agenten **Hände**, die Fähigkeit, in der Außenwelt zu greifen, zu lesen und zu handeln. A2A gibt mehreren Agenten eine **gemeinsame Sprache**, die Fähigkeit, einander Aufträge zu erteilen und Ergebnisse zurückzugeben, ohne dass einer dem anderen seine Prompts, Modelle oder seinen Speicher offenlegen muss. Der entscheidende konzeptionelle Zug bei A2A ist, dass die interne Logik des entfernten Agenten **opak** bleibt. A2A definiert, *wie* Agenten miteinander reden, nicht *wie* sie denken. Genau das erlaubt es einem Salesforce-Agenten, einen SAP-Agenten aufzurufen, ohne dass einer der beiden seine internen Prompts preisgeben muss. MCP dagegen exponiert ein Werkzeug mit einem klar beschriebenen Schema, hier ist Transparenz über die Fähigkeit gerade der Sinn der Sache. ## Technischer Vergleich: Dimension, MCP und A2A Beide Protokolle bauen auf JSON-RPC 2.0 auf und stehen unter dem Dach der Linux Foundation, das unterstreicht, dass sie als ein zusammengehöriger Stack gedacht sind. | Dimension | MCP (Model Context Protocol) | A2A (Agent2Agent Protocol) | | --- | --- | --- | | Primärzweck | Agent-zu-Tool / Agent-zu-Kontext | Agent-zu-Agent (Peer-Kollaboration) | | Ursprung | Anthropic, 25. November 2024 | Google Cloud Next, April 2025 | | Governance (Stand 2026) | [Agentic AI](/de/glossar/agentic-ai) Foundation unter der Linux Foundation (Spende durch Anthropic am 9. Dezember 2025) | Linux Foundation (Spende durch Google am 23. Juni 2025) | | Transport | JSON-RPC 2.0 über stdio (lokal), Streamable HTTP (seit Spec-Revision April 2025) | JSON-RPC 2.0 über HTTPS; Streaming via Server-Sent Events; optionale Push-Benachrichtigungen | | Fähigkeitsentdeckung | Tool-Beschreibungen / Schemata pro Server | AgentCard. JSON-Dokument mit Endpoint, Fähigkeiten, Skills, Modalitäten, Auth-Verfahren | | Verbindet | Agent ↔ Datenbank, [API](/de/glossar/api), Dateisystem, Business-System | Agent ↔ anderer eigenständiger Agent | | Sichtbarkeit der Gegenseite | Werkzeug-Schema ist transparent | Interne Agentenlogik bleibt bewusst opak | | Interaktionsmodell | Tool-Aufruf / Request-Response | Task-Lebenszyklus: submitted → working → input-required → completed / failed / canceled | | Auth (Stand 2026) | OAuth 2.1 (seit Spec-Revision April 2025) | Auth-Schemata pro AgentCard deklariert | | Wann einsetzen | Sobald ein Agent ein externes System anspricht | Sobald mehrere Agenten kooperieren, besonders anbieterübergreifend | MCP hatte 2025 eine regelrechte Adoptionsexplosion: [OpenAI](/de/glossar/openai) übernahm es im März 2025, Google DeepMind im April 2025, dazu Microsoft Copilot Studio, Cursor, Zed, Replit und viele mehr. A2A wird inzwischen von über 100 Unternehmen unterstützt; Gründungsmitglieder des Linux-Foundation-Projekts sind AWS, Cisco, Google, Microsoft, Salesforce, SAP und ServiceNow. ## Warum „komplementär" wörtlich gemeint ist Es gibt eine technische Grauzone, die in Diskussionen oft für Verwirrung sorgt: Man *kann* einen Agenten als MCP-Server exponieren und ihn so für andere Agenten tool-förmig ansprechbar machen. Das funktioniert, aber es war nicht der Designzweck von MCP, und Anthropic, Google sowie Microsoft empfehlen für echte Peer-Kollaboration konsistent A2A. Der Grund liegt in den Semantiken. MCP kennt einen Tool-Aufruf: Request rein, Response raus. A2A kennt einen vollständigen **Task-Lebenszyklus** mit Zwischenzuständen, der für langlaufende, eventuell rückfragende Kooperation gebaut ist, inklusive des Zustands `input-required`, wenn der entfernte Agent eine Klärung braucht. Wer Agent-zu-Agent über MCP nachbaut, verliert genau diese Mechanik. Historisch gab es kurzzeitig ein drittes Protokoll, IBMs ACP (Agent Communication Protocol, März 2025). Es ist am 29. August 2025 unter LF AI & Data in A2A aufgegangen, die ACP-Designprinzipien (REST, async-default) leben in A2A weiter. Das verbleibende Bild für 2026 ist daher klar: **MCP + A2A** ist der konvergente Stack. AGNTCY (Cisco u. a.) ist eine Identitäts-, Discovery- und Observability-Schicht *über* A2A und MCP, kein Konkurrent. NANDA (MIT Media Lab) ist Forschung und gehört nicht in produktive Entscheidungen 2026. ## Kombiniertes Beispiel: Schadensbearbeitung mit beiden Protokollen Ein konkretes, vereinfachtes Beispiel macht das Zusammenspiel greifbar. Stell dir einen Versicherungs-Workflow vor, im Geist des dokumentierten Allianz-Projekts „Nemo", das sieben spezialisierte Agenten (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) einsetzt und einen Schadensfall in unter fünf Minuten durchläuft (mit Mensch-im-Loop für die finale Auszahlungsentscheidung). Pseudocode aus Architektursicht: \`\`\` # A2A-Ebene: Orchestrator delegiert an spezialisierte Peer-Agenten orchestrator.send\_task(coverage\_agent, task="Deckung prüfen für Fall #4711") orchestrator.send\_task(fraud\_agent, task="Betrugsindikatoren prüfen #4711") orchestrator.send\_task(weather\_agent, task="Unwetterdaten zum Schadensdatum") # Jeder Peer-Agent nutzt INTERN MCP, um an seine Werkzeuge zu kommen: # coverage\_agent -> MCP-Server "Policendatenbank" (SQL-Lookup) # fraud\_agent -> MCP-Server "Fraud-Scoring-API" # weather\_agent -> MCP-Server "Wetterdienst-API" # A2A-Task-Lebenszyklus: submitted -> working -> completed # Ergebnisse kehren als A2A-Artefakte zurück, Orchestrator synthetisiert \`\`\` Die Aufgabenverteilung zwischen den Agenten läuft über **A2A**, der Orchestrator weiß nicht und muss nicht wissen, welches Modell oder welcher [Prompt](/de/glossar/prompt) im Fraud-Agenten steckt. Sobald aber ein einzelner Agent die Policendatenbank abfragt oder eine Wetter-API anspricht, läuft das über **MCP**. A2A koordiniert die Köpfe, MCP bedient die Hände. Genau diese saubere Trennung ist der Grund, warum die beiden Protokolle als komplementär gelten. Zur Einordnung der Kosten- und Nutzendimension: Anthropics dokumentiertes Multi-Agenten-Forschungssystem (Lead-Modell plus parallele Sub-Agenten) erreichte intern +90,2 % auf Recherche-Breite gegenüber einem Einzel-Agenten, bei rund 15-fachem [Token](/de/glossar/token)-Verbrauch. Multi-Agenten-Architektur (und damit A2A) lohnt sich also vor allem für parallelisierbare, breit gefächerte Aufgaben, nicht als Selbstzweck. ## DACH-Realität: Komplementarität hat einen Compliance-Preis Für DACH-B2B-Entscheider ist eine Konsequenz wichtig, die in US-zentrierten Referenzarchitekturen selten ehrlich benannt wird: Wenn Agenten über A2A bei unterschiedlichen Anbietern laufen und nebenbei MCP-Tool-Aufrufe absetzen, überschreitet der Datenfluss bei *jeder* Aufgabe mehrere Verarbeitungs- und ggf. Datenresidenz-Grenzen. [Jeder A2A-Hop und jeder MCP-Server ist potenziell ein eigener Auftragsverarbeiter im Sinne der DSGVO](https://gdpr-info.eu/) (Art. 28). Komplementarität auf Protokollebene bedeutet in der Praxis also eine **längere AVV-Kette** und, bei grenzüberschreitenden Hops, pro Sprung eine eigene Transfer-Frage (Art. 44–49). Wer eine hybride Salesforce-plus-SAP-plus-Microsoft-Landschaft betreibt, sollte diese Hops von Anfang an mit einer durchgängigen Trace-ID protokollieren und die AVV-Kette pro Agent dokumentieren. ## Für Agenturen und B2B-Entscheider Die praktische Empfehlung ist eindeutig: **MCP für Werkzeuge, A2A für Agenten**, alles andere ist 2026 eine bewusste Abweichung vom konvergenten Stack und braucht eine Begründung. Für DACH-Mittelständler heißt das konkret, zuerst MCP-Kompetenz aufzubauen (Sie werden ohnehin MCP-Server schreiben oder konsumieren) und A2A einzuführen, sobald Agenten über System- und Anbietergrenzen kooperieren müssen. Für Agenturen und KI-nahe Produktanbieter ist der größte strategische Hebel, für jeden produktisierten Agenten eine **AgentCard** zu veröffentlichen. Damit kann ein Kundenbestand deinen Agenten direkt aus Agentforce, Joule oder Copilot Studio per A2A aufrufen, ohne kostspielige Einzelintegration. Wer eine [Multi-Agenten-Strategie für sein Unternehmen](/de/blog/ki-agenten-orchestrierung-arbeitsablaeufe-transformieren-im-jahr-2026) oder seine Kunden konzipieren will, sollte genau hier ansetzen: klare Protokolltrennung, dokumentierte AVV-Ketten und A2A-Auffindbarkeit von Tag eins an. Sprich uns an, wenn du diese Architektur für deinen DACH-Kontext belastbar aufsetzen willst. ## FAQ ### Was ist der Hauptunterschied zwischen A2A und MCP? MCP (Model Context Protocol) verbindet einen einzelnen Agenten mit externen Werkzeugen, Daten und Kontext. Dateisysteme, Datenbanken, Business-Systeme, Web-Suche. A2A (Agent2Agent) regelt die Kommunikation zwischen eigenständigen Agenten, die gemeinsam eine Aufgabe lösen. Kurz: MCP ist Agent-zu-Tool, A2A ist Agent-zu-Agent. Beide ergänzen sich, sie konkurrieren nicht. ### Konkurrieren A2A und MCP miteinander? Nein. A2A wurde laut Google, Salesforce, Microsoft und IBM bewusst komplementär zu MCP entworfen. Die offizielle Formulierung lautet: MCP ist für Capabilities (Agent-zu-Tool), A2A für Collaboration (Agent-zu-Agent). In produktiven Systemen laufen typischerweise beide parallel, ein Agent nutzt MCP für seine Tools und A2A, um Aufgaben an andere Agenten zu delegieren. ### Kann ich nicht einfach MCP auch für Agent-zu-Agent verwenden? Technisch ja: Man kann einen Agenten als MCP-Server mit tool-förmigen Fähigkeiten exponieren. Das funktioniert, ist aber nicht der Designzweck von MCP. Anthropic, Google und Microsoft empfehlen für echte Peer-Kollaboration konsistent A2A, weil A2A einen Task-Lebenszyklus, AgentCards zur Fähigkeitsentdeckung und bewusst opake interne Logik der Gegenseite mitbringt. ### Welches Protokoll sollte ein DACH-Mittelständler 2026 zuerst lernen? MCP. Für DACH-Mittelstandsprojekte gilt 2026: Du wirst MCP-Server schreiben oder konsumieren, ob geplant oder nicht. SAP Joule Studio 2.0, Microsoft 365 Copilot, Salesforce Agentforce, n8n und LangGraph sprechen alle MCP. A2A wird relevant, sobald Agenten über System- oder Anbietergrenzen hinweg zusammenarbeiten müssen, etwa zwischen Salesforce-, SAP- und Microsoft-Beständen. ### Stehen A2A und MCP unter einer gemeinsamen Governance? Beide stehen unter dem Dach der Linux Foundation. A2A wurde am 23. Juni 2025 von Google an die Linux Foundation übergeben (Gründungsmitglieder: AWS, Cisco, Google, Microsoft, Salesforce, SAP, ServiceNow). MCP wurde am 9. Dezember 2025 von Anthropic an die Agentic AI Foundation unter der Linux Foundation gespendet. Das spricht für eine kohärente offene Protokoll-Landschaft statt eines Anbieterkriegs. --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen/a2a-vs-mcp-unterschied). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.