MCP, WebMCP und A2A: Welches Protokoll für Deine KI-Agenten im Jahr 2026 wählen

Vom Kiwop-Team · Digitalagentur spezialisiert auf Softwareentwicklung und angewandte Künstliche Intelligenz für globale Kunden in Europa und den USA · Veröffentlicht am 19. April 2026 · Zuletzt aktualisiert: 19. April 2026

TL;DR — Stand April 2026 koexistieren drei Schlüsselprotokolle für KI-Agenten. MCP (Model Context Protocol) verbindet einen Agenten mit seinen Werkzeugen und Daten; es ist der De-facto-Standard, der Linux Foundation gespendet. WebMCP ist die Browser-Variante, damit Websites Aktionen an Agenten bereitstellen; weiterhin aufstrebend. A2A (Agent-to-Agent) verbindet Agenten untereinander; v1.0 in Produktion mit 150+ Organisationen. Nutze MCP für Tools, A2A zum Orchestrieren und WebMCP für Deine Website.

Jede Woche erhalten wir dieselbe Frage von Lenkungsausschüssen und Produktteams: "Wir bauen einen KI-Agenten, welches Protokoll sollen wir verwenden?". Die richtige Antwort ist nicht mehr "MCP und Punkt" — sie war es 2025, aber 2026 hat eine Konstellation von Standards gebracht, die sich mehr ergänzen, als dass sie konkurrieren. Das Interessante ist nicht, welches gewinnt: Es ist, welches welches Problem löst.

Dieser Artikel ist der technische Vergleich, der uns vor sechs Monaten Wochen der Recherche erspart hätte. Er basiert auf unserer echten Erfahrung mit dem Bau von persönlichen Assistenten mit Claude Code und MCP, auf der internen Arbeit an Nexo (unser in Entwicklung befindlicher Workspace-SaaS) und auf den jüngsten offiziellen Quellen, die von Anthropic, Google, Cloudflare, Vercel, der Linux Foundation und dem W3C selbst veröffentlicht wurden. Wenn Du eine binäre Antwort suchst, wirst Du sie hier nicht haben. Wenn Du ein Entscheidungskriterium suchst, lies weiter.

Warum 2026 das Jahr der Protokolle für KI-Agenten ist

2023 war das Jahr des Prompts. 2024 war das Jahr des Werkzeugs (tool use). 2025 war das Jahr des Agenten. Und 2026 ist ohne Zweifel das Jahr der Protokolle. Der Grund ist einfach: Wenn es einen einzigen Agenten gibt, der mit einer einzigen API spricht, funktioniert jeder Ad-hoc-Vertrag. Wenn Du Dutzende Agenten, Dutzende Modelle verschiedener Anbieter, hunderte interne und externe Werkzeuge und Kunden hast, die ihre eigenen Agenten mit Deinen verbinden wollen, verschlingt das Chaos das Produkt.

Die Explosion war brutal. Anthropic meldet mehr als 10.000 öffentliche aktive MCP-Server und 97 Millionen monatliche SDK-Downloads zwischen Python und TypeScript laut dem offiziellen Hinweis zur Spende von MCP an die Linux Foundation. A2A seinerseits ging von einem Google-Vorschlag im April 2025 dazu über, mehr als 150 Organisationen zu zählen und sich Anfang 2026 unter dem Schirm der Linux Foundation zu befinden. Am 9. Dezember 2025 wurde die Agentic AI Foundation (AAIF) unter der Linux Foundation formalisiert, mit Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare und Bloomberg als Platinum-Mitgliedern — ein von TechCrunch abgedeckter Schritt, der das Ende der Ära proprietärer Protokolle markiert.

Das Bild zum April 2026 sieht so aus. Es gibt drei Protokolle, die jedes technische Team verstehen muss: MCP, WebMCP und A2A. Es gibt ein viertes, ACP (Agent Communication Protocol) von IBM, das sich konzeptionell mit A2A überschneidet und dessen Adoption heute deutlich geringer ist. Und es gibt eine Fülle angrenzender Initiativen — AGENTS.md, Open Responses, ANP, LLMFeed — die umkreisen, ohne bisher dieselbe kritische Masse zu erreichen. Wir konzentrieren uns auf die drei, die für echte Architekturentscheidungen wichtig sind.

Die Fragmentierung ist ein echtes Problem. Wie in der akademischen Studie von arXiv über Agenten-Interoperabilitätsprotokolle aufgezeigt, löst jedes Protokoll eine andere Schicht des Stacks: Das Problem ist nicht, eines zu wählen, sondern zu verstehen, in welcher Schicht jedes operiert, und sie zu kombinieren, ohne unnötige Kopplungen zu schaffen. Das ist die These, die wir entwickeln werden.

MCP — Model Context Protocol (Anthropic, 2024)

