Which integrations are available for this server?

Supports PostgreSQL with pgvector as a high-performance backend for storing and performing vector similarity searches on persistent memory datasets. Uses SQLite as a zero-configuration local storage engine for managing persistent memory and vector embeddings without external infrastructure.

de en es ja ko ru zh

YourMemory

by sachitrafa

Overview Schema Related Servers Score Discussions

Python

Hybrid

Your AI has the memory of a goldfish. Not anymore.

Persistent, self-improving memory for AI agents — built on the science of how humans remember.

PyPI PyPI Downloads Python License: CC BY-NC 4.0 GitHub Stars

LoCoMo Recall@5 LongMemEval Recall@5 HotpotQA BOTH@5 MCP Native

▶ Try the live interactive demo · Website · Benchmarks

The problem

Every morning your AI agent treats you like a stranger. Same context re-explained. Same preferences forgotten. Every session starts from zero.

Most "memory" tools bolt a vector database onto an agent and call it done — but that's just storage. It hoards every near-duplicate until retrieval drowns in noise. A goldfish with a bigger bowl.

YourMemory is different: memory that works like a brain, not a database.

flowchart LR
    A["🧠 You tell your<br/>AI something"] --> B["Extract durable<br/>facts"]
    B --> C["Dedup + embed<br/>+ graph-link"]
    C --> D[("Memory<br/>store")]
    D -->|"related facts pile up"| E["✨ Consolidate<br/>N → 1 summary"]
    D -->|"stale + unused"| F["📉 Decay<br/>+ prune"]
    D -->|"new session"| G["♻️ Recall<br/>hybrid + graph"]
    E --> D
    G --> H["🤖 Your agent<br/>picks up where<br/>it left off"]
    style D fill:#0a2540,stroke:#19cdff,color:#fff
    style E fill:#0c2b3a,stroke:#5eead4,color:#fff
    style H fill:#0c2b3a,stroke:#19cdff,color:#fff

Related MCP server: Recall

✨ What makes it different

	Feature	What it does
🧠	Consolidation	When enough related facts accumulate, they're compressed into one clean summary and the originals are archived. Memory gets sharper over time, not bloated.
📉	Biological decay	Every memory ages on an Ebbinghaus forgetting curve. Stale, unused facts fade; important and frequently-recalled ones persist.
🔗	Entity graph	Memories link by shared people, places, and concepts — so recall surfaces what you forgot to ask for.
♻️	Survives context resets	When the context window compacts, YourMemory hands the working context back — no re-reading files to figure out where you were.
🔒	Tamper-evident audit trail	Every read / write / delete is logged in a hash-chained ledger. Alter one record and the chain breaks.
👥	Team memory pools	Role-based shared memory, so a whole team's agents draw on the same institutional knowledge — with private memories kept private.
🛡️	Data rights built in	One-command export (right to access) and right-to-forget (purge), plus SOC 2-aligned controls.
🔌	MCP-native & local-first	Works with Claude, Cursor, Cline, Windsurf, or any MCP client. Runs entirely on your machine — no API key, nothing leaves your system.

One command to install. DuckDB by default (zero setup), Postgres + pgvector for teams.

🏆 Benchmarks

Three external datasets. Every number independently reproducible — benchmark code lives in the repo. Full methodology in BENCHMARKS.md.

LoCoMo-10 — multi-session conversational memory

xychart-beta
    title "Recall@5 · LoCoMo-10 (higher is better)"
    x-axis ["Mem0", "Zep Cloud", "Supermemory", "YourMemory"]
    y-axis "Recall@5 percent" 0 --> 70
    bar [18, 28, 31, 59]

2× better recall than Zep Cloud across all 10 samples. *Supermemory and Mem0 exhausted free-tier quotas mid-benchmark; scores computed over the full 1,534 pairs.

LongMemEval-S — 500 questions, ~53 distractor sessions each

The hardest standard benchmark for long-term memory. Each question is buried in ~53 sessions.

Metric	Score
Recall@5 (any gold session in top-5)	89.4%
Recall-all@5 (all gold sessions in top-5)	84.8%
nDCG@5 (ranking quality)	87.4%

HotpotQA — 200 multi-hop questions

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

Entity graph edges add +12 pp — they traverse from Fact 1 to Fact 2 even when Fact 2 has low embedding similarity to the query.

