MCP, HTTP, Webhooks und A2A einfach erklärt

Vier Verbindungen können technisch über HTTP laufen und trotzdem vier grundverschiedene Aufgaben erfüllen. Eine Agentenanwendung entdeckt ein Werkzeug. Ein festes Programm ruft einen dokumentierten Endpunkt auf. Ein Dienst meldet ein bereits eingetretenes Ereignis. Ein eigenständiger Agent übernimmt einen Auftrag mit eigener Laufzeit.

MCP, HTTP mit OpenAPI, Webhooks und A2A beschreiben diese Grenzen. Keines der Verfahren ersetzt die fachliche Entscheidung darüber, wer lesen, schreiben, freigeben oder veröffentlichen darf. Ein Produkt kann mehrere dieser Maschinenoberflächen anbieten und zusätzlich eine eigene Weboberfläche für Menschen besitzen. Es bleibt trotzdem eine Fachdomäne mit einem maßgeblichen Produktzustand und denselben fachlichen Regeln.

Vier Fragen statt einer Rangliste#

Eine Schnittstelle ist eine vereinbarte Grenze zwischen Systemen. Sie legt Eingaben, Ergebnisse und Fehler fest. Der Übertragungsweg beantwortet jedoch noch nicht, welche Verantwortung an dieser Grenze übergeben wird.

Die vier Optionen stehen nicht in einer Rangfolge und liegen nicht auf derselben technischen Schicht. HTTP ist ein Übertragungsprotokoll, OpenAPI beschreibt eine Schnittstelle, Webhooks verwenden HTTP für Ereigniszustellungen, und MCP sowie A2A bringen eigene Interaktionsverträge mit. Ein A2A-Agent kann intern MCP-Werkzeuge und normale HTTP-APIs aufrufen.

MCP stellt Fähigkeiten für Agentenanwendungen bereit#

MCP steht für Model Context Protocol. Eine Agentenanwendung kann damit etwa die Suche eines Wissensdienstes als Werkzeug entdecken; die Sichtbarkeit dieses Werkzeugs ist noch keine fachliche Berechtigung und kein Ersatz für einen festen Workflow.

Ein Server kann lokal als Prozess oder entfernt als Webdienst laufen. Das Wort „Server“ beschreibt seine Rolle im Protokoll, nicht seinen Standort.

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

Nach dem Verbinden kann die Agentenanwendung das Eingabeschema prüfen und das Werkzeug aufrufen. Das Modell erhält dadurch keine pauschale Berechtigung. Der Host steuert, welche Fähigkeiten sichtbar sind und welche Aufrufe eine Zustimmung verlangen. Der Server authentifiziert und autorisiert den Aufruf. Der zuständige Dienst setzt zusätzlich seine fachlichen Regeln für die Operation durch.

MCP passt zu offenen Aufgaben. Eine Agentenanwendung kann in einem Wissensdienst nach freigegebenem Wissen suchen, Quellen lesen und abhängig vom Ergebnis entscheiden, welcher nächste Schritt sinnvoll ist. Für wiederholte Veröffentlichungen mit identischer Schrittfolge ist diese Freiheit unnötig. Ein gespeicherter, freigegebener Workflow ist dort leichter zu prüfen und zu wiederholen.

HTTP und OpenAPI bilden einen ausdrücklichen Maschinenvertrag#

HTTP regelt Anfrage und Antwort. OpenAPI beschreibt darauf aufbauende APIs maschinenlesbar: Pfade, Methoden, Eingaben, Antworten und Sicherheitsverfahren. Menschen können die Beschreibung lesen, Programme daraus Clients erzeugen und Prüfungen die Implementierung mit dem Vertrag vergleichen.

Der folgende Aufruf ist ein schematisches Beispiel:

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

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

Der Aufruf fordert eine Vorschau an. Er sagt nichts darüber aus, wer den Inhalt fachlich geprüft hat oder ob diese Vorschau veröffentlicht werden darf. OpenAPI kann den technischen Vertrag präzisieren. Die Freigaberegel gehört in die Fachdomäne und in den kontrollierten Ablauf.