MCP ist Stand April 2026 der De-facto-Standard für die Verbindung eines KI-Agenten mit externen Werkzeugen. Es wurde von Anthropic im November 2024 als offenes Protokoll veröffentlicht, und in seinem ersten Jahr hat es den Weg zurückgelegt, den andere Standards ein Jahrzehnt gebraucht haben: vom individuellen Vorschlag zur gemeinsamen Infrastruktur der Industrie.

Was MCP konzeptionell ist

MCP definiert einen Vertrag zwischen zwei Parteien: einem MCP Client (im Allgemeinen der Agent oder der Host des Modells) und einem MCP Server (im Allgemeinen ein Adapter zu einem externen Dienst: Gmail, GitHub, einer Datenbank, einem internen System). Der Client entdeckt, welche Werkzeuge der Server anbietet, liest sein Schema und ruft sie mit typisierten Parametern auf. Die Kommunikation verwendet JSON-RPC 2.0 über einen Transport.

Das Protokoll deckt nicht nur Werkzeuge (tools) ab: Es definiert auch resources (statisch lesbarer Inhalt wie Dateien oder Datensätze), prompts (wiederverwendbare Templates) und — seit der Spezifikation vom 25. November 2025 — asynchrone Operationen, stateless servers, server identity und offizielle Erweiterungen laut der offiziellen Spezifikation. Diese Evolution hat es MCP ermöglicht, von "einen lokalen Client verbinden" zu "Agenten-Infrastruktur in Produktion versorgen" überzugehen.

Transporte: stdio und Streamable HTTP

MCP unterstützt zwei offizielle Transporte laut der Transport-Dokumentation der Spec:

• stdio: Der Client startet den Server als lokalen Subprozess und kommuniziert über Standard-Eingabe/Ausgabe. Ideal für lokale Ausführungen, CLI und persönliche Assistenten.
• Streamable HTTP: Der Server lebt als unabhängiger Prozess und stellt einen einzigen HTTP-Endpoint bereit, der POST und GET akzeptiert. Kann Server-Sent Events für Streaming verwenden. Es ist der De-facto-Standard für Remote-Server in 2026 und ersetzt den alten HTTP+SSE-Transport.

Die schnelle Regel: stdio für persönliche Assistenten auf einer Maschine, Streamable HTTP für gemeinsam genutzte Dienste in Produktion.

Verfügbare Server und Ökosystem

Stand April 2026 deckt das MCP-Ökosystem praktisch jeden relevanten Unternehmensdienst ab: Gmail, Google Calendar, Google Drive, Slack, Linear, GitHub, Notion, Jira, Confluence, Salesforce, HubSpot, Stripe, PostgreSQL, Snowflake, BigQuery und Dutzende mehr. Die Adoption überschreitet Anbietergrenzen: OpenAI hat es im März 2025 nativ in ChatGPT unterstützt, Microsoft hat es in Copilot integriert, Google unterstützt es in Gemini, und Editoren wie Cursor, Windsurf und VS Code sprechen nativ MCP.

Optimale Use Cases

MCP glänzt, wenn es einen Agenten gibt, der Zugriff auf viele heterogene Quellen braucht: ein persönlicher Assistent, der Deine E-Mails und Deinen Kalender liest, ein Entwicklungs-Copilot, der Deinen Code und Deine Tickets konsultiert, ein Verkaufsagent, der Daten aus CRM und Fakturierung kreuzt. In all diesen Fällen ist das Muster dasselbe: Der Agent ruft typisierte Werkzeuge auf Servern auf, die mit konkreten Systemen sprechen.

Grenzen

MCP ist nicht das richtige Werkzeug, wenn der Verkehr Agent↔Agent ist (dort kommt A2A ins Spiel), wenn der Konsument ein Browser ist und kein Prozess mit vorinstallierten OAuth-Credentials (dort kommt WebMCP ins Spiel), noch wenn die Operation massive Binärstreams oder Latenzen im Submilliseconden-Bereich erfordert (dort kommen spezifische APIs ins Spiel). Und obwohl die Adoption enorm ist, bleibt die Sicherheit ein aktiver Arbeitsbereich: Es gibt wachsende Literatur über Tool Poisoning, Prompt Injection über Werkzeugbeschreibungen und schwer auditierbare Berechtigungen. Jeder MCP-Agent in Produktion braucht eine Sandboxing- und Bestätigungsschicht, die das Protokoll selbst nicht vorschreibt.

WebMCP — das MCP für die Web (2025-2026)

WebMCP ist die Wette von Google und Microsoft, die MCP-Philosophie in den Browser und die Web selbst zu übertragen. Es ist keine Erweiterung von MCP: Es ist ein paralleler Standard, koordiniert innerhalb der W3C Web Machine Learning Community Group, die den Client-Server-Vertrag an die spezifische Umgebung des Browsers anpasst. Wir haben den ursprünglichen Vorschlag bereits in WebMCP: Deine Website bereit für KI-Agenten behandelt; hier konzentrieren wir uns darauf, wie es sich gegenüber MCP und A2A positioniert.