Writeup: I built memory decay for AI agents using the Ebbinghaus forgetting curve

🚀 Quick Start

Python 3.11–3.14. No Docker, no database setup. All memory stored locally in ~/.yourmemory/.

pip install yourmemory
yourmemory-register <your-token>
yourmemory-setup

Get your token: visit yourmemoryai.xyz → enter your email → verify with a 6-digit code → copy your token.

yourmemory-setup auto-detects and wires up Claude Code, Claude Desktop, Cursor, Windsurf, and Cline, then asks which backend to use:

DuckDB — zero setup, single local file (default)
Postgres — shared / production; you provide a DATABASE_URL (needs the pgvector extension)

Optional — smarter local extraction: YourMemory works out of the box with built-in heuristics. For higher-quality, fully-local fact extraction, install Ollama and yourmemory-setup pulls the model (qwen2.5:7b, ~4.7 GB) automatically. Prefer the cloud? Set YOURMEMORY_EXTRACT_BACKEND=anthropic.

Or install from a binary — no Python required

Prefer not to touch pip? Grab the standalone binary for your platform from the latest release:

Platform	Asset
macOS (Apple Silicon)	`yourmemory-macos-arm64.tar.gz`
macOS (Intel)	`yourmemory-macos-x86_64.tar.gz`
Linux (x86-64)	`yourmemory-linux-x86_64.tar.gz`
Windows (x86-64)	`yourmemory-windows-x86_64.exe.zip`

# macOS / Linux — download, extract, run
tar -xzf yourmemory-macos-arm64.tar.gz
./yourmemory-macos-arm64 register <your-token>
./yourmemory-macos-arm64 setup
./yourmemory-macos-arm64            # start the server

One executable handles every command: register, setup, ask "<question>", path, and (with no args) starts the server.

Fully self-contained & offline — the binary bundles Python, every dependency, and both ML models (the embedding model + spaCy). Nothing is downloaded on first run. The trade-off is size (~2 GB). Build your own with a single command — ./build-binary.sh — and multi-platform release binaries are produced automatically by the build workflow.

🧠 How Memory Works

YourMemory treats memory as a living system — it grows, consolidates, forgets, and connects, the way a brain does.

Consolidation — N → 1

Most memory tools just keep growing. YourMemory watches for clusters of related facts and, once enough accumulate, compresses them into a single clean summary — archiving the originals (never deleting, so nothing is lost).

flowchart LR
    subgraph before [Related facts pile up]
        A1["Railway uses Nixpacks"]
        A2["Railway on Pro plan"]
        A3["Railway env vars hold<br/>the Postgres URL"]
        A4["Deploys on Railway<br/>with Postgres"]
    end
    before --> C{"cluster +<br/>LLM summarize"}
    C --> S["✨ Summary<br/>Deploys on Railway (Pro,<br/>Nixpacks) with Postgres<br/>via env vars"]
    C -.->|"archived, recoverable"| ARC[("archive")]
    style S fill:#0a2540,stroke:#5eead4,color:#fff
    style C fill:#0c2b3a,stroke:#19cdff,color:#fff

Real example from one production store: 444 memories → 16 summaries — same knowledge, a fraction of the noise. Consolidation is event-driven (triggered when related memories pile up), not a blind nightly job.

Decay — the 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)

active_days counts only days you were active — vacations don't cause memory loss. Memories below strength 0.05 are pruned automatically. Each category ages at its own rate:

Category	Half-life	Best for
`strategy`	~38 days	Patterns that worked, architectural decisions
`fact`	~24 days	Preferences, identity, stable knowledge
`assumption`	~19 days	Inferred context, uncertain beliefs
`failure`	~11 days	Errors, wrong approaches, environment-specific issues

Chain-aware pruning: a decayed memory is kept alive if any graph neighbour is still strong — load-bearing context survives even when rarely queried directly.

Hybrid Retrieval — Vector + BM25 + Graph

Recall runs in two rounds so it surfaces both what you asked for and what you forgot to ask for:

flowchart LR
    Q["query"] --> R1["Vector + BM25<br/>hybrid search"]
    R1 --> R2["Graph expansion<br/>(what you forgot to ask)"]
    R2 --> S["rank by<br/>similarity × strength"]
    S --> OUT["🎯 Ranked memories"]
    style OUT fill:#0a2540,stroke:#19cdff,color:#fff

