Agent Memory
Un MCP de sistema de archivos para la memoria del agente
Servidor MCP que expone agent-memory-daemon a cualquier cliente compatible con MCP: Kiro (CLI e IDE), Claude Desktop, Cursor y otros.
El demonio realiza el trabajo de pensamiento (consolidación + extracción); este servidor es un puente ligero al sistema de archivos para que los agentes puedan leer, añadir y buscar en la memoria a través del Protocolo de Contexto de Modelo.
Cómo funciona en conjunto
┌──────────────┐ MCP/stdio ┌────────────────────┐ filesystem ┌────────────────────────┐
│ Kiro / Claude│ ◄───────────────► │ mcp-server-memory │ ◄─────────────────► │ agent-memory-daemon │
│ / Cursor │ │ (this package) │ ~/.agent-memory/ │ (runs in background) │
└──────────────┘ └────────────────────┘ └────────────────────────┘El servidor MCP lee/escribe archivos bajo
~/.agent-memory/El demonio observa el mismo directorio y ejecuta pases de consolidación + extracción
Nunca se comunican directamente entre sí: el sistema de archivos es el contrato
Related MCP server: Recall
Herramientas expuestas
Herramienta | Propósito |
| Carga el índice |
| Escribe un resumen de sesión para que el demonio extraiga memorias más tarde |
| Búsqueda de subcadenas en los archivos de memoria |
| Comprueba si el demonio de consolidación está en ejecución (solo macOS LaunchAgent) |
Instalación
npm install -g mcp-agent-memoryInicio rápido (asistente interactivo)
La forma más rápida de configurar todo (directorio de memoria, demonio, configuraciones de cliente, registros y LaunchAgent) es el asistente de configuración:
mcp-agent-memory --setupHace seis preguntas:
Directorio de memoria — donde reside
.agent-memory/(por defecto~/.agent-memory)¿Instalar el demonio de consolidación? — diga "no" para el modo solo MCP (los agentes pueden leer/escribir/buscar en la memoria, pero sin consolidación automática)
Backend de LLM —
bedrock,openaiokiro(se omite si rechazó el demonio)Configuración de consolidación —
min_hours,min_sessions, intervalo de extracción, caracteres máximosModo de ejecución —
standalone(iniciar manualmente) olaunchagent(inicio automático al iniciar sesión, solo macOS)Directorio de registros + TTL — dónde guardar los registros y cuántos días conservarlos (
0= para siempre)Registro de cliente — registrar automáticamente el servidor MCP en las configuraciones de Kiro, Claude Desktop y/o Cursor (las entradas MCP existentes se conservan)
Cuando selecciona el backend kiro, el asistente también copia un agente ligero en ~/.kiro/agents/memconsolidate.json que reduce el uso de tokens en aproximadamente 7 veces (ver Backend Kiro).
Cuando selecciona launchagent, el asistente verifica que agent-memory-daemon esté instalado (y ofrece ejecutar npm install -g si no lo está), luego registra e inicia el plist.
Referencia de CLI
mcp-agent-memory # run as an MCP server (normal mode — clients spawn it)
mcp-agent-memory --setup # first-time interactive setup
mcp-agent-memory --configure # re-run most steps; can add/remove the daemon later
mcp-agent-memory --remove # interactive uninstall (backup memory, clean configs)
# macOS LaunchAgent control:
mcp-agent-memory --daemon status # is the daemon running?
mcp-agent-memory --daemon start # load and start
mcp-agent-memory --daemon stop # unload (keeps the plist)
mcp-agent-memory --daemon restart # stop + start
mcp-agent-memory --daemon remove # unload and delete the plist--remove conserva otras entradas en las configuraciones MCP del cliente: solo se elimina la clave memory. Por defecto, realiza una copia de seguridad de ~/.agent-memory/ en un directorio .bak-* con marca de tiempo para que pueda restaurar sus memorias consolidadas.
Instalación manual
Si prefiere omitir el asistente, aquí le explicamos cómo hacerlo manualmente.
Instalar el demonio (opcional)
El servidor MCP funciona de forma independiente: simplemente lee y escribe archivos bajo ~/.agent-memory/. Las memorias persisten, pero no se consolidarán ni extraerán de las sesiones hasta que agregue el demonio.
npm install -g agent-memory-daemon
# copy the example config
mkdir -p ~/.agent-memory
cp examples/memconsolidate.toml ~/.agent-memory/memconsolidate.toml
# start the daemon
agent-memory-daemon start ~/.agent-memory/memconsolidate.tomlConsulte examples/memconsolidate.toml para obtener una configuración lista para usar que coincida con el diseño de directorio que espera este servidor MCP.
Ejecutar el demonio al iniciar sesión (macOS)
En lugar de iniciar el demonio manualmente, regístrelo como un LaunchAgent:
./scripts/daemon.sh start # install plist, load it, start at login
./scripts/daemon.sh status # check if it's running
./scripts/daemon.sh stop # unload (keeps the plist)
./scripts/daemon.sh remove # unload and delete the plistPase una ruta de configuración personalizada como segundo argumento: ./scripts/daemon.sh start /path/to/config.toml. Los registros se guardan en ~/.agent-memory/logs/daemon.{out,err}.log. remove deja sus archivos de configuración y memoria intactos.
Usar Kiro como backend de LLM
Si tiene créditos de Kiro, puede ejecutar el demonio a través de kiro-cli en lugar de pagar por llamadas a la API de Bedrock u OpenAI. Esto requiere agent-memory-daemon ≥ 2.7 (rama feat/kiro-backend) que agrega un backend kiro.
[llm_backend]
name = "kiro"
# optional overrides:
# binary = "/custom/path/to/kiro-cli"
# agent = "memconsolidate" # set to "" to use Kiro's default session context (not recommended)
# model = "claude-sonnet-4-20250514"
# timeoutMs = 300000Use un agente ligero para reducir el uso de tokens en aproximadamente 7 veces. Por defecto, cada llamada a kiro-cli chat carga el prompt del sistema completo de Kiro más cada esquema de herramienta MCP de su configuración global: aproximadamente 12–18K tokens de entrada adicionales por llamada. Cree un agente mínimo que omita todo eso:
cp examples/kiro-agent-memconsolidate.json ~/.kiro/agents/memconsolidate.jsonEl backend de Kiro pasa --agent memconsolidate automáticamente, por lo que no se necesita más configuración. Medido en un prompt trivial: 0.01 créditos con el agente ligero frente a 0.07 créditos con el predeterminado (misma calidad de salida).
Consulte examples/kiro-agent-memconsolidate.json: el agente tiene mcpServers: {}, tools: [] y useLegacyMcpJson: false para que no herede nada de su configuración global de Kiro.
Configurar clientes manualmente
Los asistentes
--setupy--configuremanejan esto por usted. Esta sección es para usuarios que desean realizar la conexión manualmente.
Kiro (CLI e IDE)
Edite ~/.kiro/settings/mcp.json:
{
"mcpServers": {
"memory": {
"command": "npx",
"args": ["-y", "mcp-agent-memory"],
"env": {
"MEMORY_DIRECTORY": "~/.agent-memory/memory",
"SESSION_DIRECTORY": "~/.agent-memory/sessions"
},
"disabled": false,
"timeout": 30000
}
}
}Luego pregúntele a Kiro: "Lee mi índice de memoria." o "Recuerda esto: prefiero pnpm sobre npm."
Claude Desktop
Edite ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) o %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"memory": {
"command": "npx",
"args": ["-y", "mcp-agent-memory"],
"env": {
"MEMORY_DIRECTORY": "~/.agent-memory/memory",
"SESSION_DIRECTORY": "~/.agent-memory/sessions"
}
}
}
}Reinicie Claude Desktop. Aparecerán las herramientas memory_*.
Cursor
Agréguelo a ~/.cursor/mcp.json con el mismo bloque de servidor.
Variables de entorno
Variable | Por defecto | Descripción |
|
| Donde el demonio almacena los archivos de memoria consolidados |
|
| Donde aterrizan los resúmenes de sesión escritos por el agente |
Ambas rutas deben coincidir con lo que utiliza su configuración de agent-memory-daemon.
Prompt de agente recomendado
Dígale a su agente que llame a memory_read al comienzo de una conversación y a memory_append_session al final. Regla de dirección de ejemplo para Kiro (~/.kiro/steering/memory.md):
At the start of every session, call memory_read (no arguments) to load my memory
index. Only pass `topics` when the task genuinely needs the full content of a
specific topic file.
When you learn something durable about me, my projects, or my preferences, call
memory_append_session with a concise markdown summary. Target 300-800 tokens,
use structured headers and bullets (not prose), and focus on durable findings
and decisions — not play-by-play. Verbose summaries cost more during the
daemon's consolidation pass.Consejos sobre el uso de tokens
Cada una de las tres herramientas tiene un perfil de costo diferente. Algunas prácticas mantienen bajas las facturas de inferencia + consolidación:
memory_readsin argumentos devuelve solo el índiceMEMORY.md(normalmente <1 KB). Prefiera esto sobretopicsa menos que necesite el contenido completo.memory_searchse basa en subcadenas y devuelve ≤3 líneas coincidentes por archivo: más barato que cargar archivos de temas completos.memory_append_sessionno cuesta nada en el momento de la llamada, pero cada sesión es procesada por el LLM del demonio durante la consolidación. Mantenga los resúmenes concisos y estructurados.Consolide o pode archivos de temas antiguos ocasionalmente. Ejecute
mcp-agent-memory --configure: ahora advierte si su directorio de memoria supera los 25 archivos o 200 KB.La poda de sesiones después de la extracción es manejada por el demonio, no por el servidor MCP. Consulte la configuración de
agent-memory-daemonpara ver las opciones que archivan o eliminan sesiones después de que se procesan (evita que el demonio vuelva a escanear sesiones antiguas para siempre).
Licencia
MIT
Available Tools
4 toolsmemory_append_sessionA
Append a session summary to the sessions directory. The daemon will later extract durable memories from it. Call this at the end of meaningful exchanges. Keep summaries focused on durable findings and decisions (target 300-800 tokens), not play-by-play — longer summaries cost more during consolidation.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Markdown-formatted session summary. Use structured headers and bullets for better extraction; avoid verbose prose. | |
| source | No | Origin tag, e.g., "kiro", "claude-desktop" |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the daemon will later extract memories and that longer summaries incur higher cost. This adds useful behavioral context beyond the simple append.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, each serves a purpose: action, timing, and content guidelines. No redundancy, front-loaded with core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description provides complete guidance: what, when, how, and cost implications. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, but description adds significant value by advising on summary focus, token target (300-800), and avoiding verbose prose. This guides the agent beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Append a session summary to the sessions directory' with a specific verb and resource. It distinguishes from sibling read tools (memory_read, memory_search) by being a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Call this at the end of meaningful exchanges' and provides guidelines on summary length and content. No exclusion criteria or alternatives mentioned, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_daemon_statusA
Check whether the memory consolidation daemon is running. Reports if the daemon is not installed or not available on this platform.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the tool reports if the daemon is not installed or not available, indicating it can return multiple status outcomes. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The core purpose is front-loaded in the first sentence, and the second adds extra detail concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the tool's purpose effectively. It explains what the tool does and the possible outcomes (daemon running, not installed, not available). No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100% (trivially). The description does not need to add parameter information. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks the running status of the memory consolidation daemon, and also reports if the daemon is not installed or not available on the platform. This distinguishes it from sibling tools (memory_append_session, memory_read, memory_search) which perform different memory operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (checking daemon status) but does not explicitly state when to use this tool versus alternatives. No exclusions or alternatives are mentioned, though sibling tools have different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_readA
Read the agent memory index (MEMORY.md) and optionally specific topic files. Call with no arguments to load only the lightweight index (cheap). Pass topics only when you need the full content of a specific topic file.
| Name | Required | Description | Default |
|---|---|---|---|
| topics | No | Optional topic file names to load in full (e.g., ["preferences", "projects"]). Omit to return the index only. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It reveals that calling without arguments is 'cheap' (lightweight), implying topic file retrieval is more expensive. This adds useful context beyond the schema, though it could further clarify error handling or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, then a follow-up sentence with usage details. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter, the description covers the main usage. However, without an output schema, it lacks details on the return format (e.g., structure of the index or topic file content). This is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning: it explains that the topics parameter triggers full content retrieval, while omitting it returns the index. This informs the agent of the parameter's purpose beyond data typing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the agent memory index (MEMORY.md) and optionally specific topic files.' It identifies the action (read) and resource (memory index/topic files), and distinguishes from siblings by specifying the no-arguments vs. topics usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Call with no arguments to load only the lightweight index (cheap). Pass topics only when you need the full content of a specific topic file.' This tells the agent when to use each mode, effectively differentiating between lightweight and full retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_searchA
Search memory files for a substring. Use this to recall specific facts without loading everything.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Substring to search for across all memory files (case-insensitive) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It specifies case-insensitive substring search but omits what the response contains (e.g., matching lines, file paths) and any performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the lack of output schema and omission of response format leaves the agent guessing about what will be returned, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with full parameter description; the tool description adds no extra semantics beyond restating the schema's content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches memory files for a substring, distinguishing it from sibling 'memory_read' which presumably loads entire files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use for 'recall specific facts without loading everything,' providing clear context for when to use, though it could name the alternative sibling directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.0.3- Added
memory_daemon_status - Changed
memory_search1 field changed- added
Input schema / properties / query / descriptionAdded value: +"Substring to search for across all memory files (case-insensitive)"
3 tool updates
v1.0.0- First observed
memory_append_session - First observed
memory_read - First observed
memory_search
TDQS
Scored across 4 tools
Each tool serves a distinct purpose: appending sessions, checking daemon status, reading memory index, and searching. No overlaps or ambiguities.
All tools follow a consistent pattern: 'memory_' prefix followed by a descriptive verb or verb_noun (append_session, daemon_status, read, search). Naming is predictable and clear.
With 4 tools, the surface is concise and well-scoped for a memory management server. Each tool addresses a core operation without redundancy.
The tools cover essential operations (append, read, search, status). Missing update/delete might be a minor gap, but the memory consolidation daemon likely handles lifecycle, making this acceptable.
Maintenance
Related MCP Connectors
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that provides AI agents with persistent memory capabilities through Mem0, allowing them to store, retrieve, and semantically search memories.684MIT

Recallofficial
AlicenseNot gradedqualityCmaintenanceOpen-source MCP memory server for AI agents — persistent, searchable, tiered memory across sessions. Works over stdio (Cursor, Claude Desktop) or HTTP+SSE. MIT licensed.8MIT- AlicenseAqualityBmaintenanceGives your AI persistent memory across conversations. Stores facts automatically, finds them by meaning using hybrid search with query expansion, and organizes everything into topics without manual tagging.181MIT

@memofs/mcp-serverofficial
AlicenseNot gradedqualityAmaintenance@memofs/mcp-server lets AI coding agents (Claude Code, Claude Desktop, Codex, Cursor, opencode, Gemini CLI, GitHub Copilot, Zed, and any other MCP client) securely read and write MemoFS memory through standard Model Context Protocol tools.6MIT