Warum WebMCP und nicht einfach MCP über HTTP

A priori klingt es redundant: Wenn MCP bereits Streamable HTTP Transport hat, wozu ein anderer Standard? Das WebMCP-Ökosystem ist Stand April 2026 in Early Preview, aber der Existenzgrund geht über die Unreife hinaus. Die technische Antwort ist, dass der Browser eine radikal andere Umgebung als ein Server ist. Im Browser:

• Die Authentifizierung verwaltet der Nutzer, nicht der Agent (das Session-Cookie lebt im Browser, es reist nicht mit dem Agenten).
• Die Aktionen müssen vom Menschen sichtbar und überwachbar sein (es gibt keinen Platz für opake Automatisierungen).
• Die exponierte Oberfläche ist die der besuchten Website, nicht ein dedizierter Endpoint.
• Die Entdeckbarkeit geschieht, wenn der Nutzer die Seite navigiert, nicht über ein globales Verzeichnis.

WebMCP löst genau diese Unterschiede. Laut der offiziellen Cloudflare-Browser-Run-Dokumentation über WebMCP stellt die Website eine Reihe von Tools bereit — zum Beispiel searchFlights() oder bookTicket() — mit typisierten Parametern. Ein Agent, der die Seite navigiert, kann diese Tools entdecken, ihre Schemata lesen und sie direkt aufrufen, ohne Klicks zu simulieren oder das DOM zu scrapen.

Implementierung: Cloudflare und Vercel

Die beiden Anbieter, die am schnellsten gezogen haben, sind Cloudflare und Vercel, wenn auch mit unterschiedlichen Ansätzen.

• Cloudflare hat am 15. April 2026 WebMCP-Unterstützung zu seinem Produkt Browser Run (vormals Browser Rendering) hinzugefügt, laut seinem offiziellen Changelog. Die Integration erlaubt einem KI-Agenten, seinen MCP Client gegen Browser Run über den CDP-Endpoint zu verbinden und Tools zu entdecken, die von jeder Website bereitgestellt werden, die WebMCP implementiert — selbst wenn diese Seite die Infrastruktur nicht kontrolliert.
• Vercel hat sein Produkt auf das Deployment von MCP-Servern über seine Functions-Plattform ausgerichtet und nutzt Fluid Compute zur Optimierung unregelmäßiger Nutzungsmuster typisch für Agenten. Die offizielle Dokumentation von Vercel MCP beschreibt, wie man Streamable-HTTP-Endpoints mit integriertem OAuth aufsetzt, und sein AI SDK enthält einen experimentellen MCP Client. Obwohl Vercel mehr klassisches MCP als reines WebMCP ist, ist es der Referenzanbieter, wenn Dein Backend bereits in Next.js lebt.

Optimale Use Cases

WebMCP ist die richtige Antwort, wenn Dein Produkt eine öffentliche Website ist und Du möchtest, dass KI-Agenten sie gut nutzen: E-Commerce (Suche, Filter, Warenkorb, Checkout), SaaS mit komplexen Formularen (Konfiguratoren, Angebote), Marktplätze, Reservierungssysteme. Jeder Fall, in dem ein menschlicher Nutzer Buttons und Formulare verwenden würde und Du möchtest, dass ein Agent dasselbe mit weniger Reibung tut.

Adoptionsstand zum April 2026

Hier muss man ehrlich sein: WebMCP ist aufstrebend, nicht reif. Chrome unterstützt es experimentell in Canary, Cloudflare hat teilweise Produktion, und die Berichterstattung von AB Magency über den "Krieg der Agentic-Formate" hält fest, dass WebMCP gleichzeitig mit Vorschlägen wie Markdown for Agents von Cloudflare (gestartet am 12. Februar 2026) konkurriert. Beide koexistieren; keiner hat gewonnen. Für ein Team, das heute entscheiden muss, ist WebMCP eine vernünftige Zukunftswette für Seiten mit vorhersehbarem Agentenverkehr, aber kein Standard, auf den man die gesamte Architektur setzen sollte.

A2A — Agent-to-Agent protocol (2026)

Wenn MCP einen Agenten mit seinen Werkzeugen verbindet, verbindet A2A Agenten untereinander und ist Stand April 2026 der horizontale Referenzstandard. Es ist der Unterschied zwischen "ein Arbeiter nutzt seine Werkzeuge" und "ein Arbeiter delegiert Aufgabe an einen anderen Arbeiter". Es ist keine akademische Unterscheidung: Es löst echte Probleme, die MCP nicht lösen kann.

Ursprung und aktueller Stand

