Installiere unsere App 🪄 Klicken Sie auf das Symbol oben rechts in der Adressleiste.
News

Agent-Protokolle 2026: Wie MCP, A2A und offene Standards die KI-Integration für IT-Teams verändern

18 September, 2026 146 Ansichten 4 Minuten lesen

Anthropics Model Context Protocol (MCP) und Googles Agent-to-Agent-Protokoll (A2A) setzen sich als Standards für KI-Agenten-Integrationen durch. Was das für IT-Teams und die Toolchain-Entwicklung bedeutet.

Abstrakte digitale Netzwerkdarstellung – symbolisiert die Verbindung zwischen KI-Agenten über standardisierte Protokolle wie MCP und A2A (Foto: Pexels)
Abstrakte digitale Netzwerkdarstellung – symbolisiert die Verbindung zwischen KI-Agenten über standardisierte Protokolle wie MCP und A2A (Foto: Pexels)

Agent-Protokolle als neue Infrastrukturebene

KI-Agenten sind längst kein Zukunftsthema mehr. In IT-Teams weltweit laufen produktive Agentensysteme, die Code überprüfen, Incidents analysieren, Dokumentation generieren und Routineaufgaben selbstständig erledigen. Doch je mehr Agenten im Einsatz sind, desto deutlicher wird ein strukturelles Problem: Jedes System spricht seine eigene Sprache. Ein Agent, der Tools von Anbieter A nutzen soll, braucht eine andere Integration als einer, der mit Anbieter B kommuniziert. Das Ergebnis sind fragmentierte, schwer wartbare Toolchains.

Genau hier setzen zwei Initiativen an, die 2026 erheblich an Bedeutung gewonnen haben: Anthropics Model Context Protocol (MCP) und Googles Agent-to-Agent-Protokoll (A2A). Beide verfolgen das Ziel, die Kommunikation zwischen KI-Modellen, Agenten und externen Tools zu standardisieren – auf unterschiedliche Weise, aber mit demselben übergeordneten Ziel: Interoperabilität.

Was ist das Model Context Protocol (MCP)?

Das Model Context Protocol wurde von Anthropic entwickelt und 2024 als Open-Source-Standard veröffentlicht. MCP definiert, wie ein KI-Modell mit externen Werkzeugen, Datenquellen und Diensten kommuniziert – ohne dass für jeden Anbieter eine separate Integration gebaut werden muss. Das Prinzip ähnelt dem Language Server Protocol (LSP), das in der IDE-Welt für ähnliche Interoperabilitätsprobleme entwickelt wurde.

Im MCP-Ökosystem gibt es drei Rollen:

  • MCP Hosts: Die KI-Anwendungen, die das Modell ausführen – zum Beispiel Claude, ein eigenes Agentensystem oder eine IDE-Integration.
  • MCP Clients: Komponenten innerhalb des Hosts, die mit MCP-Servern kommunizieren.
  • MCP Server: Dienste, die Tools, Ressourcen und Prompts über ein standardisiertes Interface bereitstellen.

Ein MCP-Server kann beispielsweise den Zugriff auf eine Datenbank, ein Monitoring-System oder ein Git-Repository kapseln. Das KI-Modell muss nicht wissen, wie die Datenbank intern aufgebaut ist – es nutzt das standardisierte MCP-Interface, um Abfragen zu stellen und Ergebnisse zu empfangen.

MCP in der Praxis: Was IT-Teams damit anfangen können

Für IT-Teams bedeutet MCP konkret: Wer einmal einen MCP-Server für ein internes System gebaut hat – etwa für ein Monitoring-Tool, eine CMDB oder ein Ticket-System –, kann diesen mit jeder MCP-kompatiblen KI-Anwendung nutzen. Die Integration muss nicht pro Modell oder pro Tool-Anbieter neu implementiert werden. Das reduziert Wartungsaufwand erheblich und senkt die Einstiegshürde für neue Agenten-Deployments.

Inzwischen gibt es ein wachsendes Ökosystem öffentlicher MCP-Server: für GitHub, Jira, Confluence, PostgreSQL, Kubernetes und viele weitere Systeme. IT-Teams können diese direkt einsetzen oder als Ausgangspunkt für eigene Implementierungen nutzen.

Was ist das Agent-to-Agent-Protokoll (A2A)?

Während MCP die Verbindung zwischen Modell und Tool standardisiert, adressiert Googles A2A eine andere Ebene: die Kommunikation zwischen autonomen Agenten untereinander. In komplexen Agentensystemen gibt es häufig einen Orchestrator, der spezialisierte Subagenten koordiniert – einen für Code-Review, einen für Deployment, einen für Incident-Analyse. Damit diese effizient zusammenarbeiten können, brauchen sie ein gemeinsames Kommunikationsprotokoll.

