04.08.2026 AI Engineering 6 Minuten Lesezeit

MCP und A2A — die Protokollschicht des Agenten-Ökosystems

Die MCP-Revision 2026-07-28 macht das Protokoll zustandslos und härtet OAuth; A2A 1.0 bringt signierte Agent Cards, Multi-Tenancy und drei Protokoll-Bindings. Der Artikel prüft den aktuellen Stand beider Standards, erklärt das Zusammenspiel der Schichten Agent-zu-Werkzeug und Agent-zu-Agent, skizziert Gateway-Muster für Unternehmen und benennt präzise, was die Protokolle nicht lösen: Semantik und Vertrauen in Inhalte.

Warum Agenten-Ökosysteme eine Protokollschicht brauchen

Ein Agent ist ein Programm, in dem ein Sprachmodell plant, Werkzeuge aufruft und Ergebnisse iterativ verarbeitet. Sobald mehrere Teams — oder mehrere Unternehmen — Agenten betreiben, entstehen zwei Integrationsprobleme, die häufig vermengt werden. Erstens: Wie erreicht ein Agent ein Werkzeug, eine API, eine Datenbank, ohne dass für jede Paarung ein eigener Adapter entsteht? Zweitens: Wie delegiert ein Agent Arbeit an einen anderen Agenten, den er weder gebaut hat noch inspizieren kann?

Die Industrie hat darauf mit zwei Protokollen geantwortet, nicht mit einem. Das Model Context Protocol (MCP, von Anthropic im November 2024 veröffentlicht) standardisiert die Verbindung Agent-zu-Werkzeug. Das Agent2Agent-Protokoll (A2A, von Google im April 2025 initiiert) standardisiert die Kommunikation Agent-zu-Agent. Beide stehen heute unter Governance der Linux Foundation, und beide erreichten 2026 einen Wendepunkt: MCP mit der größten Revision seit dem Start, A2A mit dem ersten stabilen Release.

Ein Agent erreicht seine Tools über MCP — eine Standard-Schnittstelle. 1/4

MCP nach der Revision 2026-07-28

Die MCP-Revision vom 28. Juli 2026 — das fünfte Spezifikations-Release — macht den Protokollkern zustandslos. Der initialize-Handshake und der Mcp-Session-Id-Header entfallen; jede Anfrage trägt Protokollversion, Client-Identität und Capabilities im Feld _meta. Damit kann jede Anfrage auf jeder Server-Instanz hinter einem gewöhnlichen Load Balancer landen. Ein neuer server/discover-Aufruf ersetzt den früheren Capability-Austausch, Multi Round-Trip Requests ersetzen server-initiierte Streams für Rückfragen während eines Aufrufs.

Für Infrastrukturteams zählen vor allem zwei Änderungen. Streamable-HTTP-Anfragen müssen jetzt die Header Mcp-Method und Mcp-Name tragen; Gateways können damit routen und drosseln, ohne JSON-Bodies zu parsen. Die Autorisierung, aufgebaut auf OAuth 2.1, wurde gehärtet: Clients müssen den iss-Parameter nach RFC 9207 validieren, und Dynamic Client Registration ist zugunsten von Client ID Metadata Documents als veraltet markiert. Tasks und MCP Apps erscheinen als versionierte Extensions statt als Kernfunktionen.

Die Adoptionszahlen sind überprüfbar. Anthropic meldet im Juli 2026 über 400 Millionen monatliche SDK-Downloads, eine Vervierfachung innerhalb eines Jahres. Die Linux Foundation zählte im Dezember 2025 mehr als 10.000 veröffentlichte MCP-Server; die offizielle Registry führte im Juli 2026 rund 18.850 Einträge — mit der Einschränkung, dass eine unabhängige Messung 17,2 % der angegebenen Remote-Endpunkte als nicht erreichbar auswies. Die Skalierung ist real; Kuratierung ist es nicht automatisch.

A2A 1.0 als Standard für Agent-zu-Agent

