Mike Bild
Blog

MCP, HTTP oder Webhook? SubKit, WikiKit und ContentKit verbinden

MCP, REST, Webhooks und A2A lösen unterschiedliche Integrationsprobleme. Eine Entscheidungshilfe zeigt, wann direkter Agentenzugriff genügt und wann SubKit den Ablauf übernehmen sollte.

≈ 9 Min. Lesezeit
SoftwareKIArchitektur
Markdown In Claude öffnenIn ChatGPT öffnen

Diesen Beitrag anhören (15 Min.)

MP3 herunterladen

Eine freigegebene Änderung in einer Wissensbasis soll als verständliche Seite auf einer Website erscheinen. Der Vorgang klingt zunächst nach einem einzigen Auftrag an einen Agenten: neues Wissen lesen, Text erzeugen und veröffentlichen. Tatsächlich berührt er mindestens fünf verschiedene Verantwortungen. WikiKit bestimmt den freigegebenen Wissensstand. ContentKit baut die Veröffentlichung. SubKit steuert den Ablauf. Eine Vorschau muss geprüft werden. Zuletzt darf ein klar begrenzter Schritt den sichtbaren Stand verändern.

Für jede dieser Grenzen steht ein eigener Vertrag bereit. MCP macht Fähigkeiten für Agenten auffindbar. OpenAPI beschreibt HTTP-Schnittstellen. Webhooks melden Ereignisse. A2A verbindet eigenständige Agenten. Dazu kommen Markdown und andere portable Artefakte. Wer daraus eine einheitliche Technik machen möchte, handelt sich schnell eine Integrationsschicht ein, die mehr verdeckt als vereinfacht.

Die Produkte werden über ihre jeweiligen Verträge verbunden: WikiKit liefert geprüftes Wissen mit Herkunft, ContentKit verwaltet Veröffentlichungen und SubKit steuert wiederholbare Abläufe über Systemgrenzen hinweg.

Eine Strecke mit mehreren Grenzen

Stand 17. August 2026 sind SubKit, WikiKit und ContentKit aus Sicht eines Agenten-Hosts MCP-Server. Codex, Claude Code oder ein anderer Host übernimmt die Rolle des MCP-Clients. SubKit besitzt zusätzlich einen eigenen MCP-Client und kann dadurch die Fähigkeiten fremder MCP-Server in Authoring und gespeicherten request-Schritten verwenden. ContentKits Remote-MCP-Oberfläche bildet fachliche Fähigkeiten für Agenten ab; HTTP und OpenAPI bleiben der ausdrückliche Dienstvertrag für feste Integrationen. Beide Oberflächen greifen auf dieselben Revisionen, Vorschauen, Releases und Berechtigungsregeln zu.

Alle drei Produkte besitzen außerdem Web-Cockpits. Diese Cockpits sind keine getrennten Verwaltungssysteme. Sie machen Menschen denselben Fachzustand zugänglich, den Agenten über MCP und feste Dienste über HTTP verwenden: Wissen und ChangeProposals in WikiKit, Connectoren und Workflow-Versionen in SubKit sowie Revisionen, Vorschauen und Releases in ContentKit.

flowchart LR
    H["Mensch<br/>erteilt Auftrag"] --> A["Agenten-Host<br/>Codex oder Claude"]
    A -->|"MCP<br/>erkunden und handeln"| S["SubKit<br/>Abläufe und Governance"]
    A -->|"MCP<br/>suchen und lesen"| W["WikiKit<br/>geprüftes Wissen"]
    A -->|"MCP<br/>entwerfen und prüfen"| C["ContentKit<br/>veröffentlichte Projektion"]
    S -->|"MCP<br/>beim Authoring oder im Workflow"| W
    S -->|"REST / OpenAPI<br/>feste Dienstoperation"| W
    S -->|"MCP oder HTTP<br/>Revision und Vorschau"| C
    W -->|"Standard Webhook<br/>Zustandsänderung"| S
    W -.->|"Markdown / OKF<br/>portables Artefakt"| C
    C --> P["Website<br/>für Menschen und Agenten"]