Subject-aware deduplication runs before every store — it embeds the subject of each sentence so "Sachit uses DuckDB" and "YourMemory uses DuckDB" stay separate (different entities), while "YourMemory uses DuckDB" and "YourMemory stores data in DuckDB" merge (same entity). No hardcoded word lists; generalises to any language.

🔒 Trust & Audit Trail

Enterprises won't let an opaque black box store their data. So every operation — read, write, update, delete, consolidation — is appended to a hash-chained, tamper-evident audit log.

flowchart LR
    E0["GENESIS"] --> E1
    subgraph E1 [Event 1]
        H1["row_hash =<br/>sha256(prev + data)"]
    end
    E1 --> E2
    subgraph E2 [Event 2]
        H2["row_hash =<br/>sha256(#1.hash + data)"]
    end
    E2 --> E3
    subgraph E3 [Event 3]
        H3["row_hash =<br/>sha256(#2.hash + data)"]
    end
    E3 --> V{"GET /audit/verify"}
    V -->|chain intact| OK["✅ verified"]
    V -->|any row altered| BAD["❌ chain breaks<br/>at that row"]
    style OK fill:#0a2540,stroke:#5eead4,color:#fff
    style BAD fill:#3a0c14,stroke:#fb7185,color:#fff

Each row records the timestamp, actor user + agent, action, operation, target memory, source (http vs mcp), and the previous row's hash. Change any historical record and verify_chain() pinpoints exactly where the chain broke.

GET  /audit            # browse the trail (filter by user / action / operation)
GET  /audit/verify     # cryptographically verify the chain is untampered
POST /audit/prune      # retention-based cleanup (90-day minimum, never lower)

Audit logging is fail-open — it never blocks a memory operation — and read/list events from the dashboard's own render loop are excluded, so the trail stays signal, not noise.

👥 Team Memory Pools

Give a whole team's agents one shared brain — without leaking anyone's private context. Memories are either shared (visible to the pool) or private (visible only to their owner).

flowchart TB
    P(("🧠 Team Pool<br/>shared memory"))
    A["Alice's agent"] <-->|shared| P
    B["Bob's agent"] <-->|shared| P
    C["Carol's agent"] <-->|shared| P
    A -. private .-> AP["🔒 Alice-only"]
    B -. private .-> BP["🔒 Bob-only"]
    style P fill:#0a2540,stroke:#19cdff,color:#fff
    style AP fill:#0c1424,stroke:#5a6b80,color:#8294a8
    style BP fill:#0c1424,stroke:#5a6b80,color:#8294a8

Role-based access is enforced per agent — what one engineer's agent learns, the whole team benefits from instantly; sensitive context stays scoped to its owner.

POST   /pools                          # create a pool
POST   /pools/{id}/members             # add a member (with role)
POST   /pools/{id}/memories            # contribute a shared memory
POST   /pools/{id}/retrieve            # recall across the pool

🛡️ Data Rights & Compliance

Because memory that stores real data needs the controls to be trusted with it:

Right	Endpoint	What it does
Access (DSAR export)	`GET /users/{id}/export`	Full export of everything stored for a user
Erasure (right to forget)	`DELETE /users/{id}/memories`	One-command purge of a user's memories
Portability	`POST /users/{id}/import`	Re-import a previous export
Recoverability	`GET /users/{id}/archive`	Retrieve consolidated-away originals

Combined with the hash-chained audit trail and 90-day retention floor, these map directly onto the controls documented in SECURITY.md (SOC 2-aligned).

🎛️ Dashboards

Two built-in browser UIs — no extra setup, they start automatically with the server.

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

A full read/write view with Memories · Audit · Pools tabs: stats bar (Strong / Fading / Near-prune), per-agent tabs, memory cards with live strength bars, category filters, the audit trail, and pool management.

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

An interactive force-directed map of how memories connect — root memory as a bright node, neighbours color-coded by category, edge thickness = connection strength. Drag, zoom, and click any node for full content.

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

🔧 MCP Tools

Three tools, called by your AI automatically.

