Memory MCP is an MCP server that provides intelligent project memory management for Claude Code, enabling persistent storage and retrieval of project-specific information.
Core Capabilities:
Recall memories (recall_memory_tool): Query and retrieve relevant information using natural language, keywords, or questions to find stored project knowledge
Store memories (memorize_memory_tool): Save valuable information discovered during development, such as architectural decisions, configuration details, or important insights
Persistent storage: Automatically stores memories as Markdown files in the project's .memories directory for long-term persistence across sessions
Intelligent management: Uses keyword matching and LLM-powered decision making to automatically determine whether to create new memories or update existing ones
Automatic validation: Validates content size and relevance before storage to maintain memory quality
Context preservation: Prevents duplicate work and knowledge loss by maintaining a growing repository of project knowledge that Claude can reference across conversations
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 recall what we discussed about the authentication system"
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.
English | 简体中文
An MCP server that provides project memory management for Claude Code.
Python >= 3.10
uv package manager
Anthropic API Key (get it from Anthropic Console)
Install directly from GitHub (no download required):
# Add to current project (local scope)
claude mcp add memory \
--env ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
-- uvx --from git+https://github.com/JerryZhongJ/memory-mcp.git memory-mcp --project $(pwd)If you need to modify the source code or contribute to development:
# 1. Clone the repository
git clone https://github.com/JerryZhongJ/memory-mcp.git
cd memory-mcp
# 2. Install dependencies
uv sync
# 3. Add to Claude Code
claude mcp add memory \
--env ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
-- uv --directory /path/to/memory-mcp run memory-mcp --project $(pwd)After configuration, Claude Code will automatically load the server. You can verify with:
# List all configured MCP servers
claude mcp list
# Use /mcp command in Claude Code to check server status# Remove server
claude mcp remove memory
# View server details
claude mcp get memoryRelated MCP server: Roo Code Memory Bank MCP Server
Memories are stored as Markdown files in the project's .memories directory
Uses intelligent keyword matching and retrieval
LLM automatically decides whether to create new memories or update existing ones
Automatically validates content size and relevance
Frontend-backend separation architecture with automatic backend lifecycle management
To help Claude better use this MCP service, it's recommended to create a .claude/CLAUDE.md file in your project with the following usage rules:
# Project Memory Management Rules
## ⚠️ Mandatory Rules (Must Be Strictly Followed)
### 1. Query Memory Before Starting Tasks
**Every time you receive a user question, the first step must be to use `recall_memory_tool` to query relevant information.**
Do not rely on judgment to decide whether to query. Any question may be related to existing memories.
### 2. Save New Information Immediately Upon Discovery
**Whenever you obtain valuable new information through investigation, you must immediately use `memorize_memory_tool` to save it.**
Save the information as soon as you discover it, don't wait until after answering the user's question.
**Standard Workflow**:
```
User Question → Query Memory → Investigate Code/Docs → Discover New Info → Save Immediately → Answer User
```
**Important**: Skipping these steps leads to duplicate work, inconsistent answers, and knowledge loss.MIT
记住一些内容
Args:
content: 要记住的内容。可以是一句话、一段文字甚至更长的文本。
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'remembers' content but doesn't explain what this means operationally: where content is stored, for how long, whether it's persistent, what permissions are needed, or what happens on success/failure. The description is too vague about the actual 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 appropriately concise with two sentences that directly address purpose and parameter semantics. The structure is clear with a purpose statement followed by parameter explanation. No wasted words, though it could be slightly more complete.
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 has an output schema (which handles return values) and only one parameter, the description covers the basics but leaves significant gaps. For a memory tool with no annotations, it should explain more about storage behavior, persistence, and error conditions. The description is minimally adequate but incomplete for confident tool selection.
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?
With 0% schema description coverage and only one parameter, the description adds significant value by explaining that 'content' can be '一句话、一段文字甚至更长的文本' (a sentence, a paragraph, or even longer text). This provides helpful semantic context about acceptable input formats that the schema alone doesn't convey. However, it doesn't mention length limits or content restrictions.
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 states the tool's purpose as '记住一些内容' (memorize some content), which is a clear verb+object combination. However, it doesn't differentiate from its sibling 'recall_memory_tool' beyond the basic memorization vs recall distinction. The purpose is understandable but lacks specificity about what kind of content or context is appropriate.
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. There's no mention of the sibling tool 'recall_memory_tool' or any context about when memorization is appropriate versus other operations. The user 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.
从项目记忆中回忆相关信息
Args:
interest: 想要回忆的任何东西，可以是一句陈述、一个问题甚至是关键词
| Name | Required | Description | Default |
|---|---|---|---|
| interest | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 recalls information but doesn't describe what happens when no matches are found, whether the recall is fuzzy or exact, what format the returned information takes, or any limitations like memory size or access permissions. The description provides minimal behavioral context beyond the basic operation.
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 appropriately concise with two sentences that each serve a clear purpose. The first sentence states the tool's function, and the second explains the parameter. There's no wasted text or redundancy. The structure is logical and front-loaded with the core purpose.
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 has an output schema (which handles return values), a single parameter with good semantic explanation in the description, and no complex annotations, the description is minimally adequate. However, it lacks important context about the memory system's scope, how recall interacts with the sibling memorize tool, and behavioral details that would help the agent use it 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?
The description provides meaningful semantic context for the single parameter 'interest' that goes beyond the schema. While schema description coverage is 0%, the description explains that 'interest' can be '一句陈述、一个问题甚至是关键词' (a statement, a question, or even keywords), which clarifies the flexible nature of this input. This compensates well for the lack of schema descriptions.
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 states the tool '从项目记忆中回忆相关信息' (recalls related information from project memory), which provides a basic verb+resource combination. However, it's somewhat vague about what constitutes 'project memory' and doesn't clearly differentiate from its sibling 'memorize_memory_tool' beyond the recall vs. memorize distinction. The purpose is understandable but lacks specificity about the scope and nature of the memory system.
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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention the sibling 'memorize_memory_tool' or explain the relationship between recalling and memorizing. There's no context about prerequisites, appropriate scenarios, or limitations. The agent receives no help in deciding when this tool is the right choice.
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.0memorize_memory_toolrecall_memory_toolmemorize_memory_toolrecall_memory_toolThe two tools have completely distinct purposes: one stores information (memorize) and one retrieves information (recall). There is no overlap in functionality, and an agent would never confuse which tool to use for which operation.
Both tools follow the same verb_noun_tool pattern: memorize_memory_tool and recall_memory_tool. The naming is perfectly consistent with clear action verbs and matching structure throughout.
With only 2 tools, this server feels thin for a memory system. While memorize and recall cover basic operations, there are no tools for managing, organizing, updating, or deleting memories, which would be expected for a complete memory management system.
The tool surface is severely incomplete for a memory system. While it covers basic store and retrieve operations, there are no tools for updating existing memories, deleting memories, listing available memories, searching with filters, or managing memory organization. This creates significant gaps that will limit agent effectiveness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JerryZhongJ/memory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