Das Diagramm zeigt zwei Verbindungen zwischen SubKit und WikiKit, weil sie unterschiedliche Zwecke erfüllen. Beim Entwerfen eines Ablaufs kann SubKits Agent mit wikikit_search und wikikit_read nachschlagen, welche Regeln gelten. Ein gespeicherter Workflow überlässt dieselbe Recherche nicht bei jedem Lauf erneut einem Modell. Er liest den gebundenen WikiKit-Stand über einen begrenzten MCP- oder HTTP-Connector und verarbeitet ihn nach einer freigegebenen Workflow-Version.

Die erste Auswahlregel trennt offene Auswahl von wiederholbarer Kontrolle: Ein Agent darf Quellen und Lösungsweg für eine neue Aufgabe auswählen. Eine bekannte Wiederholung gehört in einen versionierten Ablauf mit festgelegter Kontrollfolge, Berechtigungen und Fehlerregeln.

Der Vertrag bleibt beim jeweiligen Produkt

Keines der drei Produkte braucht die anderen, um seine eigene Aufgabe zu erfüllen. Diese Unabhängigkeit ist für die Integration wichtiger als ein gemeinsames Framework.

Produkt Führender Zustand Geeignete Schnittstellen Bewusste Grenze
WikiKit Quellen, Claims, Entscheidungen und freigegebene Konzepte MCP, REST/OpenAPI, Webhooks, Markdown/OKF Eine Veröffentlichung ist keine Wissensfreigabe
ContentKit Revisionen, Vorschauen und aktive Releases MCP, REST/OpenAPI, Webhooks, Markdown, llms.txt ContentKit entscheidet nicht, welches Wissen wahr ist
SubKit Connectoren, Workflow-Versionen, Ausführungen und Freigaben MCP, REST/OpenAPI, Webhooks, Zeitpläne Der Ablauf besitzt nicht die Fachdaten seiner Zielsysteme

Damit bleibt auch ein Austausch möglich. Eine andere Wissensbasis kann WikiKit ersetzen, wenn sie denselben fachlichen Vertrag erfüllt. Ein anderes Ausgabesystem kann an die Stelle von ContentKit treten. SubKit hält die Verbindung, wird aber nicht zur gemeinsamen Datenbank.

llms.txt und llms-full.txt helfen an einer anderen Stelle. Sie beschreiben ein Produkt in einer Form, die ein Modell gut lesen kann. SubKit kann solche Selbstbeschreibungen bei der Connector-Erkundung finden und bei Bedarf abrufen. ContentKit und WikiKit veröffentlichen ihre Dokumentation ebenfalls auf diesem Weg. Das liefert dem Modell Dokumentationskontext, führt jedoch keinen API-Aufruf aus und erteilt keine Berechtigung. llms.txt ist eine vorgeschlagene Konvention für Dokumentation, kein Ersatz für einen ausführbaren Vertrag.

Direkter Zugriff für neue oder seltene Aufgaben

Für eine neue oder seltene, von einem Menschen begleitete Aufgabe ist die direkte Verbindung der kleinere Aufbau. Der Agenten-Host registriert SubKit, WikiKit und ContentKit als MCP-Server. Jede Verbindung erhält einen eigenen, eng begrenzten Schlüssel. Schematisch sieht eine solche Host-Konfiguration so aus: Wer einen festen Dienst statt eines begleiteten Agentenlaufs baut, kann ContentKit und WikiKit über ihre dokumentierten HTTP-APIs anbinden.

{
  "mcpServers": {
    "subkit": {
      "type": "http",
      "url": "https://subkit.example.com/mcp"
    },
    "wikikit": {
      "type": "http",
      "url": "https://wikikit.example.com/mcp"
    },
    "contentkit": {
      "type": "http",
      "url": "https://contentkit.example.com/mcp"
    }
  }
}

