MCP, HTTP, Webhooks und A2A einfach erklärt

Diesen Beitrag anhören (14 Min.)

Ein KI-Agent soll Wissen finden, daraus eine neue Seite erstellen und die Veröffentlichung nach einer Freigabe auslösen. Das klingt nach einer einzigen Verbindung. Technisch stecken darin jedoch mehrere Gespräche: Der Agent fragt nach verfügbaren Fähigkeiten. Ein Dienst nimmt einen klar definierten Befehl entgegen. Ein anderes System meldet eine Änderung. Vielleicht übergibt ein eigenständiger Agent sogar einen länger laufenden Auftrag an einen zweiten Agenten.

MCP, HTTP mit OpenAPI, Webhooks und A2A passen jeweils zu einem dieser Gespräche. Sie sind keine vier Marken für dieselbe Technik. Wer ihre Aufgaben trennt, kann klein beginnen und den Ablauf später absichern, ohne alles neu zu bauen.

Zuerst drei Grundbegriffe

Eine Schnittstelle ist eine vereinbarte Grenze zwischen zwei Systemen. Sie legt fest, welche Nachrichten erlaubt sind, welche Daten sie enthalten und welche Antworten oder Fehler möglich sind. Diese Vereinbarung wird oft als Vertrag bezeichnet. Gemeint ist kein juristisches Dokument, sondern eine technische Zusage, auf die sich beide Seiten verlassen können.

Der Client beginnt eine Kommunikation. Der Server nimmt die Anfrage entgegen. Diese Rollen sagen nichts darüber aus, welches System wichtiger ist. Dieselbe Anwendung kann in einer Verbindung Client und in einer anderen Server sein. Eine Ausführungsschicht kann zum Beispiel Aufträge eines Agenten annehmen und anschließend selbst als Client eine Publishing-API aufrufen.

Eine API ist eine programmierbare Schnittstelle. HTTP ist dabei häufig der Übertragungsweg. Ein Aufruf besteht vereinfacht aus Methode, Adresse, Kopfzeilen und Inhalt. Die Antwort enthält einen Statuscode und meist strukturierte Daten.

POST /v1/sites/demo/previews HTTP/1.1
Host: content.example.com
Authorization: Bearer <token>
Content-Type: application/json

{
  "revisionIds": ["rev-123", "rev-456"]
}

Dieser Aufruf kann eine Vorschau anfordern. Er erklärt aber noch nicht, wie der Agent den Endpunkt gefunden hat, wer eine fachliche Freigabe erteilt oder wie ein anderes System von der fertigen Vorschau erfährt. Dafür braucht die Architektur weitere Verträge.

Vier Techniken beantworten vier Fragen

Technik	Einfache Leitfrage	Typische Richtung	Geeignet für
MCP	Welche Werkzeuge und Informationen kann eine Agentenanwendung verwenden?	Agentenanwendung zu Fähigkeitsserver	Entdecken, lesen und gezielt handeln
HTTP mit OpenAPI	Welchen exakt beschriebenen Endpunkt kann Software aufrufen?	Client zu API-Server	Verbindliche Maschinenoperationen
Webhook	Welches bereits eingetretene Ereignis soll ein anderes System erfahren?	Ereignisquelle zu Empfänger	Schnelle, ereignisgesteuerte Auslöser
A2A	Welchen Auftrag kann ein eigenständiger Agent an einen anderen Agenten übergeben?	Agent zu Agent	Delegation, längere Aufgaben und Zusammenarbeit

Die Tabelle beschreibt den Schwerpunkt. Sie verbietet keine Kombination. MCP wird meist über eine lokale Prozessverbindung oder HTTP transportiert. A2A besitzt ebenfalls HTTP-basierte Protokollbindungen. Ein A2A-Agent kann intern MCP-Werkzeuge und normale APIs verwenden. Der Übertragungsweg allein verrät also noch nicht, welche Verantwortung eine Verbindung trägt.

MCP verbindet eine Agentenanwendung mit Fähigkeiten

