¿Qué es Memory (reference server)?
Memory es uno de los siete servidores de referencia que se siguen manteniendo en modelcontextprotocol/servers; no se ha trasladado a servers-archived. Guarda lo que aprende un modelo como un pequeño grafo de conocimiento: entidades (una persona, un proyecto), relaciones dirigidas entre ellas y breves observaciones de texto asociadas a cada entidad. Nueve herramientas crean, leen, buscan y borran esos registros, y el grafo completo también se expone como el recurso memory://knowledge-graph.
El grafo vive en un único archivo JSONL local, que se define con MEMORY_FILE_PATH; por defecto está en el propio directorio de instalación del servidor. Se ejecuta con npx -y @modelcontextprotocol/server-memory, que necesita Node.js 24 o posterior desde la versión 2.0.0 (19 de octubre de 2026), o con la imagen de Docker mcp/memory y un volumen con nombre. No hace falta cuenta ni clave.
Cómo instalar Memory (reference server)
npx -y @modelcontextprotocol/server-memory¿Merece la pena Memory (reference server)?
Memory es un punto de partida sólido e inspeccionable para la memoria personal de un agente, y encaja mal cuando el grafo supera lo que un modelo puede repasar por encima. Su fuerza es que no hay nada oculto: la memoria es un archivo de texto que puedes abrir, comparar, copiar o borrar, y nada sale de la máquina.
La recuperación es la parte débil. En el código fuente, search_nodes es una coincidencia de subcadenas sin distinguir mayúsculas sobre nombres, tipos y texto de las observaciones, con consultas limitadas a 2.048 caracteres, y sin embeddings ni ordenación. Si preguntas por 'mi jefe' y la observación dice 'reports to Priya', no vuelve nada. read_graph lo evita devolviéndolo todo, lo que sirve para unas pocas decenas de entidades y se convierte en una factura de contexto a medida que crece el archivo. Los servicios de memoria dedicados, y la memoria integrada en muchas apps de chat y agentes de programación, intentan la recuperación semántica que este servidor no hace.
Las versiones recientes corrigieron los problemas de pérdida de datos que hacían arriesgado compartirlo. Desde la versión 1.0.0, cada herramienta de escritura toma un archivo de bloqueo, así que dos clientes que apuntan al mismo archivo ya no descartan los cambios del otro; las líneas que el servidor no puede analizar se conservan en lugar de borrarse en el siguiente guardado; y el archivo mantiene permisos 0600. El bloqueo depende de la creación exclusiva de archivos, así que el README advierte de que un sistema de archivos en red sigue sin poder compartirse con seguridad.
El modelo decide qué recordar, y eso es a la vez el diseño y el riesgo. Sin un prompt de sistema que le diga cuándo guardar y cuándo consultar, la recuperación es irregular, y un texto que el agente ha leído en un correo o una página web puede escribirse como observación y reaparecer en cada sesión posterior. La issue #4117 pide cuotas, redacción de datos sensibles y salvaguardas en las operaciones destructivas; nada de eso se ha publicado.
Dónde se gana su sitio
Un desarrollador en solitario que usa Claude Desktop y Claude Code en un mismo portátil
Que ambos clientes recuerden las convenciones del proyecto y a las personas entre sesiones
Apunta ambos al mismo MEMORY_FILE_PATH; el archivo de bloqueo serializa las escrituras para que ninguno pierda los cambios del otro. Es gratis y local, pero la recuperación depende de un prompt de sistema que pida al modelo buscar en la memoria al inicio de cada chat.
Una ingeniera de plataforma que prototipa una capa de memoria para agentes
Probar un modelo de memoria de entidades y relaciones antes de comprometerse con un almacén vectorial
El formato JSONL es fácil de inspeccionar y migrar, así que los experimentos solo cuestan tiempo. Cuenta con sustituirlo cuando las consultas tengan que coincidir por significado y no por palabras exactas, o cuando varios usuarios compartan una misma memoria.
Un revisor de seguridad que aprueba servidores MCP para un equipo de ingeniería de 50 personas
Decidir si la plantilla puede ejecutar un servidor de memoria en los portátiles de trabajo
Todo se queda en un archivo en el portátil, así que no hay ningún encargado del tratamiento externo que evaluar. Los riesgos que hay que sopesar son el texto inyectado que persiste entre sesiones y la ubicación por defecto del archivo; exigir MEMORY_FILE_PATH en una ruta cifrada y con copia de seguridad resuelve lo segundo.
Antes de decidirte
- Puesta en marcha
- Añade npx -y @modelcontextprotocol/server-memory a la configuración del cliente (el README tiene fragmentos para Claude Desktop y VS Code) y define MEMORY_FILE_PATH; desde 2.0.0 hace falta Node.js 24+. Las herramientas funcionan tras reiniciar, pero una recuperación útil necesita un prompt de sistema que indique al modelo cuándo leer y escribir.
- Integraciones
- Nueve herramientas: create_entities, create_relations, add_observations, delete_entities, delete_observations, delete_relations, read_graph, search_nodes y open_nodes. Seis de las nueve escriben; el grafo también es un recurso MCP al que suscribirse.
- Datos y privacidad
- Solo lee y escribe su archivo JSONL; sin red ni credenciales. Cualquier cosa que haya leído el agente se puede guardar como observación y volver a introducirse en chats posteriores, así que una prompt injection puede sobrevivir a la sesión que la trajo.
- Coste a escala
- Gratis, sin límites de peticiones. El coste es el contexto: read_graph devuelve el grafo entero, así que su coste en tokens crece con cada entidad y observación guardada.
- Límites
- Búsqueda por subcadenas, consultas limitadas a 2.048 caracteres; sin embeddings, ordenación, acceso multiusuario ni cuotas. No es seguro en sistemas de archivos en red; en 2.0.0, un solo mensaje JSON-RPC de más de 10 MiB cierra la conexión stdio.
Lo bueno
- La memoria es un único archivo JSONL local que puedes leer y editar
- El bloqueo de escritura desde 1.0.0 evita actualizaciones perdidas entre clientes
- Sin cuenta, clave ni acceso a red
Lo malo
- Solo búsqueda por subcadenas, sin recuperación semántica
- Depende de pedir al modelo que guarde y busque
- Sin cuotas ni redacción; el texto inyectado puede persistir
Ideal para
Aficionados y desarrolladores que están aprendiendo cómo funciona la memoria persistente sobre MCP.
Alternativas a Memory (reference server)
Memory (reference server): preguntas frecuentes
- ¿Merece la pena Memory (reference server)?
- Un archivo local legible y una búsqueda por subcadenas lo convierten en un cuaderno aceptable para un agente, y en una memoria a largo plazo floja cuando el grafo crece. Le damos un 3.5 sobre 5.
- ¿Cuánto cuesta Memory (reference server)?
- Gratis y de código abierto.
- ¿Qué inconvenientes tiene Memory (reference server)?
- Solo búsqueda por subcadenas, sin recuperación semántica; depende de pedir al modelo que guarde y busque; sin cuotas ni redacción; el texto inyectado puede persistir.
- ¿Para quién es Memory (reference server)?
- Aficionados y desarrolladores que están aprendiendo cómo funciona la memoria persistente sobre MCP.
- ¿Cuánto cuesta Memory (reference server) para un equipo o en producción?
- Gratis, sin límites de peticiones. El coste es el contexto: read_graph devuelve el grafo entero, así que su coste en tokens crece con cada entidad y observación guardada.
- ¿Es Memory (reference server) seguro para los datos de la empresa?
- Solo lee y escribe su archivo JSONL; sin red ni credenciales. Cualquier cosa que haya leído el agente se puede guardar como observación y volver a introducirse en chats posteriores, así que una prompt injection puede sobrevivir a la sesión que la trajo.
- ¿Cuáles son las mejores alternativas a Memory (reference server)?
- Las alternativas más cercanas que hemos analizado son Sequential Thinking (reference server), Filesystem (reference server) y MCP Memory Keeper.
Respuestas comprobadas el 23 oct 2026.