A2A wurde von Google auf der Google Cloud Next 2025 am 9. April 2025 angekündigt, mit mehr als 50 Launch-Partnern (Accenture, Atlassian, Box, Cohere, Deloitte, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UiPath, unter anderem). Im Juni 2025 hat Google es an die Linux Foundation gespendet. Im März 2026 wurde A2A v1.0 veröffentlicht, die Version, die die Community als produktionstauglich betrachtet. Die offizielle Dokumentation auf a2a-protocol.org beschreibt das Modell im Detail; die Upgrade-Ankündigung des Google Cloud Blogs dokumentiert die Verbesserungen von v1.0.

Architektur: Agent Cards und Discovery

Das zentrale Konzept von A2A ist die Agent Card: ein JSON-Dokument, das beschreibt, was ein Agent kann, welche Skills er bereitstellt, welche Authentifizierung er benötigt und wo er zu kontaktieren ist. Agenten entdecken sich, indem sie die Agent Cards anderer Agenten lesen, genauso wie Webdienste über OpenAPI entdeckt werden. In v1.0 tragen die Agent Cards kryptografische Signatur (Signed Agent Cards), was es ermöglicht zu verifizieren, dass eine Card von der Eigentümer-Domäne des Agenten ausgestellt wurde — eine wichtige Verbesserung gegen Impersonation.

Der Transport ist JSON-RPC 2.0 über HTTP, Server-Sent Events oder gRPC, mit Authentifizierung über API Keys, HTTP Auth, OAuth 2.0/OIDC und Mutual TLS. Das heißt: dieselben Teile, die jedes Enterprise-Backend seit einem Jahrzehnt nutzt, ohne etwas neu zu erfinden.

Optimale Use Cases

A2A ist die richtige Antwort, wenn mehrere spezialisierte Agenten zusammenarbeiten müssen: ein Orchestrator-Agent, der "einen Flug suchen" an einen Reise-Agenten delegiert, "ein Hotel reservieren" an einen Hotel-Agenten und "bezahlen" an einen Payment-Agenten. Jeder spezialisierte Agent hat seine eigenen Werkzeuge (intern MCP) und bietet seine Agent Card nach außen an, um orchestriert zu werden. Typische Szenarien: Purchasing Concierges mit mehreren Anbietern, Multi-Abteilungs-Workflows in großen Unternehmen, Marktplätze von Agenten.

Fundamentaler Unterschied zu MCP

Der Schlüssel, gut zusammengefasst von IBM in seinem Artikel über A2A, ist, dass MCP vertikal (Agent↔Tool) und A2A horizontal (Agent↔Agent) ist. Beide sind komplementär. Ein A2A-Agent kann intern MCP nutzen, um auf seine Daten zuzugreifen. Ein MCP-Agent benötigt A2A möglicherweise nie, wenn er ein einzelner Agent ist. Die Entscheidung ist nicht "MCP oder A2A"; sie ist "ich brauche eines, das andere oder beide".

Grenzen und Reife

A2A v1.0 ist neu. Obwohl es Produktionsbereitstellungen bei Microsoft, AWS, Salesforce, SAP und ServiceNow laut der Stellagent-Berichterstattung gibt, ist das Ökosystem interoperabler Agenten immer noch klein im Vergleich zu dem der MCP-Werkzeuge. Heute mit A2A zu bauen bedeutet, viele Teile zu bauen, die MCP bereits reif hat: Bibliotheken, Gateways, Debugger, Observability. Wenn Dein Problem "ein Agent mit vielen Tools" ist, fügt A2A Komplexität hinzu, ohne etwas Neues zu lösen.

Vergleichstabelle: MCP vs WebMCP vs A2A

Die Tabelle ist absichtlich dicht. Wenn wir sie in einem Satz zusammenfassen müssten: MCP herrscht innerhalb des Agenten, A2A herrscht zwischen Agenten, WebMCP herrscht im Browser. Jede architektonische Entscheidung beginnt damit, zu identifizieren, wo Du bist, und von dort zu arbeiten.

Reales Beispiel 1: Der PA von Kiwop nutzt MCP stdio

Unser PA (Personal Assistant) — der persönliche KI-Assistent, den wir bei Kiwop nach der OAuth-Abschaltung von Anthropic am 4. April 2026 gebaut haben, im Detail dokumentiert in Von OpenClaw zu PA mit Claude Code und MCP — ist ein Schulbeispiel für die optimale Nutzung von MCP stdio.

Die Architektur in einem Satz

Claude Code läuft auf einer lokalen Maschine (macOS, mit launchd als Prozessmanager). Er benötigt Zugriff auf Gmail, Google Calendar, Google Drive und Slack. Für jeden dieser vier Dienste haben wir einen lokalen MCP-Server, der als Subprozess der Sitzung gestartet wird. Der in Claude Code eingebettete MCP Client startet die Server per stdio, entdeckt ihre Tools und ruft sie bei Bedarf auf.

Warum stdio und nicht Streamable HTTP