MCP steht für Model Context Protocol. Ein MCP-Server beschreibt Fähigkeiten in einer Form, die eine Agentenanwendung lesen kann. Tools sind aufrufbare Aktionen. Resources liefern adressierbare Informationen. Prompts stellen wiederverwendbare Vorlagen bereit. Die Agentenanwendung ist der MCP-Client und koordiniert die Verbindung für das Modell und den Menschen.

Das Wort Server kann hier irritieren. Ein lokaler MCP-Server muss kein öffentlich erreichbarer Webdienst sein. Er kann als Prozess auf demselben Rechner laufen. Entscheidend ist der Vertrag, nicht der Ort.

{
  "mcpServers": {
    "knowledge": {
      "type": "http",
      "url": "https://knowledge.example.com/mcp"
    }
  }
}

Nach dem Verbinden kann die Agentenanwendung beispielsweise ein Suchwerkzeug entdecken, dessen Eingaben prüfen und es aufrufen. Das Modell bekommt dadurch nicht automatisch beliebige Rechte. Die Anwendung muss Serverauswahl, Zugangsdaten, Freigaben und sichtbare Ergebnisse kontrollieren.

MCP passt gut zu einer offenen Aufgabe: „Finde die geltenden Regeln und entwirf daraus eine Seite.“ Während der Bearbeitung kann das Modell entscheiden, welche Suche als Nächstes sinnvoll ist. Für eine hundertfach identische Veröffentlichung ist diese Freiheit dagegen selten nötig. Dann sollte ein festgeschriebener Ablauf die bekannten Schritte ausführen.

HTTP und OpenAPI beschreiben konkrete Maschinenaufrufe

HTTP regelt, wie eine Anfrage übertragen und beantwortet wird. REST ist ein verbreiteter Architekturstil für HTTP-APIs. OpenAPI beschreibt solche APIs maschinenlesbar: verfügbare Pfade, Methoden, Eingaben, Antworten und Sicherheitsverfahren.

Damit können Menschen Dokumentation lesen, Programme Clients erzeugen und Tests prüfen, ob Implementierung und Vertrag zusammenpassen. OpenAPI macht aus einer API jedoch keinen sicheren Geschäftsprozess. Ein dokumentierter Release-Endpunkt weiß nicht automatisch, ob ein Mensch zuvor genau diese Vorschau geprüft hat. Diese Regel gehört in den Dienst selbst oder in eine kontrollierte Ausführungsschicht.

Für Contentkit ist die HTTP-API heute die verbindliche Maschinenoberfläche. Eine Agentenanwendung kann sie direkt, über ein kleines Skript oder über einen ausgewählten MCP-Adapter nutzen. Ein Adapter übersetzt die Bedienform. Er ersetzt weder die HTTP-Berechtigungen noch die fachlichen Regeln des Publishing-Dienstes.

Ein Webhook meldet, dass etwas passiert ist

Bei einer normalen API-Anfrage fragt der Client aktiv nach. Bei einem Webhook geht die Anfrage vom System aus, in dem das Ereignis eingetreten ist. Es sendet eine HTTP-Anfrage an eine vorher registrierte Adresse. So muss der Empfänger nicht jede Minute nach Änderungen suchen.

POST /webhooks/knowledge HTTP/1.1
Host: orchestration.example.com
webhook-id: evt-789
webhook-timestamp: 1785585600
webhook-signature: v1,<signature>
Content-Type: application/json

{
  "type": "knowledge.proposal.approved",
  "data": {
    "space": "product-docs",
    "concepts": ["integration-options"]
  }
}

Ein Webhook ist am zuverlässigsten als Signal, nicht als vollständige Kopie des neuen Zustands. Der Empfänger prüft Signatur und Alter, erkennt eine doppelte Zustellung über die Ereignis-ID und liest anschließend die freigegebenen Inhalte mit seiner eigenen Berechtigung aus dem verantwortlichen System.

Mehrfache Zustellung ist kein Sonderfall, sondern Teil eines robusten Entwurfs. Der Empfänger muss deshalb idempotent arbeiten: Dieselbe Ereignis-ID darf fachlich nicht zweimal wirken. Er antwortet außerdem schnell und erledigt längere Arbeit außerhalb der eingehenden HTTP-Anfrage.

A2A verbindet eigenständige Agentensysteme

