MCP

Guía de primer uso de Dense-Mem, el servidor de memoria MCP autoalojado

Dense-Mem encaja con equipos que quieren dar a sus agentes de IA una memoria a largo plazo autoalojada y trazable, asumiendo operar PostgreSQL. Antes de arrancar hay que completar las cinco variables de entorno del proveedor de IA, y los textos de evidencia, el contexto de propuestas y las consultas recall se envían a los proveedores configurados; solo con proveedores autoalojados ese tráfico queda dentro de tu perímetro.

Official source · Dense-Mem

Install

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

Para quién es

Dense-Mem va dirigido a desarrolladores o equipos que quieren dar a sus agentes de IA una memoria a largo plazo autoalojada y están dispuestos a operar PostgreSQL y Redis a la vez; si solo quieres añadir contexto temporal a una sesión sin asumir el mantenimiento de una base de datos, no es la herramienta adecuada. Expone su contrato de automatización de memoria mediante MCP (Streamable HTTP, endpoint /mcp): primero almacena evidencias exactas, el servidor deriva el estado semántico mediante políticas validadas y después devuelve contextos de evidencia activos con handles de Relationship en forma de grafo; el conocimiento, el ciclo de vida, la procedencia, la búsqueda, la autorización y la auditoría tienen en PostgreSQL su autoridad duradera, y Redis se limita a la coordinación. Las rutas del navegador son interfaces de primera parte, no una entrada de automatización externa.

Requisitos previos y casos en los que no encaja:

  • El arranque exige la configuración completa de los dos servicios de IA, embedding y verificador (las cinco variables se ven más abajo); no existe un modo sin configuración.
  • Conoce el efecto secundario de salida de datos antes de usarlo: los textos de evidencia, el contexto de propuestas y las consultas recall se envían a los proveedores que configures; con proveedores autoalojados el tráfico se queda dentro de tu perímetro, con servicios alojados no.
  • El catálogo oficial de clientes MCP compatibles, los requisitos de recursos y los costes de operación no están documentados; quedan sin confirmar.

Primer intento en 3 minutos

Requisitos: una máquina capaz de ejecutar docker compose; rellenar POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN y AI_API_KEY en .env; el arranque exige además la configuración completa de embedding y verificador: AI_API_URL, AI_API_KEY, AI_API_EMBEDDING_MODEL, AI_API_EMBEDDING_DIMENSIONS y AI_VERIFIER_MODEL, un requisito de arranque declarado oficialmente, no algo opcional.

Aviso: un primer intento de solo lectura también envía consultas recall a los proveedores configurados.

Ruta principal oficial (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

Con los contenedores arriba, conecta /mcp desde tu cliente MCP. Para la primera llamada conviene el recall_memory de tipo consulta: la descripción oficial dice que devuelve contextos de evidencia activos y handles de Relationship. Qué devuelve en una instancia recién arrancada sin evidencias escritas no está documentado. Señales de éxito: docker compose up -d termina sin errores y el cliente alcanza el servicio a través de /mcp.

Casos de uso

Caso uno: crear para un agente una memoria entre sesiones con procedencia. Escenario: el agente debe recordar hechos a lo largo de sesiones y poder después justificar su origen. Cómo: llama a remember para escribir evidencias y usa luego recall_memory para recuperar contextos de evidencia activos y verificar. Los parámetros y el formato de entrada de remember no están documentados; solo puede confirmarse que «es la entrada oficial de ingesta de evidencias». Resultado esperado: la evidencia se acepta y el estado semántico lo deriva la política del servidor.

Caso dos: explicar cómo surgió una relación. Escenario: mostrar a otra persona o a un sistema aguas abajo cómo se formó una Relationship. Cómo: llama a trace_memory, descrito oficialmente como el seguimiento de evidencias, decisiones y linaje a lo largo de una misma Relationship del mismo equipo. Los parámetros y la estructura de retorno no están documentados; nos detenemos en «existe esta capacidad de consulta», sin inventar ejemplos aquí.

Límites de uso

  • Índole de lectura/escritura: remember escribe evidencias; retract_evidence retira evidencias propiedad del llamador conservando una procedencia append-only; correct_relationship es el reemplazo, solo para el propietario, de una Relationship activa (sustituye la original y conserva el linaje de soporte). recall_memory, trace_memory y export_memory_pack son de tipo consulta/exportación. No hay marcas oficiales de lectura/escritura por herramienta, así que si las herramientas de consulta nunca escriben queda sin confirmar.
  • El canal de corrección se limita a las dos vías anteriores, retirar y reemplazar; el resto de escrituras no debe entenderse como revocable.
  • Credenciales y plano de datos: además de los tres valores obligatorios de .env, la ejecución depende de PostgreSQL (duradero), Redis (coordinación) y proveedores de IA externos; los textos de evidencia, el contexto de propuestas y las consultas recall salen hacia los proveedores, y que queden en tu perímetro depende de dónde estén desplegados.
  • Sin confirmar: puertos por defecto y URL completas, política de retención y borrado de datos, semántica de aislamiento por equipo o inquilino, y detalles de autenticación más allá de CONTROL_PORTAL_TOKEN.