Source - MCP Read Server Implementation Session 2026-09-02
0.50
0.50
sourced
Zweiter Konsument von chemenu ueber MCP: search/types/describe_type/lint/status auf chemenu.api.Corpus, strukturell ohne Schreibpfad, jede Antwort trage einen Commit-Stempel.
MCP-Leseserver
Typ: Architecture
Definition
Ein zweiter Konsument desselben Kerns, nicht ein zweites Programm: tools/chemenu/mcp/ exponiert
search, types, describe_type, lint und status über MCP, indem es dieselben Funktionen
aufruft, die wikitool auch aufruft - vermittelt durch chemenu.api.Corpus, den In-Process-
Einstiegspunkt. Ein Golden-Test hält die Ausgaben beider Wege gegeneinander, statt darauf zu
vertrauen, dass sie übereinstimmen.
Kernpunkte
Kein Schreibpfad, strukturell. Weder der Server noch chemenu.api importiert etwas unter
chemenu.commands - new, touch, xref, publish, migrate sind aus diesem Prozess
heraus nicht erreichbar, statt aus einer Liste gefiltert zu werden. Ein Test importiert das
Servermodul in einem frischen Interpreter und prüft
sys.modules.1
Zwei Transports.stdio zum Entwickeln und Testen ohne Netz; streamable-http für die
Auslieferung, der einzige, vor den sich ein HTTP-Reverse-Proxy setzen kann. sse ist über das
SDK erreichbar und wird bewusst nicht angeboten - der abgelöste Remote-Transport, jetzt darauf
zu bauen verschiebt den Wechsel nur.
Jede Antwort trägt den Commit, aus dem sie berechnet wurde (commit, as_of). Ein
veralteter Checkout antwortet sonst selbstbewusst falsch. null heißt: der bediente Baum hat
uncommittete Änderungen, die Antwort entspricht keiner Revision. Der Stempel ist die Revision,
aus der die Seiten tatsächlich gelesen wurden, nicht die zum Zeitpunkt des Stempelns aktuelle
ein Bug, der genau diesen Unterschied überging, wurde beim Schreiben des Golden-Tests selbst
gefunden und behoben.1
Telemetrie in den bedienten Baum wird beim Start verweigert, nicht still umgeleitet. Der
Sync, der den Checkout aktuell hält (git fetch && git reset --hard), darf reports/telemetry/
wegräumen; ein Trace, der dort landet, wäre ein Verlust und eine stille Möglichkeit, den Baum
zu beschmutzen, dessen Sauberkeit der Korpus-Cache prüft.
Kein Iteration Budget Gate im Server. Das Gate begrenzt eine Agenten-Session am unbemerkten
Iterieren über den Wiki-Zustand, nicht einen Nutzer, der oft sucht - Retrieval ist deshalb
bereits generell davon ausgenommen (siehe Iteration and Cost Limits). Rate Limiting gehört
stattdessen vor den Prozess, neben die Authentifizierung.
Authentifizierung ist Middleware, nicht Servercode. Eine Traefik-ForwardAuth-Instanz
(Bearer-Token gegen SHA-256-Hashes) sitzt vor dem Prozess; nicht sauber authentifizierte
Zugriffe erreichen Python gar nicht erst.
Gemessen: Korpus-Parse für 176 Seiten 265 ms → 54 ms (CSafeLoader),
wikitool search end-to-end 593 ms → 347 ms; die verbleibenden ~262 ms sind Modulimport und
entfallen im residenten Serverprozess, weil er ihn einmal pro Start statt pro Aufruf
zahlt.1
Beispiele
search/types/describe_type/lint/status als die fünf Tools - siehe
tools/chemenu/mcp/server.py.
Der Korpus-Cache (chemenu/corpus_cache.py) hält einen Parse pro Commit und cacht nie einen
schmutzigen Arbeitsbaum - dieselbe Eigenschaft, die den Antwort-Stempel korrekt hält.
chemenu.api.Corpus: nimmt einen Root, liefert exakt die --json-Formen der CLI, raised statt
zu exitieren.
Wann zu verwenden
Ein Konsument, der keine Shell auf der bedienenden Maschine ist, soll dieselben Fragen stellen
können wie ein Agent, der wikitool direkt aufruft.
Mehrere gleichzeitige Leser eines Korpus, für die ein Prozess pro CLI-Aufruf (Modulimport,
Korpus-Parse) unnötigen Overhead bedeutet.
Wann NICHT zu verwenden
Als Ort für einen Schreibpfad - die Ingest-Queue (geplant, Issue #32) ist ein anderes Design
mit einer Quarantäne davor, nicht eine Erweiterung dieses Servers.
Als Ersatz für den Iteration Budget Gate oder das Traefik-Rate-Limiting - beide bleiben
notwendig und leben an anderer Stelle.
torben
f7597b209c