de en es ja ko ru zh

YourMemory

Name: YourMemory
Author: sachitrafa

by sachitrafa

Overview Schema Related Servers Score Discussions

Python

Hybrid

Persistent memory for AI agents — built on the science of how humans remember.

PyPI PyPI Downloads License: CC BY-NC 4.0 LoCoMo Recall@5 LongMemEval Recall@5 Docker Build

The Problem

Every session, your AI assistant starts from zero. It asks the same questions, forgets your preferences, re-learns your stack. There is no memory between conversations.

YourMemory fixes that. It gives AI agents a persistent memory layer that works the way human memory does — important things stick, forgotten things fade, outdated facts get replaced automatically. One command to install, zero infrastructure required. Memory starts working the moment you add it to your AI client.

Related MCP server: Recall

How Well Does It Work?

LoCoMo-10 — 1,534 QA pairs across 10 multi-session conversations

System	Recall@5	95% CI
YourMemory (BM25 + vector + graph + decay)	59%	56–61%
Zep Cloud	28%	26–30%

2× better recall than Zep Cloud on the same benchmark.

The 59% result used all-mpnet-base-v2. The current default model (multi-qa-mpnet-base-dot-v1) scores 55% on LoCoMo session-summary retrieval — see BENCHMARKS.md for details.

LongMemEval-S — 500 questions, ~53 sessions each

System	Recall-all@5	nDCG@5
YourMemory (full stack · `multi-qa-mpnet-base-dot-v1`)	85%	87%

HotpotQA — 200 multi-hop questions requiring two facts from different articles

System	BOTH_FOUND@5
YourMemory (vector + BM25 + entity graph)	71.5%
YourMemory (similarity graph only — no entity edges)	59.5%

Entity-based graph edges link memories that share named entity mentions — enabling the system to follow a chain of facts rather than just retrieve by similarity.

Full methodology in BENCHMARKS.md. Writeup: I built memory decay for AI agents using the Ebbinghaus forgetting curve.

Quick Start

Supports Python 3.11–3.14. No Docker, no database setup, no external services.

Step 1 — Install

pip install yourmemory

Step 2 — Get your config path

yourmemory-path

Prints your full executable path and a ready-to-paste config block. Copy it.

Step 3 — Wire into your AI client

Add to ~/.claude/settings.json:

{
  "mcpServers": {
    "yourmemory": {
      "command": "yourmemory"
    }
  }
}

Reload (Cmd+Shift+P → Developer: Reload Window).

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "yourmemory": {
      "command": "yourmemory"
    }
  }
}

Restart Claude Desktop.

VS Code doesn't inherit your shell PATH. Run yourmemory-path first to get the full executable path.

In Cline → MCP Servers → Edit MCP Settings:

{
  "mcpServers": {
    "yourmemory": {
      "command": "/full/path/to/yourmemory",
      "args": [],
      "env": { "YOURMEMORY_USER": "your_name" }
    }
  }
}

Restart Cline after saving.

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "yourmemory": {
      "command": "/full/path/to/yourmemory",
      "args": [],
      "env": { "YOURMEMORY_USER": "your_name" }
    }
  }
}

YourMemory is a standard stdio MCP server. Use the full path from yourmemory-path if the client doesn't inherit shell PATH.

{
  "mcpServers": {
    "yourmemory": {
      "command": "/full/path/to/yourmemory",
      "env": { "YOURMEMORY_USER": "your_name" }
    }
  }
}

First start is automatic. On the first run, YourMemory initialises your database, downloads the language model, and injects memory workflow instructions into your AI client config — no manual setup needed.

Step 4 — Start remembering

That's it. On the first MCP start, YourMemory automatically:

Initialises your local database at ~/.yourmemory/memories.duckdb
Downloads the spaCy language model in the background
Injects the memory workflow rules into your AI client

Your AI now recalls what it learned in previous sessions, without you telling it to.

Memory Dashboard

Every YourMemory instance ships with two built-in browser UIs — no extra setup, no separate process. They start automatically when the MCP server starts.

Memory Browser — `http://localhost:3033/ui`

A full read-only view of everything stored in memory for any user.

Stats bar — four live counters at the top:

Counter	What it means
Total memories	All stored memories for the active view
Strong ≥ 50%	Healthy — will survive the next decay cycle
Fading 5–50%	Weakening — will survive but need reinforcement
Near prune < 10%	At risk — will be deleted in the next 24h pruning job

Agent tabs — switch between views without reloading:

🧠 All — every memory for the user
👤 User — only memories stored by the user directly (no agent writes)
🤖 <agent-id> — one tab per registered agent, showing only that agent's memories

Filters and sorting:

Control	Options
Category	All · fact · strategy · assumption · failure
Sort	Strength (default) · Most recent · Recall count

Memory cards — each card shows:

Full memory content
Strength bar — color-coded green → cyan → yellow → red as strength falls
Strength percentage, category badge, agent badge (👤 user or 🤖 agent-id)
Memory ID, importance score, recall count, last accessed date

URL shortcut — pass ?user=<id> to auto-load on open:

http://localhost:3033/ui?user=sachit

Graph Visualization — `http://localhost:3033/graph`

An interactive map of how memories are connected. Requires a memoryId to use as the center node.

http://localhost:3033/graph?memoryId=42&userId=sachit&depth=2

Parameter	Default	Description
`memoryId`	required	Center node to visualise from
`userId`	`sachit`	User whose memories to load
`depth`	`2`	BFS traversal depth (1–3)

What you see:

The root memory as a larger cyan node
Connected memories as smaller nodes, color-coded by category — green (strategy), red (failure), purple (assumption), blue (fact)
Edges weighted by semantic similarity — thicker edges = stronger connection
Click any node to see its full content in the side panel
Drag, zoom, and reposition the graph freely

JSON API — get the raw graph data for any memory:

http://localhost:3033/graph/data?memoryId=42&userId=sachit&depth=2

Returns Cytoscape.js-compatible nodes and edges with weights, categories, and root flags.

Ask Without Calling the API

The only memory system that can answer questions from memory without making any LLM API call.

Every other system (Mem0, Zep, LangMem, Cognee) follows the same pattern: retrieve → inject into context → call your LLM. YourMemory has a ask command that short-circuits that loop entirely for trivial factual queries.

yourmemory ask "what database does this project use"
# → YourMemory uses DuckDB locally and Postgres in production.

yourmemory ask "what port does the dashboard run on"
# → 3033

yourmemory ask "how do I deploy to kubernetes"
# → Not enough memory context to answer without Claude.

When memory is strong enough to answer confidently, it responds instantly — zero tokens, zero cloud cost, zero latency. When it isn't, you get a clean decline rather than a hallucinated answer.

Why this matters

	Mem0 / Zep / LangMem	YourMemory
"What port does the server run on?"	Full LLM API call	Answered instantly, $0
"What database does this project use?"	Full LLM API call	Answered instantly, $0
"How do I fix a k8s deployment?"	Full LLM API call	Declines cleanly → Claude
Privacy	Query sent to cloud	Query never leaves your machine

MCP Tools

Three tools, called by your AI automatically.

Tool	When	What it does
`recall_memory(query, current_path?)`	Start of every task	Surfaces relevant memories ranked by similarity × strength; boosts spatially matched memories
`store_memory(content, importance, context_paths?)`	After learning something new	Embeds and stores with biological decay; tags optional file/dir paths for spatial recall
`update_memory(id, new_content)`	When a memory is outdated	Re-embeds and replaces; logs old content to audit trail

# Store with spatial context
store_memory("Sachit prefers tabs over spaces in Python", importance=0.9, category="fact",
             context_paths=["/projects/backend"])

# Next session — spatial boost applied when working in that path:
recall_memory("Python formatting", current_path="/projects/backend")
# → {"content": "Sachit prefers tabs over spaces in Python", "strength": 0.87, "score": 0.81}

Categories control how fast memories fade

Category	Survives without recall	Use case
`strategy`	~38 days	Successful patterns
`fact`	~24 days	Preferences, identity
`assumption`	~19 days	Inferred context
`failure`	~11 days	Errors, environment-specific issues

How It Works

Ebbinghaus Forgetting Curve

Memory strength decays exponentially — importance and recall frequency slow that decay:

effective_λ  = base_λ × (1 - importance × 0.8)
strength     = clamp(importance × e^(−effective_λ × active_days) × (1 + recall_count × 0.2), 0, 1)
hybrid_score = 0.4 × bm25_norm + 0.6 × cosine_similarity