A2A steht für Agent2Agent. Das offene Protokoll ist für Systeme gedacht, die jeweils als eigenständiger Agent auftreten. Ein aufrufender Agent kennt die angebotenen Fähigkeiten seines Gegenübers, aber nicht dessen internen Plan, Speicher oder Werkzeuge. Der entfernte Agent behält die Verantwortung dafür, wie er den Auftrag erfüllt.

Eine Agent Card beschreibt Identität, Fähigkeiten, Schnittstellen, unterstützte Funktionen und Anforderungen an die Anmeldung. Eine Message trägt eine Gesprächsnachricht aus Text, Dateien oder strukturierten Daten. Für längere Arbeit entsteht ein Task mit eigener ID und einem Lebenszyklus. Ergebnisse heißen Artifacts. Fortschritt kann der Client abfragen, als Datenstrom empfangen oder über eine Push Notification zugestellt bekommen.

Das ist mehr als ein anderer Name für einen Tool-Aufruf. Bei MCP wählt die Agentenanwendung typischerweise ein Werkzeug und erhält dessen Ergebnis. Bei A2A delegiert ein Agent ein Ziel an ein anderes, möglicherweise unbekannt implementiertes Agentensystem. Der entfernte Agent kann Rückfragen stellen, den Auftrag selbstständig weiterbearbeiten und später mehrere Ergebnisartefakte liefern.

Was keine dieser Techniken allein leistet

Ein Protokoll regelt Kommunikation. Es entscheidet nicht von selbst, welche Daten fachlich gelten, wer einen produktiven Release freigeben darf oder wie lange ein Ergebnis aufbewahrt wird. Diese Regeln müssen in den beteiligten Diensten und im Ablauf ausdrücklich festgelegt werden.

Authentifizierung beantwortet zunächst: „Wer stellt die Anfrage?“ Autorisierung beantwortet: „Was darf diese Identität tun?“ Ein gültiger API-Schlüssel sollte deshalb nicht automatisch Lesen, Schreiben und Veröffentlichen erlauben. Ein Agent, der Wissen sucht, benötigt nur Leserechte. Ein Schritt, der eine Vorschau baut, braucht Schreibrechte für Revisionen. Der spätere Release kann eine eigene Berechtigung und eine sichtbare menschliche Freigabe verlangen.

Auch Zuverlässigkeit entsteht nicht durch die Wahl eines Protokolls. Ein HTTP-Aufruf kann nach der Verarbeitung abbrechen, bevor die Antwort beim Client ankommt. Ein Webhook kann mehrfach eintreffen. Ein A2A-Task kann nach einer Rückfrage lange auf Eingaben warten. Für jeden schreibenden Schritt braucht es deshalb eine stabile Kennung, eine klare Wiederholungsregel und einen gespeicherten Zustand.

Bei der Integration prüfe ich dafür drei verschiedene Ebenen. Der technische Vertrag muss Eingaben und Fehler eindeutig beschreiben. Der fachliche Vertrag muss festlegen, welches System für Wissen, Freigabe und Veröffentlichung zuständig ist. Der betriebliche Vertrag bestimmt Zeitlimits, Wiederholungen, Protokollierung und Zuständigkeit bei einem Fehler. Erst alle drei Ebenen zusammen ergeben einen verlässlichen Prozess.

So greifen die Verträge ineinander

flowchart LR
    U["Mensch<br/>formuliert ein Ziel"] --> A["Agentenanwendung<br/>plant die neue Aufgabe"]
    A -->|"MCP<br/>Fähigkeiten entdecken"| K["Wissensdienst<br/>suchen und lesen"]
    A -->|"HTTP / OpenAPI<br/>konkreter Aufruf"| C["Publishing-Dienst<br/>Vorschau bauen"]
    K -->|"Webhook<br/>Freigabe melden"| O["Ausführungsschicht<br/>bekannten Ablauf starten"]
    O -->|"HTTP / OpenAPI<br/>festgelegte Schritte"| C
    A -.->|"A2A<br/>Ziel delegieren"| R["Eigenständiger Agent<br/>Auftrag bearbeiten"]