A2A definiert Mechanismen für:

  • Task-Delegation: Wie ein Agent einer anderen Agenten-Instanz eine Aufgabe übergibt, inklusive Kontext und Anforderungen.
  • Ergebnis-Übergabe: Wie strukturierte Ergebnisse zwischen Agenten weitergegeben werden.
  • Authentifizierung und Autorisierung: Welche Agenten welche Operationen ausführen dürfen.
  • Streaming und asynchrone Kommunikation: Wie Agenten mit längerlaufenden Aufgaben umgehen.

A2A basiert auf HTTP/JSON und ist bewusst einfach gehalten, um eine breite Kompatibilität zu ermöglichen. Google hat das Protokoll gemeinsam mit einer Reihe von Partnern entwickelt und als offenen Standard vorgeschlagen.

MCP und A2A: Ergänzung statt Konkurrenz

Ein häufiges Missverständnis ist, dass MCP und A2A konkurrierende Protokolle seien. In der Praxis adressieren sie unterschiedliche Kommunikationsebenen und ergänzen sich gut. MCP regelt die vertikale Verbindung – Modell zu Tool. A2A regelt die horizontale Verbindung – Agent zu Agent. In einem typischen modernen Agentensystem könnten beide gleichzeitig im Einsatz sein: Ein Orchestrator-Agent kommuniziert über A2A mit spezialisierten Subagenten, die ihrerseits über MCP auf externe Tools zugreifen.

Was das für Sicherheit bedeutet

Standardisierte Protokolle sind nicht nur eine technische Bequemlichkeit. Sie haben direkte Sicherheitsimplikationen. Wenn klar definiert ist, wie Agenten mit Tools kommunizieren und welche Operationen erlaubt sind, lässt sich die Berechtigungsstruktur wesentlich besser kontrollieren. Wildwuchs-Integrationen, die direkt auf interne APIs zugreifen, lassen sich durch MCP-Server ersetzen, die Zugriffe protokollieren und granular einschränken.

IT-Teams sollten MCP-Server nicht als reine Convenience-Schicht betrachten, sondern als Kontrollpunkt: Was der Agent sehen und tun darf, wird explizit im Server definiert. Das ist eine deutliche Verbesserung gegenüber Agenten, die unkontrollierten Zugang zu einer breiten API-Fläche haben.

OpenAI Function Calling und der breitere Standardisierungstrend

Neben MCP und A2A gibt es weitere Ansätze: OpenAIs Function Calling und die neueren Structured Outputs sind de-facto-Standards für die Tool-Nutzung innerhalb einzelner Modelle. Sie sind weniger ein allgemeines Protokoll als ein modellspezifischer Mechanismus – aber viele MCP-Implementierungen nutzen Function Calling intern als Grundlage.

Der übergeordnete Trend ist klar: Die KI-Industrie bewegt sich von proprietären, modellspezifischen Integrationen hin zu offeneren, interoperablen Standards. Das ist für IT-Teams langfristig positiv – weniger Vendor-Lock-in, bessere Kombinierbarkeit verschiedener Modelle und Dienste, klarere Sicherheitsgrenzen.

Praktische Schritte für IT-Teams

Wer jetzt anfangen möchte, die eigene Agenten-Infrastruktur auf solidere Grundlagen zu stellen, kann folgende Schritte gehen:

  • Bestandsaufnahme machen: Welche Tools und Systeme sollen KI-Agenten nutzen? Gibt es bereits MCP-Server dafür, oder müssen eigene gebaut werden?
  • Berechtigungen explizit definieren: Für jeden MCP-Server festlegen, welche Operationen erlaubt sind – Lesezugriff, Schreibzugriff, welche Daten sichtbar sind.
  • Logging von Anfang an einplanen: Jeder Tool-Call eines Agenten sollte protokolliert werden – nicht nur für Debugging, sondern für Audit und Sicherheit.
  • Mit einfachen Anwendungsfällen starten: Ein MCP-Server für ein gut bekanntes internes Tool – etwa das Monitoring-System oder die CMDB – ist ein sinnvoller Einstieg, bevor komplexere Agentensysteme aufgebaut werden.

Fazit

MCP und A2A sind nicht nur technische Details für KI-Entwickler. Sie sind Infrastrukturentscheidungen, die beeinflussen, wie wartbar, sicher und erweiterbar KI-Agentensysteme in IT-Teams langfristig sind. Wer heute in diese Protokolle investiert, baut auf einer Grundlage, die nicht mit dem nächsten Modellwechsel obsolet wird. Das ist in einem Bereich, der sich so schnell verändert wie KI-Tooling, ein erheblicher Vorteil.

Bildquelle: Unsplash / Tara Winstead (ki-visuals)

Quellen

  • Anthropic: Model Context Protocol Dokumentation (modelcontextprotocol.io)
  • Google: Agent-to-Agent Protocol Ankündigung (cloud.google.com)
  • OpenAI: Function Calling Dokumentation (platform.openai.com)
0 von 0 Bewertungen
Teilen

Artikel weitergeben