Tool	When your AI calls it	What it does
`recall_memory(query, current_path?)`	Start of every task	Surfaces memories ranked by similarity × decay strength; spatial boost for path-matched memories
`store_memory(content, importance, category?, context_paths?)`	After learning something new	Embeds, deduplicates, stores with decay; tags optional file/dir paths
`update_memory(id, new_content, importance)`	When a stored fact is outdated	Re-embeds and replaces; logs the change to the audit trail

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

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

⚡ Ask Without an LLM Call

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

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

yourmemory ask "how do I fix a kubernetes deployment"
# → Not enough memory context to answer without an LLM.

When memory is strong enough it answers instantly — zero tokens, zero cloud cost, zero latency. When it isn't, it declines cleanly rather than hallucinating. Your query never leaves your machine.

🔀 API Proxy — Guaranteed Memory

MCP tools are called at the AI's discretion. The API proxy removes that uncertainty — it intercepts every LLM call, injects relevant memories automatically, and handles store_memory / update_memory with no model configuration.

Start the server (yourmemory), then point your client at localhost:3033:

from anthropic import Anthropic

client = Anthropic(
    api_key="sk-ant-...",
    base_url="http://localhost:3033/proxy/anthropic",
    default_headers={"X-YourMemory-User": "alex"},  # per-user memory
)

# Memory is injected automatically — no other changes needed
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "What database do I use?"}],
)

OpenAI works identically via base_url="http://localhost:3033/proxy/openai".

🏗️ Architecture & Stack

flowchart LR
    C["Your AI client<br/>Claude · Cursor · any MCP"] <--> Y["🧠 YourMemory"]
    Y --> M[("Memory<br/>store")]
    Y --> A[("Audit<br/>ledger")]
    style Y fill:#0a2540,stroke:#19cdff,color:#fff
    style M fill:#0c1a2c,stroke:#5eead4,color:#fff
    style A fill:#0c1a2c,stroke:#5eead4,color:#fff

Component	Role
DuckDB	Default vector store — zero setup, native cosine similarity
PostgreSQL + pgvector	Optional — for teams or large datasets
NetworkX	Default graph backend (`~/.yourmemory/graph.pkl`)
Neo4j	Optional graph backend
sentence-transformers	Local embeddings (`multi-qa-mpnet-base-dot-v1`, 768 dims)
spaCy	Local NLP for deduplication and entity extraction
APScheduler	Automatic decay + pruning

🩺 Troubleshooting

Writes hang / time out (DuckDB single-writer lock). If both the MCP server and the HTTP server run at once, they compete for the DuckDB write lock. Fix:

pkill -f yourmemory 2>/dev/null || true
rm -f ~/.yourmemory/memories.duckdb.wal ~/.yourmemory/memories.duckdb.lock 2>/dev/null || true
# restart your client

Running Claude Desktop (MCP) and Claude Code (hooks) simultaneously? Use SQLite instead — it handles concurrent readers/writers cleanly: DATABASE_URL=sqlite:///~/.yourmemory/memories.db

🤝 Contributing

PRs welcome — see CONTRIBUTORS.md.

📚 Dataset References

LoCoMo — Maharana et al. (2024)
LongMemEval — Wu et al. (2024)
HotpotQA — Yang et al. (2018)

📄 License

Free for personal use, education, academic research, and open-source projects. Commercial use requires a separate written agreement → 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 11 days ago (2026-08-26 06:21 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

Your AI has the memory of a goldfish. Not anymore.

The problem

✨ What makes it different

Table of Contents

🏆 Benchmarks

LoCoMo-10 — multi-session conversational memory

LongMemEval-S — 500 questions, ~53 distractor sessions each

HotpotQA — 200 multi-hop questions

🚀 Quick Start

Or install from a binary — no Python required

🧠 How Memory Works

Consolidation — N → 1

Decay — the forgetting curve

Hybrid Retrieval — Vector + BM25 + Graph

🔒 Trust & Audit Trail

👥 Team Memory Pools

🛡️ Data Rights & Compliance

🎛️ Dashboards

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

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

🔧 MCP Tools

⚡ Ask Without an LLM Call

🔀 API Proxy — Guaranteed Memory

🏗️ Architecture & Stack

🩺 Troubleshooting

🤝 Contributing

📚 Dataset References

📄 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 Dashboard — `http://localhost:3033/ui`

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