Das Beispiel enthält absichtlich mehrere Wege. Beim ersten Versuch sucht ein Mensch mit einem Agenten nach Wissen und baut direkt eine Vorschau. Wird daraus ein regelmäßiger Vorgang, übernimmt eine Ausführungsschicht die feste Reihenfolge. Damit ist ein Dienst gemeint, der Verbindungen, Zugangsdaten, Ablaufversionen, Freigaben und Ausführungszustände verwaltet. Ein Webhook startet den Ablauf nach einer bestätigten Änderung. A2A kommt erst hinzu, wenn tatsächlich ein eigenständiger entfernter Agent einen Auftrag mit eigener Laufzeit und Verantwortung übernimmt.

Auch Markdown, llms.txt und llms-full.txt haben ihren Platz. Markdown ist ein portables Inhaltsformat. Die beiden Textdateien machen Dokumentation für Modelle leicht auffindbar und lesbar. Sie führen keine Operation aus, melden kein Ereignis und erteilen keine Berechtigung. Dokumentation erklärt einen Vertrag; MCP, HTTP, Webhooks oder A2A führen die jeweilige Kommunikation aus.

Vom begleiteten Versuch zum festen Ablauf

Am Anfang darf die Verbindung bewusst einfach sein. Eine Agentenanwendung liest mit WikiKit über MCP, erzeugt Markdown und ruft mit einem eng begrenzten Contentkit-Schlüssel die HTTP-API für eine Vorschau auf. Ein Mensch sieht jeden Schritt und kann die Reihenfolge noch verändern. Diese Form eignet sich, um die Aufgabe zu verstehen und die nötigen Eingaben herauszuarbeiten.

Wiederholt sich die Folge, sollte nicht jeder Lauf neu vom Modell geplant werden. Die erprobten Schritte werden als versionierter Workflow gespeichert. Der Workflow liest eine konkrete freigegebene Wissensrevision, erzeugt daraus eine Content-Revision und baut eine ablaufende Vorschau. Der Release verwendet genau die Revisionen dieser geprüften Vorschau. So bleibt nachvollziehbar, welcher Inhalt freigegeben wurde.

Ein Webhook kann den Workflow später automatisch anstoßen. Er enthält eine Ereignis-ID und den Hinweis auf die betroffenen Konzepte. Der Workflow liest den aktuellen freigegebenen Stand anschließend selbst nach. Ein A2A-Agent wäre erst dann ein zusätzlicher Baustein, wenn beispielsweise ein Publishing-Dienst eines anderen Teams den Auftrag eigenständig annimmt, Rückfragen bearbeitet und seine Ergebnisse über einen Task zurückliefert.

Für den Anwender verändert diese Entwicklung vor allem die Prüfbarkeit. Im Versuch bestätigt er einzelne Tool-Aufrufe. Im festen Ablauf prüft er die Vorschau und die beabsichtigte Wirkung. Bei einer Agentendelegation sieht er zusätzlich den Zustand des entfernten Tasks und dessen Artifacts. Die Technik wird umfangreicher, aber die menschliche Entscheidung sollte dadurch einfacher und eindeutiger werden.

Eine Auswahlregel für den Anfang

Vor der Auswahl hilft es, die gewünschte Wirkung in einem Satz zu formulieren:

Soll ein Agent während einer offenen Aufgabe passende Fähigkeiten finden, ist MCP ein guter Ausgangspunkt. Soll Software einen bekannten Befehl mit festem Schema ausführen, passt HTTP mit OpenAPI. Soll eine bestätigte Änderung einen Ablauf starten, passt ein signierter Webhook. Soll ein unabhängiger Agent ein Ziel eigenverantwortlich weiterbearbeiten, wird A2A interessant.
Sobald ein Vorgang wiederholt schreibt oder veröffentlicht, gehören eng begrenzte Rechte, eine feste Ablaufversion, wiederholbare Fehlerbehandlung, nachvollziehbare Freigaben und ein Ausführungsprotokoll dazu. Das gilt unabhängig vom verwendeten Protokoll.

Die wichtigste Entscheidung lautet deshalb nicht „Welcher Standard gewinnt?“, sondern „Wer besitzt an dieser Stelle welche Verantwortung?“ Der nächste Teil wendet diese Auswahl auf WikiKit, Contentkit und eine getrennte Ausführungsschicht an.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare