MCP für kuratiertes Wissen

Diesen Beitrag anhören (8 Min.)

Ein Agent soll die Retry-Regel des Teams finden. Dafür braucht er keine Datenbankverbindung und keinen Dump aller Konzept-Seiten. Er braucht wenige klar benannte Fähigkeiten: den passenden Wissenskontext wählen, suchen, lesen, Herkunft prüfen und bei einer neuen Erkenntnis einen Vorschlag anlegen. Genau diese Fähigkeiten stellt WikiKit über das Model Context Protocol bereit.

Stand 18. August 2026 gilt das Folgende für WikiKit 0.47.1. Der MCP-Server läuft per Streamable HTTP und greift auf denselben kuratierten Wissensbestand zu wie die REST-API und das Cockpit. Damit entsteht neben REST und Cockpit kein eigener Wissenszustand. MCP stellt Kontextwahl, Suche, Lesen, Herkunftsprüfung und Vorschläge als aufrufbare Werkzeuge bereit.

Drei Zugänge, derselbe Wissensbestand

WikiKit stellt Kontextwahl, Suche, Lesen, Herkunft, Entscheidungen, Historie, Ingest, Vorschläge und Review über getrennte MCP-Werkzeuge bereit. Zu den Werkzeugen des geprüften Stands gehören beispielsweise wikikit_context, wikikit_search, wikikit_read, wikikit_ingest und wikikit_ingest_status.

Ein Ingest über MCP erzeugt einen ausstehenden ChangeProposal, dessen Freigabe eine getrennte menschliche Entscheidung bleibt. Damit gelten für diesen Zugang dieselben Review- und Herkunftsregeln wie für die übrigen Zugänge zum kuratierten Wissen.

Werkzeuge bilden fachliche Verben ab

Ein konkreter Teil des aktuellen Vertrags ist die Trennung von Kontextwahl und Suche. Ob diese Werkzeuge einem Client angezeigt werden, hängt von den Scopes des Tokens ab. Eine Space-Bindung begrenzt zusätzlich, in welchen Wissensräumen der Client arbeiten kann. Aus einem verfügbaren Suchwerkzeug folgt daher nicht, dass derselbe Agent auch Ingest- oder Review-Werkzeuge sieht.

Die Trennung macht sichtbar, welchen Vorgang ein Agent ausführt. Suche, Lesen und Herkunft bleiben eigenständige Operationen, statt hinter einem Universalwerkzeug wie ask_wiki_everything zu verschwinden. Dadurch muss ein einzelner Aufruf nicht zugleich Recherche, Auswahl und Herkunftsprüfung verbergen.

flowchart LR
    K["Kontextwahl<br/>(Space)"] --> S["Suche"]
    S --> R["Lesen"]
    R --> H["Herkunft<br/>Entscheidungen · Historie"]
    H --> A{"neue belegte<br/>Erkenntnis?"}
    A -->|nein| E["Aufgabe beantworten"]
    A -->|ja| I["Ingest oder<br/>strukturierter Vorschlag"]
    I --> P["wartender ChangeProposal"]
    P --> M["menschliche Review-Entscheidung"]

Das Diagramm zeigt einen möglichen Arbeitsweg, keine verpflichtende Reihenfolge für jede Sitzung. Für Agenten bietet sich ein defensiver Ablauf an: zunächst suchen, anschließend relevante Inhalte lesen und bei Bedarf deren Herkunft prüfen. Fehlt eine belastbare Grundlage, darf die Antwort nicht als kuratiertes WikiKit-Wissen ausgegeben werden.

Kontextwahl und erreichbare Spaces

Ein WikiKit-Dienst kann mehrere Spaces bereitstellen. Die Kontextwahl ist dafür ein eigenes MCP-Werkzeug. Sie ist relevant, wenn ein Token mehrere Spaces erreichen darf; eine Space-Bindung kann den erreichbaren Bestand dagegen bereits auf einen bestimmten Space begrenzen.

Scope und Space-Bindung begrenzen unterschiedliche Aspekte des Zugriffs. Scopes bestimmen, welche Werkzeuge ein Token verwenden darf. Eine vorhandene Space-Bindung schränkt ein, welche Wissensräume erreichbar sind. Die Kontextwahl muss deshalb nicht zwingend am Anfang jeder Sitzung stehen.

Scope bestimmt die sichtbare Werkzeugliste

Die sichtbaren MCP-Werkzeuge ergeben sich aus den Scopes des Tokens. Fehlt eine Berechtigung, bietet der Server das betreffende Werkzeug nicht in der Werkzeugliste an. Erreichbare Spaces können zusätzlich durch die Bindung des verwendeten Schlüssels begrenzt sein.