Die Versuchung war, die MCP Server auf einem HTTP-Endpoint bereitzustellen und Claude Code sich über das Netzwerk verbinden zu lassen. Wir haben das aus drei Gründen verworfen:

1. Credentials: Die OAuth-Tokens von Gmail, Calendar, Drive und Slack leben im macOS-Keychain. Diese Tokens über das Netzwerk bereitzustellen würde Tunneling, Rotation und ein Secret-Modell implizieren, das wir nicht wollten.
2. Latenz: stdio ist lokaler Prozess mit UNIX-Pipe. Jeder Aufruf ist submilliseconden. Ein HTTP-Endpoint fügt Netzwerkzeit ohne funktionalen Gewinn hinzu.
3. Operative Einfachheit: An dem Tag, an dem etwas kaputtgeht, ist das Inspizieren eines lokalen Prozesses unendlich einfacher als das Debuggen eines Remote-Dienstes.

Die Entscheidung passt zu der allgemeinen Logik, die wir in LLMOps: Sprachmodelle in der Produktion verwalten beschreiben — nah zu halten, was nah sein kann, reduziert Fehleroberfläche. Das ist die Philosophie, die wir auch im nächsten Post über Muster und Antimuster von KI-Agenten in Produktion widerspiegeln werden.

Was wir NICHT berührt haben

Weder WebMCP noch A2A. Der PA ist ein einzelner Agent (Claude Code) mit vielen Werkzeugen, betrieben von einer einzigen Person. A2A einzuführen wäre reines Over-Engineering: Es gibt keinen anderen Agenten, mit dem man sich koordinieren müsste. WebMCP einzuführen trifft nicht zu: Es gibt keinen Browser dazwischen, und die MCP-Dienste decken bereits alles ab, was wir brauchen.

Das ist wichtig: Ein gutes Design ist so wertvoll für das, was es ausschließt, wie für das, was es einschließt. Jedes hinzugefügte Protokoll ist zu wartender Code, Angriffsfläche und Abhängigkeit von Anbieter-Policies.

Reales Beispiel 2: Nexo (unser SaaS) plant WebMCP für Kunden

Nexo ist der interne SaaS, den wir bei Kiwop bauen — ein kollaborativer Workspace mit integrierten Agentenfähigkeiten. Ohne auf Produktdetails einzugehen (er wird später offiziell gelauncht), können wir die architektonische Entscheidung über Protokolle erzählen, weil sie perfekt das Dilemma illustriert, dem die meisten SaaS in den nächsten 12-18 Monaten gegenüberstehen werden.

Das Problem: Kunden, die ihre eigenen Agenten verbinden wollen

Die Beta-Kunden fragten uns zwei sehr unterschiedliche Dinge:

1. "Wir möchten, dass unsere eigenen Agenten (Claude, GPT, interne Kundenagenten) auf die Daten ihres Workspace in Nexo zugreifen."
2. "Wir möchten, dass Eure internen Agenten in Nexo mit den Agenten kollaborieren können, die mein Unternehmen bereits hat."

Das sind zwei völlig unterschiedliche Protokollprobleme.

Entscheidung: WebMCP (und Remote-MCP) für das erste, A2A für das zweite

Für das erste Problem (Kunden, die externe Agenten mit ihren Daten in Nexo verbinden) haben wir entschieden, einen Streamable-HTTP-MCP-Server pro Tenant bereitzustellen und parallel WebMCP-Endpoints vorzubereiten, damit, wenn Nutzer die Nexo-UI von einem Browser mit Agenten aus navigieren, dieser Agent die verfügbaren Aktionen entdecken kann, ohne das DOM zu scrapen. Die bereitgestellten Tools sind in beiden Transporten dieselben; es ändert sich, wer sie konsumiert und wie sie sich authentifizieren. Es passt zu dem, was wir Kunden bereits in unserem Dienst für die LLM-Integration empfehlen.

Für das zweite Problem (Orchestrierung von Kundenagenten mit unseren Agenten) setzen wir auf A2A. Wir werden signierte Agent Cards für jede interne Capability veröffentlichen (classify-document, summarize-meeting, draft-email), der Kunde kann sie von seinem Orchestrator-Agenten aus entdecken, und der Verkehr wird JSON-RPC über HTTP mit OAuth 2.0 sein. Der entscheidende Vorteil von A2A gegenüber "ich mache eine weitere REST-API" ist, dass der Kunde unsere API nicht lernen muss: Sein Agent entdeckt, liest die Card und operiert.

Was wir NICHT gewählt haben und warum

Wir haben alles auf reinem MCP zu bauen verworfen, obwohl es technisch möglich ist. Der Grund ist, dass MCP für Agent↔Tool optimiert ist: Wenn ein Kunde mit einem eigenen Agenten an Nexo delegieren und komplexe Ergebnisse (multi-step, mit Zwischenzuständen, mit exponierten Reasonings) erhalten möchte, passt A2A besser. MCP ist nicht für Agent↔Agent-Konversationen mit geteiltem Gedächtnis gedacht.

