Getting Started with Dense-Mem, a Self-Hosted MCP Memory Server

Who it is for

Dense-Mem is for developers or teams who want to give their AI agents a self-hosted long-term memory and are willing to operate both PostgreSQL and Redis; if you only want to add temporary context to a session and would rather not take on database operations, it is not the right fit. It exposes its memory automation contract through MCP (Streamable HTTP, endpoint /mcp): it first stages exact evidence, derives semantic state on the server through validated policy, and then returns active evidence contexts with graph-shaped Relationship handles; knowledge, lifecycle, provenance, search, authorization, and audit all treat PostgreSQL as the durable authority, while Redis handles coordination only. Browser routes are first-party interfaces, not an external automation entry point.

Prerequisites and cases where it does not fit:

• Startup requires a complete configuration for both AI services, embedding and verifier (the five variables below); there is no zero-config mode.
• Know the data-egress side effect before you use it: evidence text, proposal context, and recall queries are all sent to the providers you configure; with self-hosted providers the traffic stays within your boundary, with hosted services it does not.
• The officially supported MCP clients, resource requirements, and operating costs are not documented, so these points remain unconfirmed.

First try in three minutes

Prerequisites: a machine that can run docker compose; fill POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN, and AI_API_KEY into .env; startup also requires the complete embedding and verifier configuration: AI_API_URL, AI_API_KEY, AI_API_EMBEDDING_MODEL, AI_API_EMBEDDING_DIMENSIONS, and AI_VERIFIER_MODEL — an officially stated startup requirement, not an optional one.

Note: even a first try that only reads still sends recall queries to the providers you configure.

Official primary path (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

Once the containers are up, connect to /mcp from your MCP client. For a first call, the query-style recall_memory is a good choice: the official description says it returns active evidence contexts and Relationship handles. What it returns on a freshly started instance with no evidence written yet is not documented. Success signals: docker compose up -d completes normally, and the client can reach the service through /mcp.

Use cases

Case one: build cross-session memory with provenance for an agent. Scenario: the agent must remember facts across sessions and later be able to show where they came from. Approach: call remember to write evidence, then use recall_memory to recall active evidence contexts and check them. Evidence does not document remember's parameters or input format, so what can be confirmed stops at "this is the official evidence intake entry point". Expected outcome: the evidence is accepted, and semantic state is derived by server-side policy.

Case two: explain how a relationship came to be. Scenario: show another person or a downstream system how a Relationship was formed. Approach: call trace_memory, officially described as tracing evidence, decisions, and lineage along one same-team Relationship. Parameters and return structure are not documented, so confirmation stops at "this query capability exists"; no examples are invented here.

Boundaries of use

• Read/write nature: remember writes evidence; retract_evidence retires caller-owned evidence while preserving append-only provenance; correct_relationship is owner-only replacement of an active Relationship (it supersedes the original and preserves support lineage). recall_memory, trace_memory, and export_memory_pack are query/export style. The official material does not flag read/write per tool, so whether query tools never write is unconfirmed.
• The correction channel is limited to the retirement and replacement above; other writes should not be assumed reversible.
• Credentials and data plane: beyond the three required .env values, running depends on PostgreSQL (durable), Redis (coordination), and external AI providers; evidence text, proposal context, and recall queries egress to the providers, and whether they stay within your boundary depends on where those providers are deployed.
• Unconfirmed: default ports and full URLs, data retention and deletion policy, team or tenant isolation semantics, and authentication details beyond CONTROL_PORTAL_TOKEN.