使用低级服务器实现和 SQLite 存储来存储和检索记忆的模型上下文协议服务器。
该项目使用uv而不是 pip 进行依赖管理。uv 是一个快速、可靠的 Python 包安装程序和解析器。
使用 uv 安装：
uv pip install memory-mcp或者直接从源安装：
uv pip install .对于开发：
uv pip install -e ".[dev]"如果你没有安装uv，可以按照官方说明进行安装。
Related MCP server: SQLite MCP Server
memory-mcp这将启动 MCP 服务器，允许您存储和检索记忆。
内存 MCP 提供以下工具：
remember ：存储带有标题和内容的新记忆
get_memory ：通过 ID 或标题检索特定记忆
list_memories ：列出所有存储的记忆
update_memory ：更新现有记忆
delete_memory ：删除记忆
MCP 提供了一个名为mcp inspect的便捷命令行工具，可让您直接调试和与 MCP 服务器交互。
首先，确保已安装 MCP CLI 工具：
uv pip install mcp[cli]在一个终端中启动 Memory MCP 服务器：
memory-mcp在另一个终端中，使用mcp inspect连接到正在运行的服务器：
mcp inspect连接后，您可以：
> tools这将显示 Memory MCP 服务器提供的所有工具。
要调用工具，请使用call命令，后跟工具名称和任何所需的参数：
> 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=1您可以启用调试模式来查看详细的请求和响应信息：
> debug on这可以帮助您准确了解发送到服务器和从服务器接收的数据。
要查看特定工具的架构：
> tool remember这显示了该工具的输入模式、所需参数和描述。
如果您遇到问题：
检查服务器运行终端中的服务器日志是否有任何错误消息。
在 MCP 检查终端中，启用调试模式并debug on以查看原始请求和响应。
确保工具参数与预期模式匹配（使用tool命令检查）。
如果服务器崩溃，请检查服务器终端中是否存在任何未捕获的异常。
要为项目做出贡献，请安装开发依赖项：
uv pip install -e ".[dev]"本项目使用uv.lock文件来锁定依赖项。要更新依赖项，请执行以下操作：
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.