active_days counts only days the user was active — vacations don't cause memory loss. Decay is used for pruning only, not ranking. Memories below strength 0.05 are pruned automatically every 24 hours.

Session wrap-up scoring: recalled memory IDs are tracked per session and get a recall_count boost when the session goes idle (30 min default). Set YOURMEMORY_SESSION_IDLE to change the window.

Recall throttling: identical (user, query) pairs are cached to avoid redundant retrieval within a configurable window. Set YOURMEMORY_RECALL_COOLDOWN (seconds, default 0 = off).

Hybrid Retrieval: Vector + BM25 + Graph

Retrieval runs in two rounds to surface related context that vocabulary-based search misses:

Round 1 — Hybrid search: cosine similarity + BM25 keyword scoring, returns top-k above threshold.

Round 2 — Graph expansion: BFS traversal from Round 1 seeds surfaces memories that share context but not vocabulary — connected via semantic edges (cosine similarity ≥ 0.4).

recall("Python backend")
  Round 1 → [1] Python/MongoDB    (sim=0.61)
             [2] DuckDB/spaCy     (sim=0.19)
  Round 2 → [5] Docker/Kubernetes (sim=0.29 — below cut-off, surfaced via graph)

Chain-aware pruning: A decayed memory is kept alive if any graph neighbour is above the prune threshold. Related memories age together.

Subject-Aware Deduplication

When storing a new memory, YourMemory compares the incoming content against the nearest existing memory. Before merging, it verifies the two memories are about the same entity — not just the same topic.

"Sachit uses DuckDB"    vs  "YourMemory uses DuckDB"
 subject: Sachit             subject: YourMemory
 → different entities → stored as two separate facts ✓

"YourMemory uses DuckDB"  vs  "YourMemory stores data in DuckDB"
 subject: YourMemory           subject: YourMemory
 → same entity → merged ✓

Subject comparison embeds the first two words of each sentence and compares them semantically — no hardcoded word lists, generalises to any sentence structure or language.

Multi-Agent Memory

Multiple agents can share the same YourMemory instance — each with isolated private memories and controlled access to shared context.

from src.services.api_keys import register_agent

result = register_agent(
    agent_id="coding-agent",
    user_id="sachit",
    can_read=["shared", "private"],
    can_write=["shared", "private"],
)
# → result["api_key"]  — ym_xxxx, shown once only

Pass api_key to any MCP call to authenticate as an agent:

store_memory(content="Staging uses self-signed cert — skip SSL verify",
             importance=0.7, category="failure",
             api_key="ym_xxxx", visibility="private")

recall_memory(query="staging SSL", api_key="ym_xxxx")
# → returns shared memories + this agent's private memories
# → other agents see shared only

Stack

Component	Role
DuckDB	Default vector DB — zero setup, native cosine similarity
NetworkX	Default graph backend — persists at `~/.yourmemory/graph.pkl`
sentence-transformers	Local embeddings (`multi-qa-mpnet-base-dot-v1`, 768 dims)
spaCy	Local NLP for deduplication and SVO triple extraction
APScheduler	Automatic 24h decay job
PostgreSQL + pgvector	Optional — for teams or large datasets
Neo4j	Optional graph backend — `pip install 'yourmemory[neo4j]'`

pip install yourmemory[postgres]

Create a .env file:

DATABASE_URL=postgresql://YOUR_USER@localhost:5432/yourmemory

macOS

brew install postgresql@16 pgvector && brew services start postgresql@16
createdb yourmemory

Ubuntu / Debian

sudo apt install postgresql postgresql-contrib postgresql-16-pgvector
createdb yourmemory

Architecture

Claude / Cline / Cursor / Any MCP client
    │
    ├── recall_memory(query, current_path?, api_key?)
    │       └── throttle check (YOURMEMORY_RECALL_COOLDOWN)
    │               embed → vector similarity (Round 1)
    │               → graph BFS expansion  (Round 2)
    │               → score = sim × strength → top-k
    │               → spatial boost (+0.08) if current_path matches context_paths
    │               → session tracking → recall_count bump on session end
    │
    ├── store_memory(content, importance, category?, context_paths?, visibility?, api_key?)
    │       └── question? → reject
    │               subject-aware dedup → same entity? merge/reinforce : new
    │               embed() → INSERT → index_memory() → graph node + edges
    │               record_activity(user_id) → active days log
    │
    └── update_memory(id, new_content, importance)
            └── log old content → memory_history (audit trail)
                    embed(new_content) → UPDATE → refresh graph node

  Vector DB (Round 1)             Graph DB (Round 2)
  DuckDB (default)                NetworkX (default)
    memories.duckdb                 graph.pkl
    ├── embedding FLOAT[768]        ├── nodes: memory_id, strength
    ├── importance FLOAT            └── edges: sim × verb_weight ≥ 0.4
    ├── recall_count INTEGER
    ├── context_paths JSON        Neo4j (opt-in)
    ├── visibility VARCHAR          └── bolt://localhost:7687
    ├── agent_id VARCHAR
    user_activity (active days log)
    memory_history (supersession audit)