Wir haben auch mit A2A für alles zu beginnen verworfen, da für den Fall "Kunde, der Workspace-Daten mit Claude lesen/schreiben möchte" ein MCP-Server die kurze und Standard-Route ist, mit dem größten Ökosystem von Clients dahinter.

Die umfassendere Lektion für jeden SaaS, der überlegt, wie er sich für Agenten öffnet: Es ist keine binäre Entscheidung, es ist eine Entscheidung pro Use Case. Daten an einen einzelnen Kundenagenten bereitstellen → Remote-MCP. Eine öffentliche Website für Agenten bereitstellen, die sie besuchen → WebMCP. Mit Kundenagenten als Gleichgestellte interoperieren → A2A.

Wann MCP NICHT verwenden (weder WebMCP noch A2A)

Ein Kapitel, das in vielen Artikeln fehlt. Agentenprotokolle sind sehr gut für ihr Gebiet und sehr schlecht außerhalb davon. Einige Signale, dass Du weder MCP, WebMCP noch A2A in Deine Architektur aufnehmen solltest:

• Extreme Latenz. Wenn die Operation submillisecond-Antwort erfordert (Hochfrequenzhandel, Industriesteuerung, Videospiele), töten der Overhead von JSON-RPC, der Handshake, die Tool-Beschreibung und der Roundtrip des Modells jedes Agentenprotokoll. Verwende spezifische binäre APIs.
• Massive Binärstreams. Videotranskodierung, Massenbildverarbeitung, Audio-Streaming in Echtzeit. MCP kann den Job aufrufen, aber es ist nicht der Kanal, über den die Bytes reisen. Behalte Deine spezifischen Pipelines.
• Lange Batch-Prozesse ohne Agent. Wenn Dein Fall "Cronjob verarbeitet jede Nacht eine CSV" ist, ist ein KI-Agent mit MCP Artillerie gegen Spatzen. Ein Skript und ein Scheduler sind weiterhin die richtige Antwort.
• Strikter Determinismus. Bankoperationen, kritische Transaktionen, Audit-Logs. Ein Agent mit Tools kann im Loop bleiben, aber der Transaktionsmotor muss deterministisch sein, mit dokumentierten Retries und ohne Spielraum für "das Modell hat ein anderes Tool gewählt".
• Reguliertes Compliance mit umfassendem Audit. Wenn jeder Call eine rechtlich reproduzierbare Spur hinterlassen muss, brauchst Du eine Schicht unterhalb der Agentenprotokolle — nicht darüber — die diese Aufzeichnung garantiert. Es ist machbar, aber einen KI-Agenten hinzuzufügen vereinfacht das Compliance nicht; es verkompliziert es.

Verwandt: In regulierten Sektoren (Gesundheit, Recht, Finanzen) erfordert jede Agentenarchitektur eine Phase der Beratung für Künstliche Intelligenz, um zu verstehen, was erlaubt ist, bevor man ein Protokoll wählt. Ein Protokoll zu wählen, ohne dort durchzugehen, ist das klassische Antimuster.

Interoperabilität: Kannst Du die drei kombinieren?

Ja, und in der Tat ist es wahrscheinlich, dass Du es tust. Das sauberste Muster im April 2026 kombiniert die drei Protokolle in einem kohärenten Stack.

Das konzeptionelle Diagramm:

1. Ein Orchestrator-Agent (höchste Ebene, spricht A2A nach außen).
2. Wenn er ein internes Werkzeug verwenden muss (eine Datenbank lesen, eine Unternehmens-API aufrufen) → MCP.
3. Wenn er eine komplexe Subtask delegieren muss an einen anderen spezialisierten Agenten → A2A zu diesem Agenten.
4. Wenn er auf einer externen Website handeln muss, die keine eigene API bereitstellt, aber WebMCP → WebMCP Client über Browser.

Der Empfangsagent in A2A nutzt intern wiederum MCP für seine eigenen Tools. Und wenn der Empfangsagent ein öffentlicher SaaS mit Frontend ist, stellt er wahrscheinlich auch eine WebMCP-Oberfläche für menschliche Nutzer mit Agenten bereit. Das System ist rekursiv und komponierbar: Jeder Agent ist ein Client der drei Protokolle und (potenziell) ein Server von zwei (MCP und A2A).

Diese Komposition ist genau das, was Quellen wie die Protokoll-Karte von Digital Applied oder der WorkOS-Leitfaden über MCP/ACP/A2A beschreiben: Die Protokolle konkurrieren nicht, weil sie unterschiedliche Schichten lösen. Sie konkurrieren mit ihren Alternativen in derselben Schicht (WebMCP vs Markdown for Agents; A2A vs ACP), nicht untereinander.

Eine Nuance: Vermeide Über-Orchestrierung