In einem Publishing-System kann die HTTP- und OpenAPI-Oberfläche feste Integrationen bedienen, ein Remote-MCP-Endpunkt ausgewählte Fähigkeiten an Agentenanwendungen richten und eine Weboberfläche die menschliche Arbeit in derselben Publishing-Domäne tragen. Alle drei Zugänge arbeiten dann mit denselben Revisionen, Vorschauen, Releases und Berechtigungsgrenzen; keiner führt einen zweiten Persistenzpfad ein.

Ein Webhook meldet ein Ereignis#

Bei einem normalen API-Aufruf fragt der Client aktiv nach. Bei einem Webhook sendet die Ereignisquelle eine HTTP-Anfrage an eine vorher registrierte Adresse. Der Empfänger muss dadurch nicht fortlaufend prüfen, ob sich etwas geändert hat.

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": "proposal.approved",
  "data": {
    "space": "product-docs",
    "concepts": ["integration-options"]
  }
}

Der Ereignistyp im Beispiel ist absichtlich generisch. In diesem Ablauf transportiert der Webhook nur das Ereignis und die Referenz auf den maßgeblichen Stand. Der Empfänger prüft Signatur und Alter, erkennt Mehrfachzustellungen über die Ereignis-ID und liest den Stand anschließend mit eigener Berechtigung aus dem verantwortlichen System.

Mehrfache Zustellung gehört zum normalen Fehlerbild. Der Empfänger muss idempotent arbeiten: Dieselbe Ereignis-ID darf fachlich nur einmal wirken. Er antwortet schnell und verschiebt längere Arbeit in einen gespeicherten Ablauf. Ein Wissensdienst kann dafür signierte Standard Webhooks liefern. Eine Workflow-Engine kann einen solchen Eingang signaturgeprüft und gegen Wiederholungen geschützt an genau einen versionierten Workflow binden, ohne die Wissens- oder Publishing-Regeln der beteiligten Systeme zu übernehmen.

A2A delegiert an ein eigenständiges Agentensystem#

A2A steht für Agent2Agent. Das Protokoll verbindet einen aufrufenden Agenten mit einem eigenständigen entfernten Agentensystem. Der Client kennt dessen veröffentlichte Fähigkeiten, aber nicht dessen internen Plan, Speicher oder Werkzeuge. Der entfernte Agent bleibt dafür verantwortlich, wie er den Auftrag innerhalb seiner Grenzen bearbeitet.

Eine Agent Card beschreibt Identität, Endpunkt, Fähigkeiten und Anforderungen an die Anmeldung. Eine Message überträgt einen Gesprächsschritt aus Text, Dateien oder strukturierten Daten. Länger laufende Arbeit erhält einen Task mit eigener ID und einem Lebenszyklus. Ergebnisse werden als Artifacts zurückgegeben. Rückfragen und andere notwendige Entscheidungen erscheinen als Zustandsübergänge des Tasks.

Das unterscheidet Delegation von einem Werkzeugaufruf. Bei MCP ruft eine Agentenanwendung eine beschriebene Fähigkeit auf. Bei A2A übergibt ein Agent ein Ziel an ein anderes System, das selbst planen, Werkzeuge verwenden und mehrere Schritte ausführen kann.

Weboberflächen und Maschinenoberflächen erfüllen verschiedene Aufgaben#

Eine Weboberfläche für Menschen ist keine fünfte Integrationsart. MCP, HTTP mit OpenAPI, Webhooks und A2A verbinden Maschinen. Weboberfläche und Maschinenoberflächen arbeiten mit dem Zustand derselben Fachdomäne und führen keinen zweiten Persistenzpfad ein.

Jede Weboberfläche verwendet dafür die Begriffe und Entscheidungen ihrer eigenen Domäne. In einem Wissensdienst ist eine ausstehende Wissensänderung ein Änderungsvorschlag, in einer Workflow-Engine gehört eine Ausführung zu einer bestimmten Workflow-Version.

Aus dieser Trennung folgen zwei Grenzen:

• Eine Weboberfläche wird nicht zum zweiten fachlichen System mit abweichenden Regeln.
• Ein Maschinenprotokoll wird nicht zur unbeabsichtigten Umgehung der menschlichen Entscheidung.

Kein Protokoll erteilt von selbst Berechtigungen#

Authentifizierung beantwortet: Wer stellt die Anfrage? Autorisierung beantwortet: Was darf diese Identität tun? Ein gültiger Schlüssel sollte Lesen, Schreiben und Veröffentlichen nicht pauschal zusammenfassen.

Ein Agent, der Wissen sucht, braucht nur Leserechte. Ein Schritt, der eine Vorschau baut, braucht die dafür erforderlichen Schreibrechte. Eine Veröffentlichung darf eine eigene Berechtigung und eine sichtbar gebundene menschliche Freigabe verlangen. Wenn eine Operation über mehrere Oberflächen angeboten wird, müssen für sie dieselben fachlichen Freigabegrenzen gelten.

Zuverlässigkeit entsteht ebenfalls nicht durch den Namen des Protokolls. Ein HTTP-Aufruf kann nach erfolgreicher Verarbeitung abbrechen, bevor die Antwort beim Client ankommt. Ein Webhook kann mehrfach eintreffen. Ein A2A-Task kann lange auf eine Entscheidung warten. Jeder schreibende Schritt braucht deshalb eine stabile Kennung, eine klare Wiederholungsregel und einen gespeicherten Zustand.

Für schreibende oder freigabepflichtige Integrationen müssen drei Verträge zusammenpassen:

• Der technische Vertrag beschreibt Eingaben, Ergebnisse und Fehler.
• Der fachliche Vertrag legt fest, welches System Wissen, Freigabe und Veröffentlichung besitzt.
• Der betriebliche Vertrag regelt Zeitlimits, Wiederholungen, Protokollierung und den Umgang mit Ausfällen.

Ein Ablauf mit allen vier Grenzen#

flowchart LR
    U["Mensch<br/>formuliert ein Ziel"] --> A["Agentenanwendung<br/>bearbeitet offene Aufgabe"]
    A -->|"MCP<br/>suchen und lesen"| K["Wissensdienst<br/>geprüftes Wissen"]
    A -->|"MCP oder HTTP / OpenAPI<br/>Revision und Vorschau"| C["Publishing-System<br/>Publishing-Domäne"]
    K -->|"signierter Webhook<br/>Freigabeereignis"| S["Workflow-Engine<br/>versionierter Workflow"]
    S -->|"HTTP / OpenAPI<br/>festgelegte Schritte"| C
    A -.->|"A2A<br/>begrenzten Auftrag delegieren"| R["Agentensystem<br/>eigenständiger Task"]
    H["Mensch in der jeweiligen Weboberfläche"] -.-> K
    H -.-> S
    H -.-> C
    H -.-> R

Der erste Durchlauf kann begleitet sein. Eine Agentenanwendung liest im Wissensdienst, erzeugt Markdown und baut im Publishing-System eine Vorschau. Ein Mensch sieht die Ergebnisse und kann die Reihenfolge noch verändern.

Sobald sich die Folge stabil wiederholt, gehört sie als versionierter Workflow in eine Workflow-Engine. Der Workflow liest eine konkrete freigegebene Wissensrevision, erzeugt eine Content-Revision und baut eine Vorschau. Er veröffentlicht nicht deshalb automatisch, weil ein Webhook ihn gestartet hat. Das Publishing-System behält die Freigabe- und Release-Grenze.

A2A kommt hinzu, wenn tatsächlich ein eigenständiges Agentensystem einen begrenzten Auftrag mit eigener Laufzeit übernimmt. Ein einfacher API-Aufruf wird durch die Bezeichnung „Agent“ nicht zu einer Delegation.

Die Entscheidung liegt vor dem Protokoll#

Die Tabelle hilft erst, wenn drei Fragen beantwortet sind: Welches System besitzt den Zustand? Welche Identität darf ihn verändern? Welche Wirkung benötigt eine menschliche Entscheidung? Daraus folgen die Regeln für Wiederholungen und die Ansicht, in der ein Mensch den aktuellen Stand prüfen kann.

Zuerst werden der Besitzer von Zustand und Freigabe festgelegt. Danach folgt das Protokoll.

Weiterführende Quellen#

• Model Context Protocol: Architektur
• Model Context Protocol: Einführung
• OpenAPI Specification
• Standard Webhooks
• A2A: zentrale Konzepte
• A2A und MCP im Vergleich