chemenu/kb/sources/Source - MCP Read Server Implementation Session 2026-09-02.md

type, source_type, author, raw_files, source_language, date, tags, entities, concepts, summary

type	source_type	author	raw_files	source_language	date	tags	entities	concepts	summary
types/source.md	notes	Torben	raw/notes/Conversation Transcript - MCP Read Server Implementation Session 2026-09-02.md	de	2026-09-02		wikitool Chemenu	Publish-Remote Gate Mass-Update Gate Iteration and Cost Limits MCP-Leseserver	Sitzung, die die Sequenz aus Issue #36 umsetzt: Publish-Remote Gate scharf, Lesepfad gehaertet, Root-Aufloesung und Bibliotheksgrenze gezogen, MCP-Leseserver gebaut - vier Versionsstufen 2.2.3 bis 2.4.0, dazu INSTALL-MCP.md und Issue #37.

Source: MCP Read Server Implementation Session 2026-09-02

Autor: Torben
Datum: 2026-09-02
Raw-Dateien: raw/notes/Conversation Transcript - MCP Read Server Implementation Session 2026-09-02.md
Typ: Notes

Zusammenfassung

Diese Sitzung arbeitet die vierstufige Sequenz aus Issue #36 ab, dem Sammel-Issue für den Weg zum MCP-Leseserver: #34 (Publish-Remote-Gate scharf stellen), #33 (Lesepfad vor der Exposition härten), #31 (Root-Auflösung von der Importzeit lösen und eine Bibliotheksgrenze ziehen), #19 (der Leseserver selbst). Jeder Schritt endet mit einem Versions-Bump und einem Testlauf; die Reihenfolge folgt dem Master-Issue, weil #33 dieselben Dateien anfasst, die #31 strukturell umbaut, und #31 die Grenze liefert, auf der #19 aufsetzt.

.wikitool-remotes.json fehlte in diesem Checkout trotz Dokumentation, die das Gegenteil behauptete - angelegt und gegen ein erfundenes Ziel gegengeprüft (Exit 42). Der Lesepfad bekam sechs Fixes gegen einen 267-Byte-YAML-Alias, der zu 672.603 Knoten expandiert, gegen einen ReDoS-Zweig in der Ranking-Funktion, einen fehlenden Subprozess-Timeout, und einen Korpus-Cache, der nie einen schmutzigen Arbeitsbaum cacht. config.ROOT und alle abgeleiteten Pfade waren zur Importzeit gebunden; die Auflösung ist jetzt lazy (CHEMENU_ROOT → Walk-up), und der reine Lesekern (search/service.py, lint_core.py, types_core.py) importiert kein typer mehr. Der MCP-Server (tools/chemenu/mcp/) exponiert search/types/describe_type/lint/status über chemenu.api.Corpus - strukturell ohne Schreibpfad, mit Commit-Stempel auf jeder Antwort und einer Startverweigerung, falls Telemetrie in den bedienten Baum schreiben würde.

Nach Freigabe des 37-Datei-Changesets (Mass-Update-Gate, Token 46442f4419c1) folgten INSTALL-MCP.md für Menschen, ein Verweis auf die separate Traefik-ForwardAuth-Middleware (gitea-mcp-forward-auth), und Issue #37 für das noch fehlende Container-Image - mit den konkreten CI-Vorlagen aus gitea-mcp-forward-auth (Registry-Push) und gitea-mcp (Dockerfile-Form, aber DockerHub statt der eigenen Registry). Alle vier Sequenz-Issues wurden geschlossen, #36 blieb offen, weil sein eigenes Abschlusskriterium - ein Konsument, der nachweislich über die Middleware antwortet - erst mit #37 erfüllbar ist.

Kernaussagen

• Gemessen: Korpus-Parse 265 ms → 54 ms (CSafeLoader), wikitool search end-to-end 593 ms → 347 ms; die verbleibenden ~262 ms sind Modulimport und entfallen erst im residenten MCP-Prozess.
• Der ReDoS-Zweig (_contains mit re.search gegen nutzergesteuerten Regex) wurde gelöscht, nicht begrenzt - rg wendet das Muster ohnehin mit einer linearen Engine an, bevor die Funktion je läuft.
• monkeypatch.setattr(config, "ROOT", ...) baute nach der lazy-Auflösung die stale Bindung beim Teardown wieder auf, weil es den aufgelösten alten Wert zurückschreibt - config.reset() musste dazukommen, in derselben autouse-Fixture, die das Problem eine Ebene höher (Umgebungsvariablen) bereits kannte.
• Der MCP-Server hat keinen Schreibpfad, weil chemenu.api nichts unter chemenu.commands importiert - nicht, weil eine Liste gefiltert wird. Ein Test importiert das Servermodul in einem frischen Interpreter und prüft sys.modules.
• Ein Stempel-Bug wurde beim Schreiben des Golden-Tests selbst gefunden: _stamp() fragte nach der aktuellen statt der beim Laden tatsächlich gelesenen Revision und hätte bei einem minimal verzögerten zweiten Zugriff commit: null auf einem sauberen Baum liefern können.
• gitea-mcp ist als Registry-Vorlage ungeeignet - sein Release-Workflow pusht nach DockerHub (Fork des Upstream), nicht in die eigene Gitea-Registry.

Aufgaben

• #34, #33, #31, #19 umgesetzt und mit Abschlusskommentar geschlossen
• INSTALL-MCP.md geschrieben, in INSTALL.md/README.md verlinkt, in dist export aufgenommen
• Issue #37 (Container-Image) angelegt, mit neun offenen Entscheidungen benannt
• #37 selbst umsetzen
• #36 schließen, sobald #37 den Middleware-Nachweis liefert
• #23 (Env-Var-Erzwingung) - CHEMENU_ROOT wurde von Hand in _WIKITOOL_ENV eingetragen
• kb/entities/tools/qmd.md - falsche Sprachangabe, in dieser Sitzung nur vermerkt, Fix in separater Transkript-Sitzung

Nicht übernommen

• Der vollständige Wortlaut der geprüften Docstrings, Kommentare und Testfälle - das Transkript benennt Dateien und die tragenden Eigenschaften, der Code selbst ist die Quelle.
• Die exakten neun offenen Entscheidungspunkte aus Issue #37 (Korpus im Image vs. Volume, Basis-Image, Healthcheck etc.) - dort bereits vollständig dokumentiert, hier nicht dupliziert.
• Der Wortlaut der abgerufenen READMEs von gitea-mcp-forward-auth und gitea-mcp - nur die für die Entscheidung relevanten Fakten (Config-Variablen, Workflow-Form, Registry-Ziel) wurden übernommen.

Verwandte Entities

• wikitool
• Chemenu

Verwandte Concepts

• Publish-Remote Gate
• Mass-Update Gate
• Iteration and Cost Limits
• MCP-Leseserver