Dense-Mem : guide de première prise en main du serveur MCP de mémoire auto-hébergé

À qui cela s'adresse

Dense-Mem s'adresse aux développeurs ou équipes qui veulent donner à leurs agents IA une mémoire long terme auto-hébergée et acceptent d'exploiter à la fois PostgreSQL et Redis ; si vous cherchez seulement à ajouter du contexte temporaire à une session sans prendre en charge l'exploitation d'une base de données, ce n'est pas le bon outil. Il expose son contrat d'automatisation mémoire via MCP (Streamable HTTP, point de terminaison /mcp) : il met d'abord en attente des preuves exactes, dérive l'état sémantique côté serveur via des politiques validées, puis renvoie des contextes de preuve actifs avec des handles Relationship en forme de graphe ; connaissance, cycle de vie, traçabilité, recherche, autorisation et audit ont tous PostgreSQL comme autorité durable, et Redis ne sert qu'à la coordination. Les routes navigateur sont des interfaces de première partie, pas une entrée d'automatisation externe.

Prérequis et cas inadaptés :

• Au démarrage, la configuration des deux services d'IA, embedding et vérificateur, doit être complète (les cinq variables ci-dessous) ; il n'existe pas de mode sans configuration.
• L'effet de bord de sortie de données doit être connu avant usage : textes de preuve, contexte de proposition et requêtes recall sont envoyés aux fournisseurs que vous configurez ; chez un fournisseur auto-hébergé, le trafic reste dans votre périmètre, chez un service hébergé, non.
• La liste officielle des clients MCP pris en charge, les besoins en ressources et les coûts d'exploitation ne sont pas documentés ; ces points restent non confirmés.

Premier essai en trois minutes

Prérequis : une machine capable d'exécuter docker compose ; renseignez POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN et AI_API_KEY dans .env ; le démarrage exige en outre une configuration complète d'embedding et de vérificateur : AI_API_URL, AI_API_KEY, AI_API_EMBEDDING_MODEL, AI_API_EMBEDDING_DIMENSIONS et AI_VERIFIER_MODEL — un prérequis de démarrage énoncé officiellement, pas une option.

Rappel : un premier essai en lecture seule envoie lui aussi des requêtes recall aux fournisseurs configurés.

Chemin principal officiel (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

Une fois les conteneurs lancés, connectez /mcp dans votre client MCP. Pour un premier appel, préférez le recall_memory de type requête : sa description officielle dit qu'il renvoie des contextes de preuve actifs et des handles Relationship. Ce qu'il renvoie sur une instance toute neuve sans preuve écrite n'est pas documenté. Signaux de réussite : docker compose up -d se déroule sans erreur, et le client atteint le service via /mcp.

Cas d'usage

Cas un : bâtir pour un agent une mémoire inter-sessions avec traçabilité. Scénario : l'agent doit retenir des faits au fil des sessions et pouvoir ensuite en citer la provenance. Démarche : appelez remember pour écrire des preuves, puis utilisez recall_memory pour rappeler les contextes de preuve actifs et vérifier. Les paramètres et le format d'entrée de remember ne sont pas documentés ; on peut seulement confirmer que « c'est l'entrée officielle d'ingestion de preuves ». Résultat attendu : la preuve est acceptée, l'état sémantique est dérivé par la politique côté serveur.

Cas deux : expliquer comment une relation est née. Scénario : montrer à quelqu'un ou à un système aval comment une Relationship s'est formée. Démarche : appelez trace_memory, décrit officiellement comme suivant une même Relationship d'une même équipe à travers preuves, décisions et lignée. Paramètres et structure de retour ne sont pas documentés ; on s'arrête à « cette capacité de requête existe », sans inventer d'exemple ici.

Limites d'usage

• Nature lecture/écriture : remember écrit des preuves ; retract_evidence retire des preuves appartenant à l'appelant en préservant une traçabilité append-only ; correct_relationship remplace, réservé au propriétaire, une Relationship active (elle remplace l'originale et préserve la lignée de support). recall_memory, trace_memory et export_memory_pack sont de type requête/export. Aucun indicateur lecture/écriture par outil n'est donné officiellement ; savoir si les outils de requête n'écrivent jamais reste non confirmé.
• Le canal de correction se limite aux deux mécanismes ci-dessus, retrait et remplacement ; les autres écritures ne doivent pas être tenues pour réversibles.
• Identifiants et plan des données : au-delà des trois valeurs obligatoires de .env, l'exécution dépend de PostgreSQL (durable), Redis (coordination) et de fournisseurs d'IA externes ; textes de preuve, contexte de proposition et requêtes recall sortent vers les fournisseurs, et rester ou non dans votre périmètre dépend de leur lieu de déploiement.
• Non confirmé : ports par défaut et URL complètes, politique de conservation et de suppression des données, sémantique d'isolement d'équipe ou de locataire, détails d'authentification au-delà de CONTROL_PORTAL_TOKEN.