Die Zugangsdaten gehören in den Secret Store des Hosts und nicht in diese Datei. Ein WikiKit-Token kann laut geprüftem Scope-Vertrag nur knowledge:read tragen. Für ContentKit lässt sich Recherche mit content:read von Upload und der menschlich bestätigten Veröffentlichung mit release:write trennen, wie der MCP-Vertrag festlegt. SubKit prüft die Rechte seines eigenen Aufrufers unabhängig davon.

Dieser Aufbau passt, wenn ein Mensch den Lauf begleitet, die Reihenfolge noch nicht feststeht und Erkenntnis wichtiger ist als Wiederholung. Er hält alle Fähigkeiten sichtbar und macht Fehler leicht untersuchbar. Sein Preis wächst mit der Zahl der Systeme: Der Host muss mehrere Anmeldungen verwalten, viele Tool-Beschreibungen in den Modellkontext bringen und Freigaben über verschiedene Oberflächen verstehen.

Die MCP-Empfehlungen für Clients warnen vor einem naiven Gesamtkatalog. Zu viele Tool-Schemata belegen Modellkontext, bevor die eigentliche Frage verarbeitet wird. Für den direkten Aufbau sollten deshalb nur die Server und Berechtigungen aktiv sein, die der konkrete Auftrag benötigt.

MCP für Agenten, OpenAPI für feste Dienste

Für ContentKit ist kein allgemeiner OpenAPI-zu-MCP-Adapter nötig. Seine native MCP-Oberfläche bietet ausgewählte fachliche Operationen mit eigenen Ressourcen, Berechtigungen und menschlichen Bestätigungen. Sie kopiert nicht mechanisch jeden HTTP-Endpunkt.

OpenAPI bleibt trotzdem relevant. Ein fester Dienst oder SubKit-Workflow braucht einen stabilen, maschinenlesbaren Vertrag für konkrete Requests, Antworten und Fehler. Die Wahl der Oberfläche ändert den fachlichen Zustand nicht: Eine Revision bleibt unveränderlich, eine Vorschau bleibt vom aktiven Release getrennt und eine veröffentlichende Wirkung benötigt die dafür vorgesehene Berechtigung und Bestätigung.

Für ein anderes Produkt ohne eigene MCP-Oberfläche kann ein Adapter weiterhin als Übergang dienen. Die gesamte HTTP-API mechanisch in Tools zu verwandeln, verlagert jedoch nur den großen Katalog in den Agenten-Host. Besser sind kleine Fähigkeiten mit einer klaren Absicht. MCP ist dann eine für Agenten geeignete Sicht; OpenAPI bleibt die maschinenlesbare Beschreibung des HTTP-Dienstvertrags.

SubKit übernimmt die Wiederholung

Sobald derselbe Vorgang regelmäßig läuft oder den öffentlichen Stand verändert, verschiebt sich die Verantwortung. ContentKit wird als MCP- oder HTTP-Connector in SubKit angelegt. Die gewählte Oberfläche richtet sich nach der konkreten Operation; seine OpenAPI-Datei beschreibt feste HTTP-Aufrufe. Zugangsdaten liegen im Vault und tauchen weder im Workflow noch im Modellkontext auf. Aus den einzelnen Aufrufen entsteht ein versionierter Ablauf für Upload, Vorschau, Prüfung und Release.

SubKit bietet dafür mehr als Protokollübersetzung. Ein Connector wird einmal authentifiziert und anschließend wiederverwendet. Jeder Lauf hat eine feste Workflow-Version, strukturierte Ein- und Ausgaben, ein Ausführungsprotokoll und einen nachvollziehbaren Auslöser. Redaktionelle Parameter, Retry-Grenzen und Freigabepunkte liegen in dieser versionierten Workflow-Konfiguration statt im Engine-Code. Eine neue oder zurückgerollte Workflow-Version benötigt kein Engine-Deployment. Schreibende oder riskante Schritte passieren erst nach der dafür vorgesehenen Freigabe.

