Stellen Sie sich einen neuen Mitarbeiter in einem großen Unternehmen vor. Er ist klug und lernt schnell. Doch damit er wirklich nützlich wird, braucht er drei Dinge: Zugang zu Werkzeugen und Akten, die Möglichkeit, mit Kolleginnen und Kollegen zu sprechen, und einen Weg, seine Ergebnisse verständlich zu präsentieren. Genau vor dieser Herausforderung stehen heute KI-Agenten.

Für jede dieser Aufgaben hat sich inzwischen ein eigenes Protokoll etabliert: MCP, A2A, AG-UI und A2UI. In diesem Artikel gehen wir die vier Protokolle Schritt für Schritt durch. Sie benötigen dafür keine Vorkenntnisse, nur ein wenig Neugier.

Warum KI-Agenten gemeinsame Protokolle brauchen

Ein Sprachmodell wurde mit Daten aus einem bestimmten Zeitraum trainiert. Es ist gewissermaßen ein Lexikon, das an einem bestimmten Tag gedruckt wurde. Fragen Sie nach dem heutigen Wetter oder nach Ihren eigenen Firmendaten, muss das Modell auf externe Quellen zugreifen. Ohne gemeinsame Regeln müsste jede Verbindung einzeln "verkabelt" werden. Protokolle schaffen hier Ordnung, ähnlich wie genormte Steckdosen dafür sorgen, dass jedes Gerät in jede Dose passt.

Das Gesamtbild: Backend und Frontend

Die vier Protokolle lassen sich übersichtlich in zwei Gruppen einteilen:

• Backend-Protokolle: MCP verbindet einen Agenten mit Werkzeugen und Daten. A2A verbindet Agenten untereinander.
• Frontend-Protokolle: AG-UI überträgt den Zustand eines Agenten in Echtzeit an die Benutzeroberfläche. A2UI ermöglicht es dem Agenten, selbst Oberflächen zu erzeugen.

Merken Sie sich dieses Bild. Es hilft Ihnen, jedes Protokoll richtig einzuordnen.

MCP: Der Universalstecker für Werkzeuge und Daten

Das Model Context Protocol (MCP) ist ein offenes Protokoll. Es legt fest, wie Sprachmodelle Werkzeuge, also Funktionen, aufrufen und zusätzlichen Kontext erhalten.

Vorher und nachher: Was MCP verändert

Früher musste jede KI-Anwendung jede Funktion einzeln anbinden. Das ist, als hätte jedes Elektrogerät seinen eigenen Stecker. Mit MCP werden Funktionen in sogenannte MCP-Server verpackt. Diese Server laufen entweder lokal auf Ihrem Rechner oder entfernt in der Cloud.

Host, Client und Server, wer ist wer?

Die Begriffe klingen zunächst verwirrend, sind aber schnell erklärt:

• Der MCP-Server stellt die Funktionen bereit.
• Der MCP-Client hält jeweils eine direkte Verbindung zu genau einem Server.
• Der MCP-Host ist die Kombination aus Ihrer KI-Anwendung und ihren Clients.

Möchte Ihre Anwendung mehrere Server nutzen, besitzt sie einfach mehrere Clients.

Die Transportwege: stdio und Streamable HTTP

Für die Übertragung gibt es zwei Varianten. Standard-I/O eignet sich für lokale Server, denn hier ist kein Netzwerk nötig. Streamable HTTP funktioniert sowohl lokal als auch über das Netz. Die ausgetauschten Nachrichten sind im Kern Funktionsaufrufe im JSON-Format, für Menschen lesbar und für Maschinen eindeutig.

Die drei Bausteine eines MCP-Servers

Ein MCP-Server kann drei Arten von Inhalten anbieten. Ein Alltagsvergleich hilft: Denken Sie an eine Küche.

Tools, die Küchengeräte

Tools sind Funktionen mit Eingaben und Ausgaben, etwa eine Summenberechnung oder eine Wetterabfrage. Das Modell entscheidet selbst, wann es ein Tool verwendet, so wie ein Koch selbst entscheidet, wann er den Mixer einschaltet.

Resources, der Vorratsschrank

Resources stellen Daten nur zum Lesen bereit, beispielsweise Dokumente oder Konfigurationen. Hier bestimmt die Anwendung, wann eine Ressource hinzugefügt wird.

Prompts, das Rezeptbuch

