Click on "Deploy 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., "@mcp-super-memory remember that I like strawberries"
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.
N:M associative memory graph for LLM agents — delivered as an MCP server.
Search "Newton" → reach "strawberry" through shared keys. Embedding similarity alone can't do this.
mcp-super-memory is an associative memory system for LLM agents built on a Key/Value graph — not a vector store. Memories live in a Value Space, accessed through a separate Key Space — one memory reachable via many keys, one key leading to many memories. This enables human-like associative leaps (multi-hop graph traversal) that pure embedding search fundamentally cannot replicate.
Works with: Claude Desktop · Claude Code · any MCP-compatible LLM agent
Every existing memory system (Mem0, A-MEM, MemGPT) stores memories as nodes and retrieves them by embedding similarity. This works until it doesn't:
Query: "Newton"
Embedding search finds: "Newton discovered gravity" ✅
Embedding search misses: "user likes strawberries" ❌Super Memory finds both — because "Newton" → apple memory → fruit key → strawberry memory. The path exists in the key graph, not in embedding space.
Related MCP server: Memsolus MCP Server
Key Space (concepts) Value Space (memories)
───────────────────── ──────────────────────────────
[Newton] ──────────────────→ "Newton discovered gravity"
[apple] ────────┬─────────→ ↑ same memory
[gravity] ────────┘
│
[apple] ────────┼─────────→ "apples are red fruit"
[fruit] ──────┬─┘
[red] ──────┤
│
[fruit] ──────┼─────────→ "user likes strawberries"
[strawberry]────┘Search "Newton" → matches [Newton], [apple] keys (1-hop) → follows shared [fruit] key → reaches strawberry memory (2-hop, score decayed by 0.3×).
Results include hop field — you always know if a result is direct or associative.
Feature | Super Memory | A-MEM | Mem0 | MemGPT |
Key/Value separation | ✅ N:M | ❌ | ❌ | ❌ |
Associative multi-hop | ✅ built-in | ❌ | ❌ | ❌ |
Depth system | ✅ | ❌ | ❌ | partial |
Memory versioning | ✅ supersede | overwrites | overwrites | ❌ |
Time decay | ✅ depth-weighted | ❌ | ❌ | ❌ |
Key types | ✅ concept/name/proper_noun | ❌ | ❌ | ❌ |
Key merge (IDF) | ✅ | ❌ | ❌ | ❌ |
Dual-path recall | ✅ key + content | ❌ | ❌ | ❌ |
Every memory has a depth score 0.0 → 1.0:
Stage | Depth | Behavior |
Shallow |
| Recent, unverified. Easy to update or forget. |
Medium |
| Confirmed multiple times. Stable. |
Deep |
| Well-established fact. Resists correction. |
Depth increases +0.05 each recall. Deep memories decay slower over time. If you try to correct a deep memory, it resists — its depth stays higher even after supersede.
Not all keys should behave the same. Names shouldn't match semantically — "동건" shouldn't match "뉴턴" just because they're both short Korean words.
Type | Matching | Use Case |
| Embedding similarity ≥ 0.35 | Topics, categories, attributes |
| Exact match only | Person names |
| Exact match only | Brands, places |
Name/proper_noun keys also get IDF penalty (×0.5) when they become hub keys connected to many memories, preventing them from polluting unrelated searches.
"user lives in Seoul" (depth: 0.4 → weakened to 0.12, preserved)
↑ superseded by
"user moved to Busan" (depth: 0.0, new)Unlike A-MEM which overwrites memory on evolution, Super Memory keeps the full history. Every correction is traceable — when did the belief change, and from what session?
Add key "파이썬" → finds existing "Python" (similarity 0.87 > threshold 0.85)
→ reuses existing key instead of creating duplicatePrevents key space fragmentation. Same concept across languages or phrasing stays unified.
Recall searches two paths simultaneously:
Path A (key matching): Query embedding → match keys → follow links → memories
Path B (content matching): Query embedding → directly compare against memory content embeddings
Scores from both paths are summed. This ensures memories are found even when they weren't tagged with the right keys.
┌─────────────────────────────────────────────────────────┐
│ Key Space │
│ [name] [동건] [programming] [python] [fruit] [red] │
│ ↓ ↓ ↓ ↓ ↓ ↓ │
│ [vec] [exact] [vec] [vec] [vec] [vec] │
└────────────────────────┬────────────────────────────────┘
│ N:M links
↓
┌─────────────────────────────────────────────────────────┐
│ Value Space │
│ "user's name is Donggeon" depth: 0.85 (deep) │
│ "user likes Python" depth: 0.30 (medium) │
│ "user likes strawberries" depth: 0.05 (shallow) │
└─────────────────────────────────────────────────────────┘Recall algorithm (2-hop):
Embed query → find matching keys (concept: similarity ≥ 0.35, name/proper_noun: exact match)
Also compare query embedding directly against memory content embeddings (≥ 0.3)
Follow links → collect memories, aggregate scores (multiple key matches sum up, IDF-weighted)
For each 1-hop memory: follow its keys → find 2-hop memories (score × HOP_DECAY = 0.3)
Apply depth factor (0.5 + depth × 0.5) and time decay (depth-weighted, 30-day half-life)
Return ranked results with hop field
The memory system exposes 8 tools via MCP:
Tool | Description |
| N:M search with 2-hop associative traversal + content matching |
| Save memory with key concepts and optional type annotations |
| Versioned update — old memory preserved but weakened |
| Find memories sharing keys (associative exploration) |
| Permanently delete |
| Load original conversation turns |
| List all stored memories with keys, depth, access count |
| Get current key/memory/link counts |
A system prompt template is also available via memory_system_prompt MCP prompt — include it to instruct the agent to recall silently, use diverse keys, and never mention the memory system to users.
Add to claude_desktop_config.json:
OpenAI embeddings:
{
"mcpServers": {
"mcp-super-memory": {
"command": "uvx",
"args": ["mcp-super-memory"],
"env": {
"OPENAI_API_KEY": "your-openai-api-key"
}
}
}
}Local embeddings (no API key required):
{
"mcpServers": {
"mcp-super-memory": {
"command": "uvx",
"args": ["mcp-super-memory[local]"],
"env": {
"EMBEDDING_BACKEND": "local"
}
}
}
}# OpenAI embeddings
claude mcp add mcp-super-memory -e OPENAI_API_KEY=your-openai-api-key -- uvx mcp-super-memory
# Local embeddings (no API key required)
claude mcp add mcp-super-memory -e EMBEDDING_BACKEND=local -- uvx "mcp-super-memory[local]"git clone https://github.com/donggyun112/mcp-super-memory
cd super-memoryCreate .env:
OPENAI_API_KEY=your-openai-api-key
OPENAI_EMBEDDING_MODEL=text-embedding-3-smallOr use local embeddings (no API key required):
EMBEDDING_BACKEND=local
LOCAL_EMBEDDING_MODEL=paraphrase-multilingual-MiniLM-L12-v2 # optional, this is the defaultNote: Mixing backends on existing data will break recall. If switching backends, clear
~/.super-memory/graph.jsonfirst.
uv sync
uv run mcp-super-memoryRequirements:
Python 3.12+
OpenAI API key (for embeddings) — or sentence-transformers for local embeddings
All data is local. No external database required.
data/
├── graph.json # keys, memories, links
└── conversations/
└── {session_id}.jsonl # original conversation turnsLinear scan — suitable for personal use (~10k memories). FAISS/ChromaDB integration planned for larger scale.
2-hop max — deeper associative chains require related() tool calls by the agent.
Agent quality matters — key selection on remember affects retrieval quality. System prompt tuning is important.
A-MEM (NeurIPS 2025) focuses on memory evolution — when new memories arrive, existing memories' descriptions update. Super Memory focuses on memory access — how to reach the right memory through associative paths.
They solve different problems. A-MEM asks "how do we keep memories well-organized?" Super Memory asks "how do we find memories the way humans actually think?"
The versioning approach also differs: A-MEM overwrites on evolution (current state only), Super Memory preserves history (full timeline).
FAISS/ChromaDB for scale
Coding agent profile (different key strategies for code context)
Memory export/import
Multi-user support
MIT
Delete all memories past their ttl. Returns count of deleted memories. Call periodically to keep memory clean.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive action ('Delete all memories past their ttl') and the return behavior ('Returns count of deleted memories'). It also indicates intended frequency ('Call periodically'). No annotations are present, but the key behaviors are disclosed. It doesn't discuss irreversibility, but deletion semantics are implied.
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 three short sentences, each with a distinct purpose: action, return value, and usage recommendation. 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?
With no parameters and an output schema present, the description covers the core operation, return, and usage cadence. It's complete for a simple cleanup tool.
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 tool has zero parameters, so schema coverage is moot. Per the rubric, 0 params earns a baseline of 4.
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 uses a specific verb ('Delete'), identifies the resource ('memories'), and specifies the scope ('past their ttl'), clearly distinguishing this from sibling tools like 'forget' or 'list_memories'.
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?
It explicitly says 'Call periodically to keep memory clean,' providing a clear usage context. It doesn't mention alternatives or exclusions, but the periodic maintenance context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update outdated information. Use when user corrects you or info changes (e.g. moved cities, changed job). Old version is preserved but weakened — never lost. Omit keys to keep the same search terms. related_to links the updated memory to other memory IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | No | ||
| content | Yes | ||
| key_types | No | ||
| memory_id | Yes | ||
| related_to | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility for behavioral disclosure. It reveals a key non-obvious behavior: 'Old version is preserved but weakened — never lost,' which is critical for understanding side effects. It also notes that 'omit keys to keep the same search terms,' adding practical behavior detail, though it doesn't cover every edge case.
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 three sentences, front-loaded with the primary purpose. Every sentence earns its place: purpose, usage, and behavioral notes. There is no fluff or redundant information.
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?
Despite having 5 parameters and no annotations, the description covers purpose, usage, key behavior, and some param semantics. Because an output schema exists, the description needn't explain return values. The only notable gap is the 'key_types' parameter, but overall it provides enough context for effective tool invocation.
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 0%, yet the description adds meaning for some parameters: it explains 'keys' ('Omit keys to keep the same search terms') and 'related_to' ('links the updated memory to other memory IDs'). 'memory_id' and 'content' are implicit from the tool's purpose, but 'key_types' is left completely unexplained, leaving a coverage gap.
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 uses a specific verb+resource: 'Update outdated information,' clearly stating the tool's purpose. It distinguishes itself from siblings like 'remember' (for new info) and 'forget' (for deletion) by focusing on corrections. Examples like 'moved cities, changed job' further clarify its 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?
It explicitly states when to use: 'Use when user corrects you or info changes,' providing clear context for invocation. However, it doesn't explicitly mention when not to use it or name alternative tools, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a memory. Only use for completely wrong information. For outdated info, use correct() instead — it preserves history.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the permanent (irreversible) nature of the deletion, which is the key behavioral trait. The contrast with correct() also implies that forget does not preserve history. However, it does not mention authorization requirements or potential side effects, which would strengthen 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 two sentences, each earning its place. The first states the core purpose concisely, and the second provides essential usage guidance and an alternative. No filler or redundant information.
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?
For a simple delete operation with one parameter and an output schema, the description covers the key aspects: what it does, when to use it, and the alternative. It lacks explicit error handling or idempotency details, but these are less critical given the simplicity and the presence of an output schema.
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 has no parameter descriptions (0% coverage). The description does not explain 'memory_id', its format, or how to obtain it. While the name is fairly self-explanatory, the description adds no semantic meaning beyond the schema, and with low coverage it fails to compensate.
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's function with a specific verb and resource: 'Permanently delete a memory.' It distinguishes itself from the sibling tool 'correct' by pointing out that correct preserves history, making the purpose unambiguous.
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 explicitly states when to use the tool ('Only use for completely wrong information') and when not to use it, directing users to an alternative ('For outdated info, use correct() instead — it preserves history'). This provides clear guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load raw conversation turns from a past session. Use when a recalled memory lacks detail and you need the original context.
| Name | Required | Description | Default |
|---|---|---|---|
| turn | No | ||
| session_id | 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 only states that it loads raw turns, offering no information about side effects, error behavior, data volume, or whether the operation is read-only. This is minimal and leaves important behavioral aspects undisclosed.
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 two sentences, front-loaded with the primary purpose, and contains no filler. Every sentence contributes to understanding the tool's purpose and usage context, 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?
The description gives a clear purpose and usage context, and the output schema covers return values. However, it does not fully explain the parameters, especially 'turn', and lacks details about potential edge cases. For a simple retrieval tool this is adequate but has clear gaps in parameter semantics.
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 0%, so the description must compensate. It hints at 'session_id' via 'past session' but does not explain the 'turn' parameter at all. The description adds only marginal meaning beyond the schema, leaving the optional 'turn' parameter ambiguous.
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 ('Load') and the resource ('raw conversation turns from a past session'), which is specific and distinct from sibling tools like recall or remember. It also differentiates itself by referencing 'raw' context, implying it provides more detail than recalled memories.
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 explicit guidance on when to use the tool: 'Use when a recalled memory lacks detail and you need the original context.' This implies when the recall tool is insufficient and gives clear context, though it does not explicitly name the alternative or state exclusion conditions.
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. namespace filters by project/context. Expired memories are excluded. Prefer recall() for normal retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses a key behavior: 'Expired memories are excluded.' It implies that omitting namespace lists all memories, but doesn't mention pagination or authentication, leaving some gaps.
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?
Three short sentences, each earning its place: the action, the parameter behavior, and the alternative guidance. Front-loaded and free of redundant wording.
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?
For a simple one-param tool with an output schema, the description covers purpose, param semantics, an exclusion behavior, and an alternative. It could mention ordering or pagination, but the given detail is adequate for this tool's complexity.
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 has no descriptions for the namespace parameter, so the description's statement that it 'filters by project/context' adds crucial meaning. However, it doesn't explain the default behavior when namespace is null, so compensation is partial.
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 opens with 'List all stored memories,' which is a specific verb+resource statement. It also distinguishes from siblings by noting 'Prefer recall() for normal retrieval,' making it clear this is for bulk listing rather than targeted retrieval.
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 explicitly provides an alternative: 'Prefer recall() for normal retrieval,' which tells the agent when not to use this tool. It also clarifies the namespace parameter usage, giving context for project/context filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get counts of keys, memories, and links in the system.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly implies a read-only operation ('get counts') and discloses no side effects, but it does not elaborate on what exactly is included (e.g., expired memories, links across all namespaces) or the return format beyond what the output schema likely provides. This is adequate for a simple stats tool but not rich.
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, concise sentence that immediately states the tool's purpose. Every word earns its place, and the structure is ideal for quick comprehension.
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?
The tool is simple with no parameters and an output schema that presumably documents return values. The description sufficiently communicates the scope ('counts of keys, memories, and links') without needing further detail. It could mention that it's a read-only stats endpoint, but the verb 'get' already implies this.
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?
There are zero parameters, so the baseline is 4. The description adds no parameter-level detail because none is needed. The schema-driven coverage is effectively perfect, and the description's mention of keys, memories, and links aligns with the tool's purpose.
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's function: retrieving counts of keys, memories, and links. This is a specific verb+resource combination that distinguishes it from sibling tools like recall or list_memories, which deal with individual items rather than aggregate statistics.
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 explicit guidance is given about when to use this tool versus alternatives. The description does not mention that it should be used for aggregate overviews instead of listing memories, nor does it mention any exclusions or trade-offs. The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CALL THIS FIRST before every first response. Search long-term memory by concept. namespace filters to a specific project/context. expand=True returns up to 2x results by following explicit memory links — use when initial results feel insufficient. Returns memories ranked by relevance with hop=1 (direct) or hop=2 (associative). Memories get stronger each time they're recalled.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| expand | No | ||
| namespace | No |
| 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 reveals important behaviors: memory ranking by relevance, hop=1 vs hop=2, and that 'Memories get stronger each time they're recalled.' This gives the agent a clear picture of side effects and retrieval semantics beyond the schema.
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 dense paragraph but every sentence contributes value—the imperative call order, the core purpose, parameter nuances, output mechanics, and memory strengthening effect. It is front-loaded with the most critical usage instruction.
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?
The tool has four parameters and no annotations, but the description covers the key concepts: namespace, expansion, hop levels, and relevance ranking. An output schema exists, so return value details are not needed. Minor gaps include lack of mention of empty results or error behavior, but overall it is well-rounded.
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 has 0% description coverage, so the description must compensate. It explains namespace ('filters to a specific project/context'), expand ('returns up to 2x results'), and implies query semantics through 'search by concept.' top_k is not explicitly explained, but ranking by relevance with a default value makes it self-explanatory.
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's function: 'Search long-term memory by concept.' It explicitly instructs to call it first before every response, distinguishing it from sibling tools like remember or list_memories. The namespace and expand parameters are also described with specific behavior.
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?
Provides strong when-to-use guidance: 'CALL THIS FIRST before every first response' and suggests expand=True 'when initial results feel insufficient.' However, it does not explicitly mention when not to use it or name alternatives like list_memories or related, so it falls short of full alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save important information to memory. Keys are search terms — think 'what would I search to find this later?' Use 3-6 diverse keys. namespace groups memories by project/context (e.g. 'work', 'personal'). ttl_seconds sets expiry for temporary memories (e.g. 3600 = 1 hour; None = permanent). related_to links this memory to existing memory IDs for explicit graph traversal.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | Yes | ||
| content | Yes | ||
| key_types | No | ||
| namespace | No | default | |
| related_to | No | ||
| ttl_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It does disclose important behaviors like ttl_seconds expiry, permanent when None, and related_to for graph traversal. Yet it doesn't mention potential side effects like overwriting existing memories, permissions, or persistence guarantees, leaving room for ambiguity.
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 remarkably concise: four sentences cover the main purpose and all key parameters without unnecessary detail. The first sentence frontloads the action, and the subsequent parameter explanations are telegraphic but highly informative.
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?
The description is largely complete for a write operation: it explains key selection, namespaces, TTL, and relations, and the output schema covers return values. The main gaps are key_types semantics and any guidance about using remember_batch for bulk writes, which would have made it fully complete.
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 adds significant meaning for keys (search terms, 3-6 diverse), namespace (project/context), ttl_seconds (with example and permanent default), and related_to (graph traversal). However, key_types is not explained at all, and schema coverage is 0%, so the description only partially compensates for the missing 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 opens with 'Save important information to memory', clearly stating the action and resource. The verb 'save' distinguishes it from retrieval, deletion, and batch siblings, and the parameter explanations reinforce its write-purpose.
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 practical guidance on key selection ('think what would I search to find this later?'), namespace usage with examples, and TTL vs permanent storage, which implies when to set expiry. However, it doesn't explicitly mention when to use alternatives like recall or remember_batch, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save multiple memories in one call. Each item: {content, keys, key_types?, namespace?, ttl_seconds?, related_to?}. Returns list of saved IDs. More efficient than multiple remember() calls.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full responsibility. It discloses that the tool saves memories and returns a list of saved IDs. It also outlines the item structure (content, keys, etc.), which is useful. However, it omits important behavioral aspects such as partial failure handling, whether the operation is atomic, or any validation or permission requirements.
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 two sentences long, front-loads the main purpose, and includes no redundant information. Every sentence adds value: the first explains the core action, the second details the item schema and return value.
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?
With an output schema present, the return values are likely covered, so the description's mention of returning saved IDs is a bonus. The tool is a batch operation with potential complexity (e.g., partial failures, limits), but the description does not address these. It is adequate for basic usage but not fully complete.
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 provides no descriptions and has a coverage of 0%, so the description must compensate. It lists the expected fields for each item (content, keys, key_types?, namespace?, ttl_seconds?, related_to?), which adds meaning beyond the empty schema. However, it does not explain what each field means, which are required, or any constraints, leaving gaps for the agent.
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's function: 'Save multiple memories in one call.' It identifies the resource (memories) and the batch nature. It also distinguishes itself from the sibling tool remember() by stating it is 'More efficient than multiple remember() calls,' making the purpose unambiguous.
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 explicitly names the alternative tool (remember()) and positions remember_batch as the more efficient choice for batch saving. This gives the agent clear guidance on when to prefer this tool over the singular variant.
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.4.4cleanup_expiredcorrectforgetget_conversationlist_memoriesmemory_statsrecallrelatedrememberremember_batchScored across 10 tools
Each tool has a distinct role in the memory lifecycle: creation (remember, remember_batch), retrieval (recall, list_memories, get_conversation), update (correct), deletion (forget), exploration (related), and maintenance (cleanup_expired, memory_stats). The overlap between remember and remember_batch is clearly explained as single vs batch.
Names are consistently lowercase snake_case with clear verbs (recall, remember, correct, forget) and noun-prefixed operations (get_conversation, list_memories, memory_stats). No mixed conventions like camelCase or inconsistent verb styles.
Ten tools provide comprehensive coverage without redundancy. Each tool earns its place, covering CRUD, batch operations, exploration, and system maintenance.
The set covers the full memory lifecycle: save, search, list, update, delete, link exploration, batch save, and maintenance. A minor gap is the lack of a direct 'get memory by ID' tool, though recall and related can surface memory content.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Graph memory for AI agents: entities, cause-effect links, cross-session recall, time travel.
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