A2A 1.0, veröffentlicht am 12. März 2026, ist die erste stabile Version des Agent-zu-Agent-Standards. Das zentrale Objekt ist die Agent Card: ein JSON-Dokument, das Identität, Fähigkeiten und Endpunkte eines Agenten beschreibt. Version 1.0 macht diese Karten kryptografisch prüfbar — JSON Web Signatures (RFC 7515) über nach RFC 8785 kanonisiertem JSON. Ein Aufrufer kann so verifizieren, wer ein Agent ist, bevor er über Organisationsgrenzen hinweg eine Aufgabe delegiert.

Das Interaktionsmodell ist aufgabenbasiert: Nachricht senden oder streamen, dann den entstehenden Task abfragen, auflisten oder abbrechen; Ergebnisse kommen als Messages und Artifacts zurück. Drei Protokoll-Bindings sind normativ — JSON-RPC, gRPC und HTTP+JSON — definiert gegen eine einzige a2a.proto als Quelle der Wahrheit mit Äquivalenzgarantien. Multi-Tenancy erlaubt viele Agenten hinter einem Endpunkt. Laut Linux Foundation unterstützten im April 2026 mehr als 150 Organisationen den Standard; im Technical Steering Committee sitzen AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP und ServiceNow.

Wie sich die beiden Schichten ergänzen

Die beiden Protokolle konkurrieren nicht; sie arbeiten auf benachbarten Schichten. MCP verbindet einen Agenten mit Fähigkeiten, die er kontrolliert: Das Werkzeug führt eine definierte Funktion aus und liefert Daten. A2A verbindet einen Agenten mit Gegenübern, die er nicht kontrolliert: Der entfernte Agent plant selbst, nutzt eigene Werkzeuge und hält seinen inneren Zustand verborgen. In der Praxis ist ein Dienst oft beides — MCP-Client gegenüber seinen Werkzeugen und A2A-Server gegenüber anderen Agenten.

Drei Entscheidungsregeln decken die meisten Fälle ab. Erstens: Ist die entfernte Fähigkeit eine deterministische Funktion ihrer Eingaben, stellen Sie sie als MCP-Tool bereit. Zweitens: Plant das entfernte System selbst, hält eigenen Zustand und soll nicht Schritt für Schritt gesteuert werden, adressieren Sie es über A2A. Drittens: Leben beide Seiten in einer Laufzeitumgebung unter einem Team, nutzen Sie keines von beiden — prozessinterne Framework-Konstrukte sind günstiger als jedes Wire-Protokoll.

Dimension	MCP (2026-07-28)	A2A (1.0)
Verbindet	Agent mit Werkzeugen und Daten	Agent mit Partner-Agenten
Austauscheinheit	Tools, Resources, Prompts	Tasks, Messages, Artifacts
Discovery	Registry; server/discover-Aufruf	Signierte Agent Card (JWS, RFC 8785)
Bindings	JSON-RPC über Streamable HTTP; stdio	JSON-RPC, gRPC, HTTP+JSON
Autorisierung	OAuth 2.1, RFC 9207, CIMD	OAuth-2.0-Flows, PKCE, mTLS
Zustandsmodell	Zustandsloser Kern, explizite Handles	Task-Lebenszyklus mit Task-IDs
Governance	AAIF (Linux Foundation)	Linux Foundation, TSC aus 8 Firmen

Neutrale Governance unter der Linux Foundation

Im Dezember 2025 übergab Anthropic MCP an die Agentic AI Foundation (AAIF), einen Directed Fund unter der Linux Foundation, mitgegründet von Anthropic, Block und OpenAI und unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg. MCP wurde Gründungsprojekt neben goose und AGENTS.md. A2A war bereits 2025 von Google an die Linux Foundation übergeben worden. Kein einzelner Anbieter kontrolliert damit noch das Protokoll, von dem sein Ökosystem abhängt.

Für Unternehmen ist das keine Formalie. Protokollintegration ist eine Investition über Jahre, und die Revision 2026-07-28 verbindet neutrale Governance mit einer formalen Lifecycle-Richtlinie: Features durchlaufen Active → Deprecated → Removed mit mindestens zwölf Monaten Übergangsfrist, eine Conformance-Suite sichert Änderungen ab. Nicht ein einzelnes Feature macht ein Protokoll tragfähig, sondern vorhersagbare Evolution.

Gateway-Muster für Enterprise-Governance

