Uses SQLite for persistent memory storage, enabling the creation, retrieval, updating, and deletion of memories with features like titled entries and memory management through various tools.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Memory MCP remember meeting notes from yesterday's project kickoff"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for storing and retrieving memories using low-level Server implementation and SQLite storage.
This project uses uv for dependency management instead of pip. uv is a fast, reliable Python package installer and resolver.
Install using uv:
uv pip install memory-mcpOr install directly from source:
uv pip install .For development:
uv pip install -e ".[dev]"If you don't have uv installed, you can install it following the official instructions.
Related MCP server: SQLite MCP Server
memory-mcpThis will start the MCP server that allows you to store and retrieve memories.
The Memory MCP provides the following tools:
remember: Store a new memory with a title and content
get_memory: Retrieve a specific memory by ID or title
list_memories: List all stored memories
update_memory: Update an existing memory
delete_memory: Delete a memory
MCP provides a handy command-line tool called mcp inspect that allows you to debug and interact with your MCP server directly.
First, make sure the MCP CLI tools are installed:
uv pip install mcp[cli]Start the Memory MCP server in one terminal:
memory-mcpIn another terminal, connect to the running server using mcp inspect:
mcp inspectOnce connected, you can:
> toolsThis will display all the tools provided by the Memory MCP server.
To call a tool, use the call command followed by the tool name and any required arguments:
> 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=1You can enable debug mode to see detailed request and response information:
> debug onThis helps you understand exactly what data is being sent to and received from the server.
To view the schema for a specific tool:
> tool rememberThis shows the input schema, required parameters, and description for the tool.
If you encounter issues:
Check the server logs in the terminal where your server is running for any error messages.
In the MCP inspect terminal, enable debug mode with debug on to see raw requests and responses.
Ensure the tool parameters match the expected schema (check with the tool command).
If the server crashes, check for any uncaught exceptions in the server terminal.
To contribute to the project, install the development dependencies:
uv pip install -e ".[dev]"This project uses uv.lock file to lock dependencies. To update dependencies:
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. Dates show when Glama detected each change.
v1.0.0delete_memoryget_memorylist_memoriesrememberupdate_memoryEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for AI agents — log and recall conversation context over MCP.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/drdee/memory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