Bevor Du die drei Protokolle in ein System einfügst, frag Dich, ob Du sie brauchst. Die Mehrheit der KI-Anwendungen in Produktion braucht heute nur MCP. Eine große Minderheit braucht MCP + WebMCP (SaaS mit öffentlichem Frontend). Eine kleine, aber wachsende Minderheit braucht MCP + A2A (Multi-Agenten-Ökosysteme). Der Dreifachfall ist real, aber selten. Wenn Du nicht rechtfertigen kannst, warum jede Schicht ein unterschiedliches Problem löst, ist wahrscheinlich eine überflüssig.

Tabelle: Wann was verwenden

Tabelle: Adoptionsreife zum April 2026

Roadmap und Adoption in 2026

Was in welcher Phase laut offizieller Quellen Stand April 2026 ist:

• MCP: Stabile Spezifikation vom 25. November 2025 mit asynchronen Operationen und stateless servers; nächster relevanter Meilenstein, der MCP Dev Summit Europe, angekündigt für 17.-18. September 2026 in Amsterdam. Zu beobachtende Signale: Konsolidierung des Streamable-HTTP-Transports als Remote-Standard, progressive Einstellung des Legacy-SSE, Standardisierung von Sicherheitsmustern für Tool Poisoning.
• A2A: v1.0 veröffentlicht im März 2026 mit Signed Agent Cards und formaler AP2-Erweiterung. Zu beobachtende Signale: Wachstum des öffentlichen Agent-Cards-Registers, Erscheinen von A2A-Gateways (Äquivalente zu traditionellen API-Gateways), native Integration mit den großen Orchestratoren (LangGraph, CrewAI, AutoGen).
• WebMCP: Early-Preview-Programm offen, teilweise Implementierung in Cloudflare, begrenzte Unterstützung in Chrome Canary. Zu beobachtende Signale: Annahme des Entwurfs im W3C, Entscheidung von Chromium Stable über standardmäßige Unterstützung, definitive Positionierung gegenüber Markdown for Agents.
• Angrenzende Standards: AGENTS.md (von OpenAI vorgeschlagen, unter AAIF), Open Responses (offene OpenAI-Spezifikation für interoperable Agenten-Loops, im Februar 2026 von InfoQ berichtet) und Skills (beigesteuert von Block/Anthropic). Keiner konkurriert direkt mit MCP/WebMCP/A2A, sondern löst komplementäre Teile: Repo-Beschreibung, Loop-Interoperabilität, Prompt-Bundling.

Die am wenigsten riskante Vorhersage für die nächsten 6-12 Monate ist, dass MCP sich als Commodity konsolidiert, A2A seine erste große Welle von B2B-Bereitstellungen erreicht und WebMCP weiterhin umkämpftes Terrain bleibt, bis Chrome Stable entscheidet, ob es unterstützt wird oder nicht. Im Falle einer Nichtunterstützung kann der Vorschlag sterben oder zu einer alternativen Lösung migrieren (Markdown for Agents oder andere).

Häufig gestellte Fragen

Gehört MCP nur Anthropic?

Seit Dezember 2025 nicht mehr. Anthropic hat MCP an die neu geschaffene Agentic AI Foundation unter der Linux Foundation gespendet, mit Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare und Bloomberg als Platinum-Mitgliedern. Heute ist MCP Community-Governance. Anthropic trägt weiterhin stark zur Entwicklung bei, aber ist nicht mehr der einzige Entscheider.

Ersetzt WebMCP meine REST-API?

Nein. WebMCP stellt eine Oberfläche bereit, die für Agenten gedacht ist, die aus Browsern heraus operieren. Deine REST-API bleibt der richtige Weg für Backend-Backend-Integrationen, mobile Apps und mit eigenen Credentials authentifizierte Clients. WebMCP fügt eine auf den Agenten des Nutzers ausgerichtete Schicht hinzu, ersetzt sie aber nicht.

Ist A2A zum April 2026 produktionsbereit?

Ja für Standardfälle. Die v1.0, veröffentlicht im März 2026, enthält Signed Agent Cards und gilt als produktionstauglich. Es gibt Bereitstellungen bei Microsoft, AWS, Salesforce, SAP und ServiceNow. Allerdings ist das Bibliotheks- und Tooling-Ökosystem weniger reif als das von MCP — erwarte, mehr eigene Engineering-Arbeit für Gateways, Observability und Agent-Cards-Management aufzuwenden.

Welches SDK verwenden, um mit MCP zu beginnen?

Die offiziellen SDKs in Python und TypeScript decken die meisten Fälle ab. Zum Bau von Servern im Anthropic-Ökosystem ist das offizielle TypeScript-SDK die empfohlene Route. Für Scripting und lokale Server ist das Python-SDK der Standard. Beide werden von Anthropic mit offiziellem Support gepflegt.

