content-knowledge-mcp

Ein MCP-Server, der einem Content-Agenten Zugriff auf das redaktionelle Wissen eines Unternehmens gibt: Markenregeln, einen visuellen Vorlagenkatalog und vergangene Beiträge mit ihren Ergebnissen. Das Wissen liegt in einfachen Markdown-Dateien, die dem Unternehmen gehören; der Server stellt es lediglich bereit.

Als technischer Kern meiner Bachelorarbeit über KI-Agenten und Workflow-Automatisierung entstanden. Die Version hier ist die generische Engine, mit einem erfundenen Unternehmen als Beispielwissen.

Warum es keine Vektordatenbank gibt

Der naheliegende Ansatz ist, das Wissen zu embedden und nach Ähnlichkeit abzurufen. Dieser Server tut das bewusst nicht, aus zwei Gründen.

Auf dieser Skala gewinnt die strukturierte Suche über kuratierte Dateien. Die redaktionellen Regeln eines Unternehmens sind einige Dutzend Blöcke, nicht zehntausende. Sie in Chunks zu zerlegen und per Kosinus-Ähnlichkeit abzurufen, fügt einen Indizierungsschritt hinzu, einen Speicher, der synchron gehalten werden muss, und eine Fehlerklasse, die schwer zu erkennen ist – im Tausch für eine Trefferquote, die man bereits hatte.

Jede Regel trägt eine ID, und genau das ist der Punkt. Regeln sind R1, R17, R905; Vorlagen sind T901, T905; Launch-Datensätze sind L2. Der Agent wird angewiesen, die verwendeten IDs zu nennen. Dadurch wird jeder Vorschlag zu etwas, das ein Mensch in Sekunden prüfen kann: Der Reviewer liest rules_used: ["R920", "R903"] und weiß genau, welche Regeln diesen Beitrag erzeugt haben. Ein Embedding liefert einen Absatz, aber kein Argument. Wenn das Ziel eine funktionierende menschliche Prüfinstanz ist, schlägt Nachvollziehbarkeit Cleverness.

Der Preis dafür ist real und sollte ausgesprochen werden: Die Suche ist lexikalisch, eine Abfrage, die mit einer Regel keine Wörter gemeinsam hat, findet sie also nicht. Der Server antwortet mit NO_MATCH, statt so zu tun, als hätte er etwas gefunden – genau dieses Verhalten prüfen die Evaluierungsfälle.

Related MCP server: mcp-guide

Architektur

  Claude Desktop / Claude Code ──stdio──┐
                                        ├──▶ content-knowledge-mcp ──▶ KNOWLEDGE_PATH/
  n8n MCP Client Tool ──────────HTTP────┘         (3 tools)              guidelines/*.md   R# rules, L# launch records
       (host.docker.internal:8765)                                       templates/catalog.md   T# catalog
                                                                         past-posts/*.md        past posts and outcomes

Drei Tools, ein Transportumschalter, kein Zustand:

Der Server besitzt keinerlei Inhalte. Verweist man KNOWLEDGE_PATH auf einen anderen Ordner, bedient er ein anderes Unternehmen – genau das hat es veröffentlichbar gemacht, ohne den Code anzufassen.

Schnellstart

git clone https://github.com/alessandro-martelli/content-knowledge-mcp
cd content-knowledge-mcp
python3 -m venv .venv && .venv/bin/pip install fastmcp

# run the twelve checks against the example knowledge
KNOWLEDGE_PATH=examples/knowledge .venv/bin/python smoke_test.py

# stdio, for Claude Desktop or Claude Code
KNOWLEDGE_PATH=examples/knowledge .venv/bin/python server.py

# HTTP on :8765, for the n8n MCP Client Tool
KNOWLEDGE_PATH=examples/knowledge .venv/bin/python server.py --http

Das Beispielwissen unter examples/knowledge/ ist vollständig erfunden: eine fiktive Designschule mit Regeln, Launch-Datensätzen, einem Vorlagenkatalog und drei vergangenen Beiträgen. Es existiert, damit das Repository für alle lauffähig ist und die Tests etwas haben, an dem sie sich festbeißen können.

Evaluierung

Smoke-Tests: 12/12. Jede Prüfung läuft über einen echten fastmcp.Client über das Protokoll, nicht über die Hilfsfunktionen – ein Bruch in der Tool-Registrierung oder im Transport wird also hier sichtbar.

Agenten-Protokoll: 8 Fälle, 5 davon adversarial (widersprüchliche Regeln, Anfrage außerhalb des Geltungsbereichs, nicht verfügbares Tool, kein passendes Template, unterspezifizierte Eingabe). Ausgeführt im August 2026 gegen die Prompts der beiden Agenten: 6 von 8 bestanden, jede Ausgabe war auf Anhieb gültiges JSON, und die beiden Fehlschläge waren Fehler in der Testsuite, nicht des Agenten. Beide sind in eval/test-log.md festgehalten, jeweils mit dem Fix, den sie brauchen. Das Log bleibt so belassen, wie es entstanden ist: Eine Suite, die ausschließlich Erfolge meldet, misst nichts.

Ehrliche Grenzen

• Die Suche ist lexikalisch und gewichtet nach Termfrequenz. Sie versteht keine Synonyme; eine Regel, die in Wörtern formuliert ist, die die Abfrage nicht verwendet, wird nicht gefunden.

• Das Layout des Wissensordners ist festgelegt (guidelines/, templates/catalog.md, past-posts/), und der Dateiname des Katalogs ist hartkodiert.

• Es gibt keinen Schreibpfad und keinen Cache: Jeder Aufruf liest die Dateien. Bei dieser Größe ist das in Ordnung – bei zehntausend Blöcken wäre es das nicht.

• Die beiden offenen Fehler aus der Evaluierung sind in diesem Code noch nicht behoben: rules_used kann keine L#-Datensätze zitieren, und das Plan-Schema kann keine Zeile mit unbekanntem Kanal ausdrücken.

Lizenz

MIT, siehe LICENSE.