Prompts sind wiederverwendbare Vorlagen. Sie zeigen, wie Tools und Ressourcen sinnvoll kombiniert werden. Die Auswahl trifft der Benutzer, so wie Sie im Rezeptbuch ein Gericht auswählen.

In TypeScript gelingt der Einstieg mit dem offiziellen MCP-SDK. Ein einfaches Tool ist schnell definiert:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "mein-server", version: "1.0.0" });

server.registerTool(
  "summe",
  {
    description: "Addiert zwei Zahlen.",
    inputSchema: { a: z.number(), b: z.number() }
  },
  async ({ a, b }) => ({
    content: [{ type: "text", text: String(a + b) }]
  })
);

Auf dieselbe Weise registrieren Sie Ressourcen und Prompts. Die Eingaben werden dabei mit Zod beschrieben, sodass das Modell genau weiß, welche Werte es übergeben muss.

Ein Praxisbeispiel: Der Dokumentenserver

Wie die drei Bausteine zusammenspielen, zeigt ein kleiner Dokumentenserver. Er enthält einfache Textdateien, die in Markdown umgewandelt werden sollen. Dafür gibt es ein Tool zum Lesen und eines zum Bearbeiten, eine Ressource zum Auflisten der Dokumente sowie einen Prompt namens "format". Dieser Prompt beschreibt dem Modell genau, was zu tun ist: Überschriften und Aufzählungen ergänzen, das Bearbeitungswerkzeug nutzen und am Ende das fertige Dokument zurückgeben.

In einem Kommandozeilenwerkzeug wie Claude Code, Codex, Copilot CLI, Gemini CLI und Co. lässt sich der Prompt anschließend direkt aufrufen. Das Modell fragt vor jedem Werkzeugeinsatz um Erlaubnis, eine sinnvolle Sicherheitsleine. Ein praktischer Hinweis: Unterstützt ein Client keine Ressourcen mit Parametern, können Sie das Lesen eines Dokuments ersatzweise als Tool umsetzen.

Hilfsmittel und Stolpersteine

MCP Inspector und Registries

Der MCP Inspector ist eine lokale Webanwendung, mit der Sie Server testen und deren Tools, Ressourcen und Prompts betrachten können. Um fertige Server zu finden, lohnt sich ein Blick in die offene MCP-Registry sowie in die MCP-Registry von GitHub. In den meisten Fällen werden Sie nämlich keinen eigenen Server schreiben, sondern bestehende nutzen.

Unterschiedliche Unterstützung je nach Werkzeug

Nicht jedes Programm unterstützt alles. Manche Clients können nur lokale Server über Standard-I/O ansprechen, andere beherrschen beide Transportwege. Auch bei Tools, Ressourcen und Prompts gibt es Unterschiede: Einige Anwendungen unterstützen alle drei Bausteine, andere nur Tools. Da sich das ständig ändert, gilt: Prüfen Sie vor dem Einsatz den aktuellen Stand.

Weitere Funktionen: Elicitation und Fortschrittsmeldungen

Mit Elicitation kann ein Server beim Benutzer nachfragen, etwa um eine Bestätigung einzuholen oder fehlende Angaben zu erhalten. Das ähnelt einem Handwerker, der vor dem Bohren noch einmal fragt, ob die Stelle wirklich richtig ist. Die Fortschrittsmeldung wiederum informiert bei länger laufenden Aufgaben über den Stand, zum Beispiel "10 von 100 erledigt". Die Funktionen Roots und Sampling befinden sich dagegen auf dem Weg zur Abkündigung.

A2A: Wenn Agenten miteinander sprechen

Ein Agent besteht aus einem Modell, Anweisungen und Werkzeugen. In größeren Systemen arbeiten oft mehrere spezialisierte Agenten zusammen, die möglicherweise mit ganz unterschiedlichen Frameworks gebaut wurden. Das offene Agent-to-Agent-Protokoll (A2A) von Google regelt, wie diese Agenten miteinander kommunizieren.

Die Agent Card: Die Visitenkarte eines Agenten

Bevor ein Agent einen anderen beauftragt, muss er zwei Dinge wissen: Was kann der andere, und wie erreiche ich ihn? Die Antwort liefert die Agent Card, eine JSON-Beschreibung unter der festen Adresse /.well-known/agent-card.json. Sie enthält drei Bereiche:

1. Capabilities: Wie lässt sich der Agent ansprechen, per Anfrage und Antwort, per Streaming oder per Push-Benachrichtigung?
2. Skills: Welche Fähigkeiten bietet er an? Skills entsprechen im Grunde den Tools aus MCP, tragen hier nur einen anderen Namen.
3. Authentifizierung: Welche Anmeldung ist erforderlich?

Ein Skill wird möglichst ausführlich beschrieben, inklusive Beispielen wie "Wie viel ist ein Britisches Pfund in US-Dollar?". So kann ein Sprachmodell leichter erkennen, ob der Skill zur Aufgabe passt.

Der Agent Executor: Der Dolmetscher

Damit Agenten aus verschiedenen Frameworks dieselbe Sprache sprechen, wird jeder Agent in einen Agent Executor eingebettet. Diese Schnittstelle besitzt im Wesentlichen zwei Methoden: eine zum Ausführen eingehender Nachrichten und eine zum Abbrechen von Aufgaben. Das fertige Ergebnis einer Aufgabe nennt A2A ein Artifact.

Nachrichten oder Tasks?

Für einfache Fragen genügt eine zustandslose Nachricht: Frage rein, Antwort raus. Für länger dauernde Arbeiten legt der entfernte Agent einen Task an, der verschiedene Zustände durchläuft, etwa "eingereicht", "in Arbeit", "fehlgeschlagen" oder "abgeschlossen".

Polling, Streaming und Push-Benachrichtigungen

Beim Polling fragt der Auftraggeber immer wieder nach, einfach, aber wenig effizient, wie ein Kind auf der Rückbank, das ständig fragt: "Sind wir schon da?" Beim Streaming erhält er laufend Aktualisierungen in Echtzeit. Push-Benachrichtigungen eignen sich für Clients, die nur gelegentlich verbunden sind, zum Beispiel mobile Anwendungen.

A2A in der Praxis: SDKs und Frameworks

Für TypeScript steht ein eigenes A2A-SDK zur Verfügung. Damit erstellen Sie Agent Cards, implementieren den Executor und bauen einen Client, der zunächst die Agent Card eines anderen Agenten abruft und ihm anschließend Nachrichten sendet, wahlweise mit oder ohne Streaming.

Noch bequemer wird es mit Frameworks wie dem Agent Development Kit (ADK) von Google. Dort werden Agent Card und Executor automatisch erzeugt. Mit einem einzigen Aufruf wird ein Agent A2A-fähig, und auf der Gegenseite genügt ein sogenannter Remote-A2A-Agent, der auf die Agent Card verweist.

Ein anschauliches Beispiel ist ein Reiseassistent. Er nutzt einen lokalen Wetteragenten und einen entfernten Währungsagenten, der über A2A angebunden ist. Für den Reiseassistenten sehen beide Helfer gleich aus, dass einer davon über das Netz kommuniziert, bleibt ein Detail im Hintergrund. Fragen Sie ihn nach dem Wetter in Kopenhagen und nach dem Wechselkurs von Pfund zu Euro, verteilt er die Aufgaben selbstständig an den richtigen Helfer.

AG-UI: Die Live-Übertragung zum Benutzer

Während MCP und A2A im Hintergrund arbeiten, verbindet AG-UI den Agenten mit der Benutzeroberfläche. Das ereignisbasierte Protokoll wurde von CopilotKit entwickelt. Es standardisiert, wie Agenten-Backends aus Frameworks wie LangGraph, CrewAI oder ADK ihren Zustand an ein Frontend übermitteln. Man kann es sich wie eine Live-Sportübertragung vorstellen: Jedes Ereignis wird sofort an die Zuschauer gesendet.

AG-UI setzen Sie nicht allein ein, sondern stets zusammen mit einem Framework. Auf der Serverseite wickeln Sie Ihren Agenten in eine passende Middleware ein und stellen ihn über einen Endpunkt bereit. Auf der Clientseite empfangen Sie die Ereignisse mit TypeScript und zeigen sie in Ihrer Oberfläche an. Das AG-UI Interactive Dojo zeigt anschaulich, wie diese Integration für verschiedene Frameworks aussieht.

A2UI: Wenn der Agent die Oberfläche selbst baut

Agenten können nicht nur Text erzeugen, sondern auch Benutzeroberflächen. Genau das standardisiert A2UI, ein Protokoll für generative UI. Der Agent beschreibt die Oberfläche in JSON, und verschiedene Renderer stellen sie auf dem Gerät dar. Das funktioniert noch nicht perfekt, aber bereits erstaunlich gut.

Oft werden AG-UI und A2UI verwechselt. Der Unterschied ist jedoch klar: AG-UI regelt, wie Ereignisse transportiert werden. A2UI regelt, wie die Oberfläche selbst beschrieben wird. A2UI ist transportunabhängig; derzeit werden A2A und AG-UI als Übertragungswege unterstützt.

Die vier Nachrichtentypen von A2UI

Stellen Sie sich eine Theaterbühne vor:

• Create Surface stellt eine leere Bühne auf.
• Update Components bringt die Kulissen hinein.
• Update Data Model füllt die Szene mit Inhalt.
• Delete Surface räumt die Bühne nach der Vorstellung wieder ab.

Dazu gibt es einen Katalog standardisierter Komponenten für Layout, Anzeige und Interaktion. Renderer existieren für Lit und Angular sowie für Flutter auf Mobilgeräten, Desktop und Web.

Ein Beispiel: Die Restaurantsuche

Ein Benutzer möchte einen Tisch für zwei Personen reservieren. Der Agent erstellt eine Oberfläche, beschreibt deren Aufbau und füllt sie mit Daten. Ändert der Benutzer die Gästezahl auf drei und klickt auf "Bestätigen", geht diese Aktion zurück an den Agenten, der die Buchung abschließt.

Bemerkenswert ist, wo die eigentliche Arbeit steckt: im Prompt. Der Agent erhält eine Rollenbeschreibung, den Komponentenkatalog und konkrete JSON-Beispiele, etwa mit der Anweisung, bei fünf oder weniger Restaurants eine bestimmte Darstellung zu wählen. Je präziser die Beispiele, desto besser das Ergebnis.

Hilfreiche Werkzeuge für den Einstieg

Zum Ausprobieren bieten sich eine Komponentengalerie, ein Starterprojekt für A2A und A2UI von CopilotKit sowie der A2UI Composer an. Im Composer beschreiben Sie etwa eine Konferenz-App mit Sprechern und Vorträgen, lassen ein Widget erzeugen, verfeinern es und kopieren anschließend das JSON als Beispiel für Ihren eigenen Agenten.

Fazit: Vier Bausteine für vernetzte KI-Agenten

Die vier Protokolle ergänzen sich wie die Abteilungen eines gut organisierten Unternehmens. MCP gibt dem Agenten Zugang zu Werkzeugen und Daten, A2A lässt ihn mit Kollegen zusammenarbeiten, AG-UI hält die Benutzer in Echtzeit auf dem Laufenden, und A2UI erlaubt es ihm, seine Ergebnisse in einer passenden Oberfläche zu präsentieren. Vieles davon befindet sich noch in Bewegung: Funktionen werden abgekündigt, Werkzeuge unterschiedlich gut unterstützt, und bei generativen Oberflächen ist noch offen, welcher Standard sich durchsetzt. Für Einsteiger lohnt es sich dennoch, früh anzufangen, am besten mit einem Framework, das viele technische Details übernimmt. So können Sie sich auf das Wesentliche konzentrieren: nützliche Agenten zu bauen.

Häufig gestellte Fragen

Muss ich für die Nutzung von MCP einen eigenen Server programmieren?

Nein, in den meisten Fällen nicht. Häufig binden Sie bestehende MCP-Server in Ihren Agenten ein. Passende Server finden Sie in der offenen MCP-Registry oder in der Registry von GitHub. Ein eigener Server lohnt sich erst, wenn Sie spezielle Funktionen oder interne Daten bereitstellen möchten.

Worin unterscheiden sich MCP-Tools und A2A-Skills?

Im Kern beschreiben beide Funktionen, die ein anderer Teilnehmer nutzen kann. Tools gehören jedoch zu einem MCP-Server, der einem Agenten Werkzeuge bereitstellt. Skills werden in der Agent Card eines eigenständigen Agenten veröffentlicht, der selbst ein Modell und eigene Anweisungen besitzt.

Kann ich diese Protokolle auch mit TypeScript verwenden?

Ja. Sowohl für MCP als auch für A2A gibt es offizielle SDKs für TypeScript. Tools, Ressourcen und Prompts registrieren Sie direkt am Server, Eingaben beschreiben Sie typsicher mit Zod. Auch die Clientseite von AG-UI ist in TypeScript umgesetzt, sodass Sie vom Backend bis ins Frontend in einer Sprache arbeiten können.