Kann ich MCP mit Modellen verwenden, die nicht von Anthropic sind?

Ja. Seit März 2025 unterstützt ChatGPT MCP nativ; Copilot und Gemini auch. Die MCP-Server sind modell-agnostisch: Jeder Client, der das Protokoll spricht, kann sie konsumieren. Das ist der Hauptgrund, warum MCP gewonnen hat — die Portabilität zwischen Anbietern ist real, kein Marketing.

Ist WebMCP dasselbe wie Markdown for Agents von Cloudflare?

Nein. Es sind zwei konkurrierende Vorschläge mit unterschiedlichen Philosophien. WebMCP stellt typisierte Aktionen bereit, die der Agent aufruft; Markdown for Agents stellt eine strukturierte Markdown-Darstellung der Seite bereit, damit der Agent sie interpretiert. Stand April 2026 koexistieren beide und keiner hat gewonnen. Wenn Du beide Flanken abdecken möchtest, dokumentiert Cloudflare, wie man parallele Unterstützung implementiert.

Was ist der echte Unterschied zwischen A2A und ACP?

Konzeptionell lösen sie dasselbe Problem: horizontale Kommunikation zwischen Agenten. A2A wird von Google vorangetrieben und hat viel mehr Zugkraft (150+ Organisationen, Linux Foundation, v1.0 Produktion). ACP wird von IBM (BeeAI) mit begrenzterer Adoption vorangetrieben. Technisch verwendet ACP direktere HTTP-Konventionen; A2A verwendet JSON-RPC mit signierten Agent Cards. Wenn Du heute bei null anfängst, hat A2A ein besseres Wert-/Risiko-Verhältnis durch das Ökosystem.

Brauche ich die drei Protokolle in meinem Projekt?

Fast nie. Die meisten Projekte beginnen nur mit MCP. Ein SaaS mit öffentlichem Frontend fügt WebMCP hinzu, wenn der Agenten-Verkehr die Investition rechtfertigt. Ein Ökosystem mit mehreren interoperierenden Agenten fügt A2A hinzu. Der häufige Fehler ist, die drei ab Tag eins ohne klaren Business Case aufzunehmen; das gesunde Muster ist, mit MCP zu beginnen und den Rest nur hinzuzufügen, wenn es ein echtes Problem gibt, das zu lösen ist.

Fazit: Wähle nach Schicht, nicht nach Marke

Die richtige Frage in 2026 ist nicht "welches Protokoll ist besser?", sondern "welche Schicht löse ich?". MCP herrscht innerhalb des Agenten, im Bindeglied Agent↔Tool. A2A herrscht zwischen Agenten, im horizontalen Bindeglied. WebMCP herrscht an der Grenze zwischen Deiner öffentlichen Website und den Agenten, die sie besuchen. Es sind drei verschiedene Schichten; sie konkurrieren nicht, sie komponieren sich.

Die operative Lektion nach dem Bau des PA auf MCP stdio und dem Design von Nexo auf Remote-MCP + A2A + WebMCP ist, dass die Kosten einer falschen Protokollwahl enorm sind. Jedes Protokoll bringt ein mentales Modell, eine Reihe von Bibliotheken, eine Kunden-Adoptionskurve und eine langfristige Wartungsverpflichtung mit sich. Aber es ist auch wahr — und das ist vielleicht das Wichtigste — dass die Portabilität zwischen Schichten nie größer war. Ein gut konzipierter MCP-Server wird ohne Änderungen von Claude, ChatGPT, Copilot, Gemini und Cursor konsumiert. Ein gut konzipierter A2A-Agent ist für jeden Orchestrator sichtbar, der das Protokoll spricht. Eine Website mit WebMCP antwortet jedem Agenten, der sie besucht. Die Investition in offene Protokolle amortisiert sich schnell.

Bei Kiwop — Digitalagentur spezialisiert auf Softwareentwicklung und angewandte Künstliche Intelligenz für globale Kunden in Europa und den USA — bauen wir seit zwei Jahren auf LLMs in Produktion und seit Anfang 2025 auf MCP. Wenn Dein Team heute entscheidet, wie Ihr Eure Plattform für KI-Agenten öffnet oder wie Ihr ein Multi-Agenten-System orchestriert, können wir Euch helfen, die richtige Architektur ohne Over-Engineering zu wählen. Wirf einen Blick auf unsere Dienstleistungen zur Entwicklung von KI-Agenten, Beratung für Künstliche Intelligenz und LLM-Integration — oder schreib uns und wir setzen uns zusammen.

Und wenn Dich die technische Reise interessiert hat, folge dem Faden mit den anderen Posts des Clusters: Von OpenClaw zu PA mit Claude Code und MCP, Baue Deinen PA mit Claude Code und MCP, KI-Agenten in Produktion: Muster und Antimuster 2026 und WebMCP: Deine Website bereit für KI-Agenten.