Contributing

PRs are welcome. See CONTRIBUTORS.md for the people who have already improved YourMemory.

Dataset Reference

Benchmarks use the LoCoMo dataset by Snap Research.

Maharana et al. (2024). LoCoMo: Long Context Multimodal Benchmark for Dialogue. Snap Research.

License

Free for: personal use, education, academic research, open-source projects.
Not permitted: commercial use without a separate written agreement.

Commercial licensing: mishrasachit1@gmail.com

Available Tools

5 tools

memory_getA

Stage 2 of two-stage recall. Returns the FULL content of one memory PLUS its connected graph neighbourhood (related facts) — the 'connected region'. Use after memory_search to pull depth on demand without re-reading files.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Memory id from memory_search results.
`user_id`	No	User identifier (default: 'root').
`neighbors`	No	How many connected neighbours to include (default: 5).

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description clearly states it is a read operation returning full content and connected neighborhood, implying non-destructive behavior. No mention of auth or rate limits, but acceptable for a read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, front-loaded with the key purpose and contextual usage. Each word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains what is returned (full content + neighborhood). Could be slightly richer on the structure of the connected region, but sufficient for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. The description adds context about the 'id' coming from memory_search but does not add new meaning beyond the schema for the other parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies a clear verb ('Returns'), resource ('FULL content of one memory PLUS its connected graph neighbourhood'), and distinguishes from siblings like memory_search by calling this 'Stage 2'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use after memory_search' and explains it provides 'depth on demand without re-reading files', giving clear context but not listing exclusions or alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_searchA

Stage 1 of two-stage recall (progressive disclosure). Returns a COMPACT index of relevant memories (id + short summary + score) — cheap to scan. Use this first, then call memory_get on the IDs you want, instead of re-reading source files.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	What to look for in memory.
`top_k`	No	Max results (default: 8).
`user_id`	No	User identifier (default: 'root').

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses output structure (id, summary, score) and performance characteristic ('cheap to scan'). However, it does not explicitly state non-destructive behavior, though it is implied by a search operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Key information is front-loaded: stage, output nature, and usage recommendation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description sufficiently describes return format and explains workflow with sibling tool. For this complexity level, it is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3. Description does not add additional semantic detail beyond what is in the schema for parameters like query, top_k, and user_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it is 'Stage 1 of two-stage recall' returning a compact index of relevant memories (id + short summary + score). Distinguishes from sibling tools like memory_get by specifying it is a cheap-to-scan first step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to 'Use this first, then call memory_get on the IDs you want, instead of re-reading source files,' providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recall_memoryA

Retrieve memories relevant to a query. Retrieve relevant memories about the user's preferences, past instructions, and known facts. Call this when persistent context would help answer the current request. Returns a list of memories with their IDs.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Keywords or sentence describing what to look for in memory.
`top_k`	No	Max memories to return (default: 5).
`api_key`	No	Agent API key (starts with 'ym_'). If provided, also returns this agent's private memories. If omitted, returns shared memories only.
`user_id`	No	User identifier (default: 'root').
`current_path`	No	Current working file or directory path. Memories tagged with matching paths receive a relevance boost.

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses key behavioral traits: the return format (list with IDs) and the scoping of memories via the API key parameter (private vs shared). It does not mention read-only nature or side effects, but for a retrieval tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, all front-loaded with the main action and essential details. Every sentence contributes unique value: the action, the content type, usage context, and return format. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a retrieval tool with 5 parameters and no output schema, the description adequately explains the return format (list of memories with IDs). It could benefit from mentioning what fields each memory contains, but given the lack of nested objects and enums, it is still complete enough for an agent to use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what is already in the schema's parameter descriptions. The schema itself sufficiently documents each parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves memories relevant to a query, with specific mention of user preferences, past instructions, and facts. However, it does not distinguish itself from sibling tools like memory_get or memory_search, which likely have similar functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Call this when persistent context would help answer the current request,' providing a when-to-use condition. However, it does not specify when not to use it or mention alternative tools among the siblings, so the guidance is implied but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

