Un servidor de protocolo de contexto de modelo para almacenar y recuperar memorias utilizando una implementación de servidor de bajo nivel y almacenamiento SQLite.
Este proyecto utiliza uv para la gestión de dependencias en lugar de pip. uv es un instalador y solucionador de paquetes de Python rápido y confiable.
Instalar usando uv:
uv pip install memory-mcpO instalar directamente desde la fuente:
uv pip install .Para desarrollo:
uv pip install -e ".[dev]"Si no tienes instalado uv, puedes instalarlo siguiendo las instrucciones oficiales .
Related MCP server: SQLite MCP Server
memory-mcpEsto iniciará el servidor MCP que le permite almacenar y recuperar memorias.
El Memory MCP proporciona las siguientes herramientas:
remember : Almacena un nuevo recuerdo con un título y contenido
get_memory : recupera una memoria específica por ID o título
list_memories : Lista todas las memorias almacenadas
update_memory : Actualizar una memoria existente
delete_memory : Borrar una memoria
MCP proporciona una práctica herramienta de línea de comandos llamada mcp inspect que le permite depurar e interactuar con su servidor MCP directamente.
Primero, asegúrese de que las herramientas CLI de MCP estén instaladas:
uv pip install mcp[cli]Inicie el servidor Memory MCP en una terminal:
memory-mcpEn otra terminal, conéctese al servidor en ejecución usando mcp inspect :
mcp inspectUna vez conectado, podrás:
> toolsEsto mostrará todas las herramientas proporcionadas por el servidor Memory MCP.
Para llamar a una herramienta, utilice el comando call seguido del nombre de la herramienta y los argumentos requeridos:
> call remember title="Meeting Notes" content="Discussed project timeline and milestones."> call list_memories> call get_memory memory_id=1> call update_memory memory_id=1 title="Updated Title" content="Updated content."> call delete_memory memory_id=1Puede habilitar el modo de depuración para ver información detallada de solicitudes y respuestas:
> debug onEsto le ayudará a comprender exactamente qué datos se envían al servidor y se reciben del mismo.
Para ver el esquema de una herramienta específica:
> tool rememberAquí se muestra el esquema de entrada, los parámetros requeridos y la descripción de la herramienta.
Si encuentra problemas:
Verifique los registros del servidor en la terminal donde se ejecuta su servidor para detectar cualquier mensaje de error.
En la terminal de inspección de MCP, habilite el modo de depuración con debug on para ver las solicitudes y respuestas sin procesar.
Asegúrese de que los parámetros de la herramienta coincidan con el esquema esperado (verifique con el comando tool ).
Si el servidor falla, verifique si hay excepciones no detectadas en la terminal del servidor.
Para contribuir al proyecto, instale las dependencias de desarrollo:
uv pip install -e ".[dev]"Este proyecto utiliza el archivo uv.lock para bloquear las dependencias. Para actualizar las dependencias:
uv pip compile pyproject.toml -o uv.lockpython -m pytestblack memory_mcp testsruff check memory_mcp testsmypy memory_mcpDelete a memory.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | The ID of the memory to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete a memory' implies a destructive, irreversible mutation, but it doesn't specify permissions required, whether deletion is permanent or recoverable, error handling (e.g., if memory_id doesn't exist), or side effects. This is a significant gap for a destructive tool with zero annotation coverage.
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?
The description is extremely concise at three words, with zero wasted text. It's front-loaded with the core action, making it easy to parse quickly. Every word earns its place by directly stating the tool's function without 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?
Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what happens post-deletion (e.g., confirmation message, error responses), prerequisites, or how it differs from sibling tools. The agent lacks sufficient information to use this tool safely and effectively.
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 description coverage is 100%, with the parameter 'memory_id' clearly documented in the schema as 'The ID of the memory to delete'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 'Delete a memory' clearly states the verb (delete) and resource (memory), making the basic purpose understandable. However, it doesn't differentiate this tool from its sibling 'update_memory' which could also modify memory state, nor does it specify what type of memory is being deleted (e.g., user memory, system memory, cached data). It's adequate but vague about scope.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_memory', 'list_memories', 'remember', and 'update_memory', there's no indication of when deletion is appropriate (e.g., after retrieval, as cleanup, or for specific memory types). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific memory by ID or title.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | No | The ID of the memory to retrieve | |
| title | No | The title of the memory to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It states the tool retrieves but doesn't disclose error handling (e.g., if memory doesn't exist), authentication needs, rate limits, or return format. The description is minimal and doesn't compensate for the absence of annotations, leaving key operational traits unclear.
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?
The description is a single, efficient sentence that front-loads the core action ('Retrieve a specific memory') and adds necessary qualification ('by ID or title'). There is zero waste, and every word earns its place, making it appropriately sized for a simple retrieval tool.
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 the tool's moderate complexity (retrieval with two parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like error cases or return values, leaving gaps that could hinder an AI agent's ability to use it correctly. More context is needed for a retrieval operation.
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 description coverage is 100%, so the schema already documents both parameters ('memory_id' and 'title') fully. The description adds no extra meaning beyond implying these are alternative lookup methods, but doesn't explain exclusivity, precedence, or format details. This meets the baseline of 3 when schema coverage is high.
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 action ('Retrieve') and resource ('a specific memory'), and specifies the lookup methods ('by ID or title'). It distinguishes from siblings like 'list_memories' (which retrieves multiple) and 'delete_memory'/'update_memory' (which modify). However, it doesn't explicitly contrast with 'remember' (which likely creates memories), keeping it from a perfect 5.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing memory), exclusions (e.g., not for bulk retrieval), or direct comparisons to siblings like 'list_memories' for multiple memories or 'remember' for creation. Usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all stored memories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'List all stored memories,' which implies a read-only operation, but doesn't clarify aspects like pagination, sorting, filtering, or what 'all' entails (e.g., if there are limits). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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?
The description 'List all stored memories' is a single, efficient sentence that front-loads the core action and resource. It wastes no words and is appropriately sized for a simple tool, earning the highest score for conciseness.
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 the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior (e.g., output format, limitations) that would be helpful for an agent. Without annotations or output schema, more context is needed for full 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?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of inputs. The description doesn't add parameter details, but since there are no parameters, a baseline of 4 is appropriate—it's clear no inputs are needed, though a perfect score would require explicit confirmation of this in the description.
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 'List all stored memories' clearly states the verb ('List') and resource ('stored memories'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_memory' (which likely retrieves a specific memory) or 'remember' (which likely creates a memory), so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives. Given siblings like 'get_memory' (for specific retrieval) and 'delete_memory'/'update_memory' (for modifications), the agent must infer usage from the name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a new memory.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The full content of the memory to store | |
| title | Yes | A concise title for the memory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Store a new memory' implies a write operation, but it doesn't specify whether this is idempotent, requires authentication, has side effects, or what happens on failure. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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?
The description is a single, efficient sentence ('Store a new memory') that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, making it highly concise and well-structured.
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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, potential errors, or how it interacts with sibling tools like 'list_memories'. For a tool that modifies state, more context is needed to guide effective usage.
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 schema description coverage is 100%, with clear descriptions for both parameters ('content' and 'title'). The tool description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 where the schema does the heavy lifting without extra value from the description.
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 'Store a new memory' clearly states the verb ('store') and resource ('memory'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_memory' or 'delete_memory' beyond the 'new' qualifier, which is why it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives like 'update_memory' or 'delete_memory'. It lacks any context about prerequisites, such as whether this creates a memory from scratch versus modifying existing ones, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing memory.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | Optional new content for the memory | |
| memory_id | Yes | The ID of the memory to update | |
| title | No | Optional new title for the memory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates an existing memory but doesn't clarify whether this is a destructive operation, what permissions are required, how conflicts are handled, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration. Every word earns its place, making it easy for an agent to parse quickly.
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 the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'update' entails (e.g., partial vs. full updates), error conditions, or return values. For a tool that modifies data, more context is needed to ensure correct usage by an AI agent.
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 description coverage is 100%, so the schema already documents all three parameters (memory_id, content, title) with their types and optionality. The description adds no additional meaning beyond the schema, such as format constraints or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Update an existing memory' clearly states the verb (update) and resource (memory), but it's vague about what constitutes a 'memory' and doesn't differentiate from sibling tools like 'remember' or 'delete_memory'. It's better than a tautology but lacks specificity about the update operation's scope.
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 provides no guidance on when to use this tool versus alternatives like 'delete_memory' or 'remember'. It doesn't mention prerequisites (e.g., needing an existing memory ID) or contextual cues for choosing this tool over others. The absence of usage instructions leaves the agent without decision-making help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0delete_memoryget_memorylist_memoriesrememberupdate_memoryScored across 5 tools
Each tool has a clearly distinct purpose targeting specific CRUD operations on memories: list (retrieve all), get (retrieve specific), remember (create), update (modify), and delete (remove). There is no overlap in functionality, making tool selection unambiguous for an agent.
All tool names follow a consistent verb_noun pattern with snake_case, using clear action verbs (list, get, remember, update, delete) paired with the noun 'memory'. There are no deviations or mixed conventions, ensuring predictable naming throughout.
With 5 tools, this server is well-scoped for memory management, providing complete CRUD coverage without unnecessary bloat. Each tool earns its place by covering essential operations, making the count appropriate for the domain.
The tool set offers complete CRUD/lifecycle coverage for memory management: create (remember), read (list_memories, get_memory), update (update_memory), and delete (delete_memory). There are no obvious gaps, allowing agents to handle all core workflows without dead ends.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP memory server. One memory your agents share — across models, devices and apps.
Cloud-hosted MCP server for durable AI memory
Cross-tool persistent memory and context for AI assistants over MCP.