Diese Filterung wirkt auf der technischen Schnittstelle und nicht nur als Anweisung im Prompt. Der Agent sieht das Werkzeug nicht in der Werkzeugliste; ein dennoch übermittelter Aufruf darf die Autorisierungsprüfung nicht umgehen. So begrenzen Scopes und Space-Bindung die verfügbaren Fähigkeiten und Wissensräume.

Für Agentenschlüssel sollten die Berechtigungen entsprechend knapp zugeschnitten sein. Das Recht, Material einzulesen oder einen Vorschlag anzulegen, umfasst nicht die menschliche Review-Entscheidung. Die Freigabe bleibt einem Zugang vorbehalten, über den eine Person den konkreten ChangeProposal prüft und entscheidet.

Ingest ist asynchron und endet in einem ChangeProposal

Ingest läuft asynchron. wikikit_ingest antwortet mit einer ingest_id und verweist auf wikikit_ingest_status. Der Agent fragt diesen Status ab, bis ein Endzustand wie done oder failed erreicht ist. Ein erfolgreicher Lauf kann einen ausstehenden ChangeProposal liefern, aber kein unmittelbar freigegebenes Wissen.

Diese Unterscheidung muss ein Agent korrekt wiedergeben. Nach dem Ingest kann er berichten, dass ein Änderungsvorschlag zur Prüfung vorliegt. Er darf dagegen noch nicht behaupten, das kuratierte Wissen sei aktualisiert. Dafür fehlt zu diesem Zeitpunkt die getrennte menschliche Freigabe.

Neben Ingest stellt WikiKit Werkzeuge für Vorschläge bereit. Auch dieser Weg umgeht die Prüfung nicht. Der daraus entstehende ChangeProposal bleibt ausstehend, bis ein Mensch ihn freigegeben oder abgelehnt hat.

Die Freigabe verlangt eine menschliche Entscheidung

Ein Agent darf die Freigabe eines Änderungsvorschlags nicht aus dem Gesprächsverlauf ableiten.

Suche, Lesen, Herkunftsprüfung, Ingest und das Anlegen eines Vorschlags sind ohne menschliche Review-Entscheidung möglich. Erst der Übergang vom ausstehenden ChangeProposal zum gemeinsam geltenden Wissen verlangt die Entscheidung einer Person.

Zwei Zugänge zur Authentifizierung

Interaktive entfernte Clients können OAuth verwenden. API-Schlüssel bleiben davon unabhängig als Zugang für lokale oder nicht interaktive Integrationen bestehen.

Ein lokaler Coding-Agent oder ein fester Dienst kann einen eng zugeschnittenen API-Schlüssel verwenden – mit minimalen Scopes und, wo passend, einer Space-Bindung. Die Wahl des Anmeldewegs ersetzt in keinem Fall die Begrenzung der erreichbaren Werkzeuge und Spaces.

Wann REST der einfachere Weg bleibt

MCP ersetzt nicht jeden API-Client. Ein geplanter Workflow, der stündlich einen festen Pfad abfragt, braucht keine Werkzeugentdeckung und keine Agentensitzung. Er kann die REST-API mit einem eng begrenzten Credential und einem deterministischen HTTP-Schritt verwenden.

MCP passt zu Aufgaben, bei denen ein Agent während der Bearbeitung zwischen Wissensfähigkeiten wählen muss: gegebenenfalls einen Space als Kontext setzen, suchen, lesen, Herkunft prüfen oder einen Vorschlag einreichen. Die konkrete Folge dieser Schritte ergibt sich aus der Aufgabe und muss nicht als fester HTTP-Ablauf vorgegeben sein.

REST, MCP und Cockpit bestehen im selben System nebeneinander. Ein Workflow nutzt REST, ein Coding-Agent MCP und eine prüfende Person das Cockpit. Alle drei greifen auf denselben kuratierten Wissensbestand zu.

Wenige Verben, klare Verantwortung

WikiKit spiegelt nicht jede REST-Route als MCP-Werkzeug. Es bietet die Vorgänge an, die ein Agent für den Zugriff auf kuratiertes Wissen benötigt: Kontext wählen, suchen, lesen, Herkunft prüfen, Material einlesen und Änderungen vorschlagen. Review-Werkzeuge sind ebenfalls scope-gesteuert, die Entscheidung selbst bleibt menschlich.

Für den Betrieb sind drei Entscheidungen nötig: welche Spaces ein Token erreichen darf, welche Scopes es trägt und wer die entstehenden ChangeProposals prüft. Die erste Entscheidung begrenzt den Wissensraum, gegebenenfalls über eine Space-Bindung. Die zweite bestimmt die sichtbaren Werkzeuge. Die dritte bleibt bei einem Menschen – als ausdrückliche Entscheidung über den konkreten Änderungsvorschlag, nicht als Ableitung aus einem Chatverlauf.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare