This server enables intelligent searching and navigation of Claude Code memory files, allowing you to efficiently retrieve relevant context without loading every memory into the context window.
search_memory: Perform ranked keyword searches across all memory file bodies, with scoring bonuses for title and description matches. Supports an optional limit parameter to control the number of results.
get_memory: Retrieve the complete contents of a specific memory file by its name (without the .md extension), useful for loading only what you need on demand.
list_memories: List all available memory files, with an optional filter by type (user, feedback, project, or reference) to narrow results.
find_related: Discover memories linked to or from a given memory file via [[wikilinks]], enabling traversal of connected context across the memory graph.
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., "@claude-memory-search-mcp search memories for 'database migration'"
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.
MCP server that searches and links across Claude Code memory files.
Claude Code's auto-memory directory grows large quickly (100+ files in my setup). Loading every memory into context defeats the point of having them — and the auto-loaded MEMORY.md only carries a 150-char hook per entry. This server lets Claude:
search by keyword across every memory body, not just titles,
filter by type (user / feedback / project / reference),
fetch a single memory in full only when needed,
traverse [[wikilinks]] to pull related context on demand.
In short: stop trying to hold the whole memory in the window. Index it, then pull what you need.
Related MCP server: claude-kb
Tool | Args | Description |
|
| Ranked keyword search across all memory bodies. Bonuses for title and description hits. |
|
| Fetch the full body of one memory by file name (no |
|
| List every memory, optionally filtered by type. |
|
| Return memories linked from or to a given memory via |
git clone https://github.com/yangchoi/claude-memory-search-mcp.git
cd claude-memory-search-mcp
npm install
npm run buildnpx -y github:yangchoi/claude-memory-search-mcpSlower on first invocation (npx fetches and builds), then cached.
Add to your Claude Code MCP config (~/.claude/settings.json or project .mcp.json):
{
"mcpServers": {
"memory-search": {
"command": "node",
"args": ["/absolute/path/to/claude-memory-search-mcp/dist/index.js"],
"env": {
"CLAUDE_MEMORY_DIR": "/Users/you/.claude/projects/<your-project-id>/memory"
}
}
}
}CLAUDE_MEMORY_DIR is optional — by default the server derives the path from $HOME (e.g. /Users/jane → ~/.claude/projects/-Users-jane/memory on macOS, /home/jane → ~/.claude/projects/-home-jane/memory on Linux). Set it explicitly if your memory lives elsewhere.
Restart Claude Code. The four tools above will appear under mcp__memory-search__*.
> search_memory query="database migration"
[42] backend-project-notes (project)
matches: database, migration
Postgres migration patterns and rollback strategy
[18] team-conventions (reference)
matches: migration
...MIT
Fetch the full body of a memory file by its name (without .md).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Memory file name (no extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states basic fetch action. Discloses no behavioral traits like size limits, error handling, or response format. As the sole source of behavioral info, it falls short.
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?
Single sentence, front-loaded with verb and resource. No redundant words; every word serves a 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?
Tool is simple (1 param, no output schema, no annotations). Description sufficiently conveys the core action. Lacks details about what 'full body' entails, but adequate for a straightforward fetch 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 covers 100% of the single parameter 'name' with description 'Memory file name (no extension)'. Tool description adds 'without .md' reinforcing the schema. Baseline 3 since schema already provides adequate semantics.
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 uses specific verb 'Fetch', identifies resource 'full body of a memory file', and specifies identifier 'by its name (without .md)'. This clearly distinguishes from siblings like list_memories, search_memory, and find_related.
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?
Implied usage when you have a specific memory name, but no explicit when-to-use or when-not-to-use guidance. Sibling tools are listed but no differentiation in usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all memory files. Optionally filter by type (user/feedback/project/reference).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional type filter (user/feedback/project/reference) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only states it lists files; missing details on pagination, ordering, potential size limits, or whether the call is safe and non-destructive.
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 concise sentences with clear front-loaded purpose and filter option, no wasted words.
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 (one optional param, no output schema), the description is mostly complete but lacks specifics on list size or ordering, which are minor 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 coverage is 100% with one parameter already described. The description reiterates the parameter's use but adds no new meaning beyond the schema, warranting baseline score.
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 lists all memory files with an optional type filter, distinguishing it from siblings like find_related or search_memory which have different purposes.
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?
While the description implies when to use (list all), it does not explicitly state when not to use or compare with alternatives like find_related or search_memory, providing only implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across memory files by keyword. Returns ranked hits with file name, score, matched terms, type, and description.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| query | Yes | Search query (keywords) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format but lacks details on behavioral aspects like read-only status, performance, or side effects.
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 concise sentences, front-loaded with a verb, with no wasted words.
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 (2 params, no output schema, no annotations), the description provides adequate context for an agent to use it correctly.
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%, and the description does not add meaning beyond the schema's parameter descriptions. The baseline of 3 is appropriate.
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 by keyword and returns specific ranked hit fields. It distinguishes from siblings like list_memories (listing all) and get_memory (retrieving one).
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 when to use (keyword search) and differentiates from siblings, but does not explicitly state when not to use alternatives or provide exclusion criteria.
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.
v0.1.0find_relatedget_memorylist_memoriessearch_memoryScored across 4 tools
Each tool has a clearly distinct purpose: find_related for wikilink navigation, get_memory for full content retrieval, list_memories for enumeration with filtering, and search_memory for keyword search. No overlap in functionality.
All tool names follow the consistent snake_case verb_noun pattern (find_related, get_memory, list_memories, search_memory). No deviations or mixed conventions.
4 tools is well-scoped for a memory search server. Each tool serves a distinct need (listing, retrieval, search, link navigation) without unnecessary redundancy or gaps.
The set covers core read/search operations for a memory system. However, it lacks write operations (create, update, delete), which may be intentional given the 'search' focus, but slightly limits completeness for full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Project memory, semantic code search, and grounded agent context.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.