Dense-Mem: Erste Schritte mit dem selbst gehosteten MCP-Memory-Server

Für wen es passt

Dense-Mem richtet sich an Entwickler und Teams, die einem KI-Agenten ein selbst gehostetes Langzeitgedächtnis geben möchten und bereit sind, PostgreSQL und Redis gemeinsam zu betreiben; wer einer Sitzung nur flüchtigen Kontext hinzufügen und keinen Datenbankbetrieb einführen will, für den ist es nicht geeignet. Den Automatisierungsvertrag für das Gedächtnis stellt es nach außen über MCP bereit (Streamable HTTP, Endpunkt /mcp): Exakte Beweise werden zuerst gestaffelt, der semantische Zustand wird serverseitig über validierte Richtlinien abgeleitet, und anschließend gibt der Server aktive Beweiskontexte mit graphförmigen Relationship-Handles zurück. Wissen, Lebenszyklus, Herkunft, Suche, Autorisierung und Audit sehen PostgreSQL als dauerhafte Autorität; Redis koordiniert nur. Browser-Routen sind Erstanbieter-Schnittstellen, kein externer Automatisierungseingang.

Voraussetzungen und ungeeignete Fälle:

• Beim Start muss die Konfiguration für beide KI-Dienste, Embedding und Verifier, vollständig vorliegen (die fünf Variablen weiter unten); einen konfigurationsfreien Modus gibt es nicht.
• Die Nebenwirkung ausgehender Daten muss vor der Nutzung bekannt sein: Beweistexte, Proposal-Kontext und Recall-Abfragen gehen an die von dir konfigurierten Anbieter; bei selbst gehosteten Anbietern bleibt der Datenverkehr in deiner Grenze, bei gehosteten Diensten nicht.
• Die offiziell unterstützten MCP-Clients, der Ressourcenbedarf und die Betriebskosten sind in den Belegen nicht beschrieben und damit unbestätigt.

Der erste Versuch in drei Minuten

Voraussetzungen: eine Maschine, die docker compose ausführen kann; trage POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN und AI_API_KEY in .env ein; der Start verlangt außerdem die vollständige Embedding- und Verifier-Konfiguration: AI_API_URL, AI_API_KEY, AI_API_EMBEDDING_MODEL, AI_API_EMBEDDING_DIMENSIONS und AI_VERIFIER_MODEL — eine offiziell genannte Startvoraussetzung, keine Option.

Hinweis: Auch ein rein lesender Erstversuch schickt Recall-Abfragen an die konfigurierten Anbieter.

Offizieller Hauptweg (Docker Compose):

curl -fsSLo docker-compose.yml \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/docker-compose.base.yml
curl -fsSLo .env.example \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/.env.example

cp .env.example .env
# Fill in POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN, and AI_API_KEY.
${EDITOR:-vi} .env

docker compose up -d

Sobald die Container laufen, binde /mcp in deinen MCP-Client ein. Als ersten Aufruf bietet sich das abfragende recall_memory an: Laut offizieller Beschreibung liefert es aktive Beweiskontexte und Relationship-Handles. Was es auf einer frisch gestarteten Instanz ohne geschriebene Beweise zurückgibt, ist nicht belegt. Erfolgssignale: docker compose up -d läuft fehlerfrei durch, und der Client erreicht den Dienst über /mcp.

Anwendungsfälle

Fall eins: sitzungsübergreifendes Gedächtnis mit Herkunftsnachweis für einen Agenten aufbauen. Szenario: Der Agent soll Fakten über Sitzungen hinweg erinnern und später belegen können, woher sie stammen. Vorgehen: mit remember Beweise schreiben, später mit recall_memory aktive Beweiskontexte abrufen und abgleichen. Parameter und Eingabeformat von remember sind nicht belegt; bestätigt ist nur: „das ist der offizielle Eingang für Beweise“. Erwartetes Ergebnis: der Beweis wird angenommen, und der semantische Zustand wird serverseitig per Richtlinie abgeleitet.

Fall zwei: erklären, wie eine Beziehung entstanden ist. Szenario: einem anderen Menschen oder einem nachgelagerten System die Entstehung einer Relationship zeigen. Vorgehen: trace_memory aufrufen; offiziell beschreibt es das Verfolgen von Beweisen, Entscheidungen und Abstammung entlang genau einer Relationship desselben Teams. Parameter und Rückgabestruktur sind nicht belegt; bestätigt bleibt nur „diese Abfragefähigkeit existiert“ — Beispiele werden hier nicht erfunden.

Nutzungsgrenzen

• Lese-/Schreibcharakter: remember schreibt Beweise; retract_evidence mustert vom Aufrufer eigene Beweise aus und bewahrt die append-only-Herkunft; correct_relationship ersetzt — ausschließlich durch den Owner — eine aktive Relationship (löst das Original ab, bewahrt die Support-Linie). recall_memory, trace_memory und export_memory_pack sind Abfrage-/Export-artig. Offizielle Lese-/Schreib-Flags je Tool fehlen; ob Abfragetools niemals schreiben, ist unbestätigt.
• Der Korrekturweg besteht nur aus Ausmusterung und Ersetzung wie oben; andere Schreibvorgänge sind nicht als widerrufbar zu verstehen.
• Zugangsdaten und Datenebene: über die drei Pflichtwerte in .env hinaus hängt der Betrieb an PostgreSQL (dauerhaft), Redis (Koordination) und externen KI-Anbietern; Beweistexte, Proposal-Kontext und Recall-Abfragen verlassen das System Richtung Anbieter, und ob sie in deiner Grenze bleiben, hängt vom Deployment-Ort ab.
• Unbestätigt: Standardports und vollständige URLs, Datenrückhalte- und Löschpolitik, Team- oder Tenant-Isolationssemantik, Authentifizierungsdetails jenseits von CONTROL_PORTAL_TOKEN.