store_memoryA

Store a new memory about the user. Use when you learn a new fact, preference, instruction, past failure, or successful strategy. Does not conflict with any memory returned by recall_memory.

ParametersJSON Schema

Name	Required	Description
`api_key`	No	Agent API key (starts with 'ym_'). Required for agent-scoped memory. If omitted, stored as 'user' with shared visibility.
`content`	Yes	The fact, preference, failure, or strategy to remember.
`user_id`	No	User identifier (default: 'root').
`category`	No	Memory category — controls decay rate: 'fact' — user preferences, identity, stable knowledge (default, ~24 day survival) 'assumption' — inferred beliefs, uncertain context (~19 days) 'failure' — what went wrong in a past task, environment-specific errors (~11 days, decays fast) 'strategy' — what worked well in a past task, approach patterns (~38 days, decays slow) Use 'failure' when storing e.g. 'OAuth failed for client X due to wrong redirect URI'. Use 'strategy' when storing e.g. 'Using pagination fixed the timeout on large DB queries'.
`created_at`	No	ISO8601 timestamp to use as the memory's creation time. Overrides the default (now). Useful for backfilling historical memories.
`importance`	No	You MUST decide this. How important is this memory? (0.0–1.0) 0.9–1.0 — core identity, permanent preferences (e.g. 'Sachit uses Python') 0.7–0.8 — strong preferences, recurring patterns 0.5 — regular facts, project decisions 0.2–0.3 — transient context, one-off notes from this session
`visibility`	No	Who can recall this memory: 'shared' (any agent, default) or 'private' (only this agent).
`context_paths`	No	File or directory paths this memory is associated with (e.g. ['src/services/', 'pyproject.toml']). Used for spatial relevance boosting during retrieval.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It adds a behavioral assurance (no conflict with recall_memory) but lacks details on error handling, side effects, or persistence guarantees. The schema provides some behavioral info like decay rates and importance ranges, but description itself is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no extraneous information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple store operation with 8 well-documented parameters and no output schema, the description is adequate. It covers when to use and a behavioral distinction. Could mention return value or failure modes, but overall complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter already has a detailed description. The tool description does not add meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool stores a new memory about the user and specifies concrete use cases (fact, preference, instruction, past failure, strategy). It also distinguishes from sibling recall_memory by noting no conflict.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('Use when you learn...'), and clarifies no conflict with recall_memory. However, it does not mention when not to use or provide alternatives among siblings like memory_search or update_memory.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_memoryA

Merge or replace an existing memory by its ID. Use when a recalled memory is outdated (replace) or when new info adds detail to an existing memory (merge — write the combined sentence as new_content).

ParametersJSON Schema

Name	Required	Description
`user_id`	No	User identifier (default: 'root').
`memory_id`	Yes	ID of the memory to update (from recall_memory results).
`importance`	No	You MUST decide this. Re-evaluate importance after the update. (0.0–1.0) 0.9–1.0 — core identity, permanent preferences 0.7–0.8 — strong preferences, recurring patterns 0.5 — regular facts, project decisions 0.2–0.3 — transient context, one-off notes
`new_content`	Yes	The updated or merged memory text.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears full burden. It adds value by explaining merge vs. replace semantics, but lacks details on error handling, idempotency, or side effects. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences that front-load the core purpose and follow with usage guidance. Every sentence is informative and not redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite low complexity, the description omits important context: it does not mention the 'importance' parameter (which the schema marks as mandatory) nor the return value. For a mutation tool, this leaves gaps in understanding the full behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The tool description does not add extra parameter semantics beyond the schema, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('merge or replace') and resource ('existing memory by its ID'). It distinguishes from sibling tools (memory_get, memory_search, recall_memory, store_memory) by specifying it is for updating existing memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides two specific use cases: replace when outdated, merge when adding detail. This guides the agent on when to use this tool vs. alternatives, even though it does not explicitly list when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.4.83Jul 9, 2026
- First observedmemory_get
- First observedmemory_search
- First observedrecall_memory
- First observedstore_memory
- First observedupdate_memory

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation3/5