Dasselbe gilt für WikiKit, aber mit einer nützlichen Trennung. SubKits Authoring-Agent darf WikiKit über dessen MCP-Werkzeuge kennenlernen. Der gespeicherte Lauf verwendet danach eine genaue MCP-Operation oder einen festen HTTP-Aufruf mit rein lesendem Schlüssel. So hilft das Modell beim Bauen, während die freigegebene Kontrollfolge in Produktion nicht neu interpretiert wird.

type PublicationInput = {
  space: string
  proposalId: string
  conceptSlugs: string[]
}

type PublicationCheckpoint =
  | { state: "preview_ready"; previewUrl: string; revisionIds: string[] }
  | { state: "approval_required"; approvalUrl: string }
  | { state: "released"; releaseId: string; publicUrls: string[] }
  | { state: "failed"; step: string; requestId: string }

Diese Grenze macht Vorschau, Prüfbericht und beabsichtigte Wirkung getrennt prüfbar. Der Prüfer bewertet diese drei Artefakte statt den vermuteten Modellzustand. Der Agent darf den Vorgang vorbereiten; der festgeschriebene Ablauf und die Berechtigung entscheiden über seine Reichweite.

Ein Webhook startet den gebundenen Ablauf

Eine dauerhafte Verbindung sollte nicht im Minutentakt fragen, ob sich etwas geändert hat. WikiKit schreibt bei einer Freigabe im selben Datenbankvorgang Ereignisse in eine Outbox und liefert sie als signierte Standard Webhooks aus. wikikit.proposal.approved enthält die betroffenen Konzept-Slugs; wikikit.concept.updated bezeichnet die einzelne neue Revision. Die Ereignisnamen sind im geprüften OpenAPI-Vertrag gebunden; die atomare Outbox ist im geprüften Datenvertrag definiert.

SubKit kann einen eingehenden Standard Webhook prüfen, anhand von webhook-id wiederholte Zustellungen erkennen und den gebundenen Workflow starten. Der Webhook bleibt dabei ein Signal. Er transportiert nicht den gesamten Wissensstand. Der Workflow liest jedes genannte Konzept mit seinem eigenen knowledge:read-Schlüssel aus WikiKit nach. Damit stammt der Inhalt aus der führenden Quelle und nicht aus einer möglicherweise verspäteten Ereigniskopie.

sequenceDiagram
    participant R as Mensch im WikiKit-Review
    participant W as WikiKit
    participant S as SubKit
    participant C as ContentKit
    participant P as Prüfer
    R->>W: Vorschlag freigeben
    W->>S: proposal.approved als signierter Webhook
    S->>S: Signatur prüfen und webhook-id deduplizieren
    S->>W: Freigegebene Konzepte über REST lesen
    W-->>S: Markdown, Revision und Herkunft
    S->>C: Revisionen hochladen und Vorschau bauen
    C-->>S: Revision, Preview-Release-ID und Manifest
    S->>P: Vorschau und Prüfergebnisse vorlegen
    P-->>S: Inhalt und Manifest prüfen
    S-->>P: Gebundene ContentKit-Promotion öffnen
    P->>C: Geprüfte Vorschau im Cockpit bestätigen
    C-->>S: Release-ID und aktiver Stand
    S->>S: Öffentliche URLs und Ergebnis protokollieren

Für diesen Workflow gilt: Eine ungültige Signatur beendet den Eingang. Eine bekannte Ereignis-ID erzeugt keinen zweiten Lauf. 401 und 403 sind Konfigurations- oder Berechtigungsfehler und keine Einladung zum schnellen Wiederholen. Ein in diesem Workflow als fachlicher Validierungsfehler definiertes 422 geht mit Diagnose in die Überarbeitung. Vorübergehende Transportfehler folgen der Retry-Grenze der Workflow-Version. Die Promotion bleibt an die genaue Revision, Preview-Release-ID, Manifest-Digest und den vorherigen Veröffentlichungsstand gebunden. Nur der Mensch im ContentKit-Cockpit kann diese öffentliche Wirkung bestätigen.