Keines der beiden Protokolle definiert rollenbasierte Zugriffskontrolle, Audit-Trails oder Kostengrenzen. Das ist eine bewusste Abgrenzung, und das Ökosystem füllt sie mit einem Gateway-Muster: einer Kontrollschicht zwischen Agenten und Servern. Das Gateway erzwingt gefilterte Discovery — ein Agent sieht nur die Werkzeuge, die seine Identität erlaubt —, verwaltet Tokens zentral, sodass Rohzugangsdaten den Agenten nie erreichen, protokolliert jeden Aufruf mit Nutzeridentität und Argumenten und drosselt pro Agent und Werkzeug.

Der zustandslose MCP-Kern macht diese Schicht günstiger im Betrieb: Die Header Mcp-Method und Mcp-Name erlauben Routing und Policy auf HTTP-Ebene, cachebare Listenantworten (ttlMs, cacheScope) ersetzen langlebige Streams. Registries föderieren über Geschäftsbereiche und öffentliche Quellen hinweg; das quelloffene MCP Gateway and Registry von AWS (Apache 2.0) ist eine Referenzimplementierung. Für A2A gilt dasselbe Muster an der Organisationsgrenze — mit signierten Agent Cards, die vor jeder Delegation geprüft werden.

Was die Protokolle bewusst offenlassen

Beide Protokolle transportieren Struktur, nicht Bedeutung. MCP liefert das JSON-Schema eines Werkzeugs samt Verhaltensannotationen wie Read-only- oder Destructive-Hints — die Spezifikation markiert diese aber ausdrücklich als nicht vertrauenswürdige Hinweise, und nichts im Protokoll prüft, ob eine Beschreibung dem tatsächlichen Verhalten entspricht. Schemaqualität bleibt Ingenieursaufgabe des Server-Autors und bestimmt direkt, wie zuverlässig Agenten Aufrufe routen.

Vertrauen in Inhalte stellen die Protokolle ebenfalls nicht her. Eine signierte Agent Card authentifiziert Identität, nicht Ehrlichkeit. Tool Poisoning — bösartige Instruktionen in Tool-Metadaten oder -Antworten — ist eine indirekte Prompt Injection, die kein Transport verhindern kann: Der MCPTox-Benchmark, aufgebaut auf 45 produktiven MCP-Servern, maß Erfolgsraten von bis zu 72,8 % bei einzelnen Agenten. Provenance-Tracking, Inhaltsfilter und Least-Privilege-Isolation müssen oberhalb der Protokollschicht entstehen.

Auch die ehrliche Umkehrung gilt: Nicht jedes System braucht diese Protokolle. Eine Multi-Agenten-Architektur innerhalb einer Laufzeitumgebung — ein Prozess, ein Team, ein Deployment — ist mit framework-internen Konstrukten besser bedient als mit A2A-Endpunkten. Und drei feste interne APIs rechtfertigen weder Registry noch Gateway. Protokolle lohnen sich an Grenzen; innerhalb einer Grenze erzeugen sie Latenz und Angriffsfläche.

Ausblick: Die Protokollschicht wird Infrastruktur

Die Richtung steht in den Spezifikationen selbst. Beide Protokolle sind auf die Architektur des Webs konvergiert: zustandslose Anfragen, Standard-Header, cachebare Antworten, gateway-freundliches Routing. Genau diese Konvergenz erlaubt es, dreißig Jahre HTTP-Betriebswissen — Load Balancing, WAFs, Observability — unverändert auf Agenten-Traffic anzuwenden. Wir lesen die Releases von 2026 so: Die Protokollschicht erklärt ihre Transportfragen für gelöst.

Was als Nächstes kommt, liegt darüber: prüfbare Agentenidentität jenseits signierter Karten, semantische Verträge, die Werkzeugverhalten verifizierbar machen, Mechanismen für Inhaltsvertrauen gegen Injection und irgendwann Abrechnung — wer bezahlt wen für eine delegierte Aufgabe. Nichts davon ist heute standardisiert. Für Engineering-Teams bleibt der praktische Schluss seit den diesjährigen Releases derselbe: Bauen Sie an Systemgrenzen auf MCP und A2A, umhüllen Sie beide mit einer Governance-Schicht unter Ihrer Kontrolle, und behandeln Sie alles oberhalb des Transports als Ihre eigene Verantwortung.