Memory_search and recall_memory both retrieve memories but with different output formats, causing potential confusion. Memory_get is clearly for full content after search, but the presence of two similar retrieval tools may lead to misselection.

Naming Consistency2/5

Tool names mix noun_verb (memory_get, memory_search) and verb_noun (store_memory, update_memory, recall_memory) patterns. Recall_memory lacks the 'memory_' prefix, breaking consistency further.

Tool Count4/5

Five tools is a reasonable count for a memory system, covering retrieval and modification. The three retrieval tools are slightly redundant but still within acceptable bounds for a specialized server.

Completeness3/5

The set includes store, multiple reads, and update, but lacks a delete tool, which is a notable gap for full lifecycle management. The two-stage retrieval mechanism adds depth but also redundancy.

Maintenance

ActivitySlowing

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

UltraMemoryOAuth
io.github.LogicLabsAI
One memory, every AI: Claude, ChatGPT, Perplexity, Gemini, Cursor, OpenClaw, Hermes, any MCP client.
Knowledge & Memory Autonomous Agents
21
VAAS-X Cognitive MemoryOAuth
io.github.VAAS-X
Persistent, outcome-grounded episodic memory for Claude. 14ms CPU retrieval, no GPU, no vector DB.
Knowledge & Memory AI & Machine Learning Autonomous Agents
1
Agentverse Memory
io.github.fetchai
Graph-native persistent memory for AI agents — 33 MCP tools, zero-LLM writes.
Knowledge & Memory Autonomous Agents
2
memory
com.lodekeep
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
Knowledge & Memory File Systems
1

Related MCP Servers

YantrikDB MCP
Knowledge & Memory Autonomous Agents AI & Machine Learning
yantrikos
A
license
A
quality
A
maintenance
Cognitive memory for AI agents. Works with Claude Code, Cursor, Windsurf, and any MCP-compatible client.
Updated 5 hours ago (2026-09-06 08:25 UTC)
20
24
MIT
Recallofficial
Knowledge & Memory RAG Systems
RecallWorks
A
license
Not graded
quality
C
maintenance
Open-source MCP memory server for AI agents — persistent, searchable, tiered memory across sessions. Works over stdio (Cursor, Claude Desktop) or HTTP+SSE. MIT licensed.
Updated 3 months ago (2026-06-16 08:03 UTC)
7
MIT
dakera-mcpofficial
Knowledge & Memory Vector Databases Autonomous Agents
Dakera-AI
F
license
A
quality
B
maintenance
Self-hosted MCP-native agent memory server. Gives AI agents persistent, decay-weighted memory via 83 MCP tools — no cloud, full control. RocksDB+HNSW backend. Works with Claude Code, Cursor, and any MCP-compatible agent.
Updated 20 days ago (2026-08-17 03:09 UTC)
14
8
-
Decay Memory
Knowledge & Memory AI & Machine Learning
trssantos
A
license
Not graded
quality
D
maintenance
An MCP server that gives AI agents persistent, forgetting memory with layered decay, semantic search via token overlap, and zero external dependencies.
Updated 6 months ago (2026-02-28 23:37 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sachitrafa/YourMemory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

The Problem

How Well Does It Work?

LoCoMo-10 — 1,534 QA pairs across 10 multi-session conversations

LongMemEval-S — 500 questions, ~53 sessions each

HotpotQA — 200 multi-hop questions requiring two facts from different articles

Quick Start

Step 1 — Install

Step 2 — Get your config path

Step 3 — Wire into your AI client

Step 4 — Start remembering

Memory Dashboard

Memory Browser — http://localhost:3033/ui

Graph Visualization — http://localhost:3033/graph

Ask Without Calling the API

Why this matters

MCP Tools

Categories control how fast memories fade

How It Works

Ebbinghaus Forgetting Curve

Hybrid Retrieval: Vector + BM25 + Graph

Subject-Aware Deduplication

Multi-Agent Memory

Stack

Architecture

Contributing

Dataset Reference

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Recallofficial

dakera-mcpofficial

Latest Blog Posts

MCP directory API

Memory Browser — `http://localhost:3033/ui`

Graph Visualization — `http://localhost:3033/graph`