Für regelmäßig freigegebene Wissensstände gelten damit drei getrennte Entscheidungen: WikiKit entscheidet über den freigegebenen Wissensstand; SubKit hält den Übergang an den projektspezifischen Prüfpunkten; ContentKit aktiviert nach seiner unabhängigen menschlichen Bestätigung den gebundenen Release.

Wann mehrere Agenten wirklich helfen

Ein Wissensagent mit WikiKit, ein Workflow-Agent mit SubKit und ein Publishing-Agent für ContentKit klingen nach einer sauberen Rollenverteilung. Technisch lassen sie sich hinter einem gemeinsamen Agenten-Host koordinieren. A2A setzt eine andere Grenze: Ein Agentensystem delegiert einen begrenzten Auftrag an ein eigenständig laufendes anderes System. WorkKit und CodeKit besitzen konkrete A2A-1.0-Oberflächen mit Agent Card und Task-Lebenszyklus. Das ist kein Grund, jeden internen Produktaufruf in eine Agentendelegation umzubauen.

Diese zusätzliche Grenze lohnt sich, wenn die Agenten verschiedenen Teams oder Organisationen gehören, eigene Laufzeiten und Sicherheitsbereiche besitzen oder einen Auftrag unabhängig weiterführen müssen. Für die bekannte Folge „Wissen lesen, Vorschau bauen, prüfen, veröffentlichen“ wäre sie unnötig. Ein versionierter SubKit-Workflow benötigt dafür keine eigenständigen Agentenlaufzeiten und bindet Eingaben, Kontrollfolge und Freigabepunkte an eine konkrete Version.

ContentKits nativer MCP-Server bestätigt genau diese Trennung. Er bietet wenige fachliche Fähigkeiten samt OAuth, Scopes, Ressourcen und Risikohinweisen, während HTTP und OpenAPI parallel bestehen bleiben. Die zusätzliche Oberfläche schafft keine zweite Datenhaltung und keinen zweiten Veröffentlichungsstand.

Die Entscheidung folgt der Wirkung

Die Wirkung bestimmt die Integration:

  • Ist der Auftrag neu und begleitet ein Mensch jeden Schritt? Dann direkt verbinden.
  • Besitzt das Ziel eine fachliche MCP-Oberfläche? Dann diese für begleitete Agentenarbeit nutzen; OpenAPI bleibt für feste Dienste und Workflows verfügbar.
  • Spricht der Host nur MCP, während das Ziel ausschließlich eine gute OpenAPI liefert? Dann ausgewählte Operationen adaptieren.
  • Wiederholt sich der Ablauf oder schreibt er in produktive Systeme? Dann als SubKit-Workflow festschreiben.
  • Soll eine bestätigte Zustandsänderung den Lauf starten? Dann einen signierten Webhook als Signal verwenden und den Stand nachlesen.
  • Arbeiten wirklich unabhängige Agentensysteme über eine dauerhafte Aufgabengrenze zusammen? Erst dann A2A prüfen.

Das Zusammenspiel funktioniert, solange die Produktgrenzen erhalten bleiben. WikiKit macht aus Quellen geprüftes Wissen. ContentKit macht aus einem freigegebenen Stand eine zugängliche Veröffentlichung. SubKit macht aus mehreren Aufrufen einen wiederholbaren und kontrollierten Vorgang. MCP, HTTP, Webhooks und A2A sind dabei keine konkurrierenden Antworten auf dieselbe Frage. Sie benennen verschiedene Kanten eines Systems.

Der praktische Weg beginnt mit einem Agenten und nur den MCP-Verbindungen, die der Auftrag tatsächlich benötigt. Für den dauerhaften Betrieb gehören Wiederholung, Secrets, Freigaben und Protokollierung in eine geprüfte SubKit-Workflow-Version.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare