What can you do with this server?

The mcp-memory server provides intelligent, decay-based memory management for AI agents, preventing one-time questions from becoming permanent obsessions by applying exponential decay and frequency-based relevance scoring. * Store memories (remember): Save information with automatic content-based categorization (preference, fact, correction, context, one-time, question), semantic deduplication, and preference superseding. Supports optional tags and explicit category override. * Retrieve memories (recall): Fetch memories ranked by a dynamic score combining decay × frequency × match quality. Automatically reinforces the top match and prunes dead memories. Accepts query, limit, and min_relevance parameters. * Delete memories (forget): Remove a memory by id or fuzzy content match (e.g., "VS Code" matches "User prefers VS Code for all editing"). * Reinforce topics (reinforce): Boost a memory's relevance and reset its decay clock. After 5 mentions, a question automatically upgrades to interest with a longer lifespan. * Inspect memory state (inspect): Debug view of all memories showing decay status, relevance scores, ages, and category breakdown. * Prune decayed memories (prune): Explicitly remove memories below a configurable relevance threshold (also happens automatically during recall). * Memory health overview (stats): Summary of active, fading, and dead memories broken down by category. Key behaviors: Each category has its own decay half-life (e.g., 7 days for one-time, 180 days for preferences). Active memories can be injected into AI agent system prompts. Older tool names from v0.1.0 are supported for backwards compatibility.

mcp-memory

by ShipItAndPray

Overview Schema Related Servers Score Discussions

JavaScript

mcp-memory

Smart memory for AI agents. Memories decay, topics are frequency-weighted, one-time questions don't become obsessions.

Solves the Karpathy problem: "A single question from 2 months ago keeps coming up as a deep interest with undue mentions in perpetuity."

What's New in v0.2.0

Auto-categorization — no need to specify category, inferred from content
Semantic dedup — bigram similarity prevents duplicate memories
Preference supersede — "prefers dark mode" then "prefers light mode" updates, not duplicates
Recall auto-reinforces — searching for a topic counts as a mention
Recall auto-prunes — dead memories cleaned up on every read
System prompt injection — active memories provided via MCP prompts capability
Fuzzy forget — "VS Code" matches "User prefers VS Code for all editing"
7 tools → 4 tools — simpler API, higher adoption (backwards compatible)

Related MCP server: engram-mcp

In Action

Day 1: User asks 5 questions (Rust, dark mode, Python, job title, Haskell)

  #1 [ACTIVE] rel=1.000 cat=preference "User prefers dark mode in all editors"
  #2 [ACTIVE] rel=0.900 cat=fact       "User works as a senior software engineer"
  #3 [FADING] rel=0.500 cat=question   "User is building a Python web scraper"
  #4 [FADING] rel=0.300 cat=one-time   "User asked about Rust programming"
  #5 [FADING] rel=0.300 cat=one-time   "User asked what Haskell monads are"

Day 2-5: User mentions Python 4 more times → auto-upgraded to "interest"

  #1 [ACTIVE] rel=2.658 mentions=5 cat=interest    "Python web scraper"
  #2 [ACTIVE] rel=1.000 mentions=1 cat=preference  "dark mode"
  #3 [ACTIVE] rel=0.900 mentions=1 cat=fact         "senior software engineer"
  #4 [FADING] rel=0.300 mentions=1 cat=one-time     "Rust" ← FADING, won't obsess
  #5 [FADING] rel=0.300 mentions=1 cat=one-time     "Haskell" ← FADING, won't obsess

After 60 days:
  Rust:   0.3 × 0.5^(60/7) = 0.0008 → DEAD (gone, as it should be)
  Python: 0.8 × 0.5^(60/60) × 3.32 = 1.329 → STILL ACTIVE (real interest)

How It Fixes This

Current LLM Memory	mcp-memory
Ask about Rust once → mentioned forever	Ask once → fades in 7 days
All memories equal weight	Categories: one-time (7d), question (14d), interest (60d), preference (180d)
No decay	Exponential decay — old memories naturally fade
No frequency tracking	Mentioned 5+ times → auto-upgrades from "question" to "interest"
Keyword matching	Bigram similarity + relevance scoring
Agent must decide to remember	Auto-categorizes from content patterns
Contradicting preferences coexist	New preference supersedes old one
Manual cleanup required	Auto-prunes dead memories on recall

Install

"mcpServers": {
  "memory": {
    "command": "npx",
    "args": ["-y", "mcp-memory"]
  }
}

Tools

Tool	What it does
`remember`	Store a memory. Auto-categorizes from content. Auto-deduplicates via bigram similarity. Supersedes conflicting preferences.
`recall`	Retrieve memories ranked by relevance. Auto-reinforces top match. Auto-prunes dead memories.
`forget`	Delete a memory by ID or fuzzy content match.
`inspect`	Debug view: all memories with decay status, relevance scores, category breakdown, health.

Auto-Categorization

No need to specify category — it's inferred from content:

Content Pattern	Auto-Category	Decay
"prefers X", "likes X", "always uses X"	`preference`	180 days
"works as X", "is a X", "lives in X"	`fact`	365 days
"actually X", "meant X", "wrong"	`correction`	365 days
"currently building", "working on"	`context`	30 days
"what is X", "how to X"	`one-time`	7 days
anything else	`question`	14 days

You can still override: remember(content: "...", category: "preference")

Examples

Auto-categorized preference:

remember(content: "User prefers TypeScript over JavaScript")
→ Auto-detected as "preference". Persists 180 days.

Semantic dedup:

remember(content: "Works as data scientist at Google")
remember(content: "Works as senior data scientist at Google")
→ Second call reinforces first (80% similar). Keeps longer version.

Preference supersede:

remember(content: "User prefers dark mode")
remember(content: "User prefers light mode")
→ Superseded: "dark mode" → "light mode". One memory, not two.

Recall auto-reinforces:

recall(query: "MCP servers")
→ Returns matching memories AND counts this as a mention.
  mention_count goes from 1 → 2 automatically.

Fuzzy forget:

forget(content: "VS Code")
→ Matches and removes "User prefers VS Code for all editing"

The Math

relevance = base_weight × decay × frequency_boost

where:
  base_weight  = category-specific (0.3 for one-time, 1.0 for preference)
  decay        = 0.5 ^ (age_days / halflife_days)
  freq_boost   = 1 + log2(mention_count)

A one-time question from 2 months ago: 0.3 × 0.5^(60/7) × 1.0 = 0.0003 → effectively zero. Won't surface.

A preference mentioned 8 times, last week: 1.0 × 0.5^(7/180) × 4.0 = 3.89 → top of every recall.

Backwards Compatibility

v0.2.0 still accepts the old v0.1.0 tool names (reinforce, prune, stats). They map to the new tools internally. No breaking changes.

License

MIT

Available Tools

4 tools

forgetA

Delete a memory by ID or content match (fuzzy). Use when the user says to forget something.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	Memory ID (from inspect)
`content`	No	Fuzzy content match

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states action (delete) and fuzzy matching, but does not disclose permanence, confirmation behavior, error handling, or what happens on multiple fuzzy matches.

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 short sentences, no wasted words, directly conveys purpose and usage. Appropriate length for such a simple tool.

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

Completeness3/5

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

Tool is simple with 2 optional params and no output schema. Description covers core action and usage trigger but omits return behavior, error cases, or confirmation messages.

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?

Input schema has 100% description coverage for both parameters. Description adds minimal extra value ('id from inspect', 'fuzzy content match') but not enough to raise score above baseline 3.

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 'Delete a memory by ID or content match (fuzzy)', providing a specific verb and resource. It distinguishes from siblings like 'remember' (create) and 'recall' (retrieve) by focusing on deletion and fuzzy matching.

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 when the user says to forget something', which is a clear usage context. However, no guidance on when not to use or alternatives like 'update' or 'clear all'.

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

inspectA

Debug view: all memories with decay status, relevance scores, ages, and health stats. Also shows category breakdown.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Describes what it shows (all memories, various stats) and implies read-only behavior. No annotations, but no contradictions. Could mention no side effects explicitly.

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 fluff. Efficient and clear.

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?

Adequate for a simple debug tool with no parameters. Could mention limitations or what is not shown, but complete enough.

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

Parameters4/5

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

No parameters in input schema, so baseline of 4 applies. Description adds no parameter info, which is fine.

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 a debug view showing all memories with specific fields (decay status, relevance scores, ages, health stats, category breakdown), differentiating it from sibling tools like forget, recall, remember.

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?

Implied usage for debugging, but no explicit when-to-use or when-not-to-use guidance. Sibling tools provide context but description lacks direct alternatives.

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

recallA

Search memories by topic. Auto-reinforces strong matches. Auto-prunes dead memories. Leave query empty to get all active memories ranked by relevance.

ParametersJSON Schema

Name	Required	Description
`query`	No	Search query. Leave empty for all.
`limit`	No	Max results. Default: 10.
`min_relevance`	No	Min relevance 0-1. Default: 0.05.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description discloses important side effects: auto-reinforces strong matches and auto-prunes dead memories. This adds behavioral context beyond a simple search.

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 wasted words. Every sentence adds meaningful information.

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

Completeness3/5

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

No output schema and no description of return format or error cases. While side effects are noted, the output nature is vaguely described as 'get all active memories'. Incomplete for full tool understanding.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds value by explaining empty query returns all active memories ranked by relevance, which supplements schema descriptions.

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 'Search memories by topic', specifying verb and resource. Leaving query empty for all memories distinguishes from sibling tools (forget, inspect, remember).

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?

Description implies usage for searching memories and provides context for empty query, but lacks explicit when-not or alternatives. However, sibling tool names clarify scope.

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

rememberA

IMPORTANT: Call this whenever the user reveals a preference, fact about themselves, correction, or recurring interest. Auto-categorizes if no category given. Auto-deduplicates similar content. Categories: one-time (7d), question (14d), interest (60d), preference (180d), correction (365d), fact (365d), context (30d).

ParametersJSON Schema

Name	Required	Description
`content`	Yes	What to remember. Keep concise — under 20 words.
`category`	No	Optional. Auto-detected if omitted.
`tags`	No	Optional comma-separated tags.

TDQS

A4.7/5.0

Behavior4/5

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 auto-categorization, auto-deduplication, and category-specific durations. However, it does not explicitly mention side effects (e.g., whether data is overwritten) or failure modes.

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 extremely concise, with every sentence providing essential information. It is front-loaded with an imperative to use the tool, making it immediately clear.

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 the absence of annotations and output schema, the description covers purpose, usage, categories, durations, and automatic behaviors comprehensively. No critical gaps remain.

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

Parameters4/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 adds value beyond the schema by explaining category durations and auto-detection, thus enriching the meaning of the 'category' parameter.

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 tool's purpose: remembering user preferences, facts, corrections, and recurring interests. It also distinguishes itself from sibling tools (forget, inspect, recall) by being the one for storing new information.

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?

The description provides explicit guidance on when to call the tool ('whenever the user reveals a preference, fact about themselves, correction, or recurring interest') and also explains auto-categorization and auto-deduplication behavior, leaving no ambiguity.

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.

6 tool updatesv1.0.0May 3, 2026

Changedforget2 fields changed

changedInput schema / properties / content / description

Previous value: -"Content to match (partial match)"New value: +"Fuzzy content match"

changedInput schema / properties / id / description

Previous value: -"Memory ID"New value: +"Memory ID (from inspect)"

Removedprune

Changedrecall3 fields changed

changedInput schema / properties / limit / description

Previous value: -"Max results (default: 10)"New value: +"Max results. Default: 10."

changedInput schema / properties / min_relevance / description

Previous value: -"Minimum relevance score 0-1 (default: 0.05)"New value: +"Min relevance 0-1. Default: 0.05."

changedInput schema / properties / query / description

Previous value: -"What to search for. Leave empty to see all memories ranked by relevance."New value: +"Search query. Leave empty for all."

Removedreinforce

Changedremember3 fields changed

changedInput schema / properties / category / description

Previous value: -"Memory type. \"one-time\" decays in 7 days. \"preference\" lasts 6 months. Default: question (14 days)"New value: +"Optional. Auto-detected if omitted."

changedInput schema / properties / content / description

Previous value: -"What to remember"New value: +"What to remember. Keep concise — under 20 words."

changedInput schema / properties / tags / description

Previous value: -"Comma-separated tags for better recall matching"New value: +"Optional comma-separated tags."

Removedstats

7 tool updatesv0.1.0Apr 2, 2026
- First observedforget
- First observedinspect
- First observedprune
- First observedrecall
- First observedreinforce
- First observedremember
- First observedstats

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct operation on memories: forget deletes, inspect shows debug view, recall searches, and remember creates. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names are single-word lowercase verbs (forget, inspect, recall, remember), following a consistent imperative pattern.

Tool Count5/5

With 4 tools, the server covers the essential CRUD-like operations for a memory system (create, read, delete, and inspect) without being excessive or insufficient.

Completeness4/5

The tool set covers creation, search, deletion, and inspection, but lacks an explicit update tool. While auto-reinforcement and categorization handle some updates, a direct edit capability is a minor gap.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

mcp-serverOAuth
in.creo-memories
Memory system for AI agents with semantic search. Store and recall memories with ease.
Knowledge & Memory Search RAG Systems
2
agentbay-mcp AOAuth
io.github.thomasjumper
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Knowledge & Memory Autonomous Agents Agent Orchestration
21
goldhold
io.github.jerrysrodz
Persistent memory for AI agents. Search, store, and recall across sessions.
Knowledge & Memory Autonomous Agents RAG Systems
2
AI Context FlowOAuth
network.plurality
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Knowledge & Memory Search
22

Related MCP Servers

engram-rs
Knowledge & Memory Autonomous Agents RAG Systems
kael-bit
A
license
Not graded
quality
C
maintenance
Persistent memory for AI agents — organized by time and space. Important memories get promoted, noise decays naturally, and related knowledge clusters into a browsable topic tree. Fully automatic.
Updated 6 months ago (2026-03-03 05:02 UTC)
27
MIT
engram-mcp
Knowledge & Memory RAG Systems Autonomous Agents
Cartisien
A
license
A
quality
C
maintenance
Persistent semantic memory for AI agents. SQLite-backed, local-first, zero config. Semantic search via Ollama embeddings with keyword fallback. Tools: remember, recall, history, forget, stats.
Updated 5 months ago (2026-04-20 02:08 UTC)
17
37
1
MIT
NEXO Brain
Knowledge & Memory RAG Systems Autonomous Agents
wazionapps
A
license
C
quality
F
maintenance
Cognitive memory for AI agents. Implements Atkinson-Shiffrin multi-store memory (sensory → STM → LTM), semantic RAG with fastembed, Ebbinghaus forgetting curves, trust scoring, and metacognitive guard. 76+ MCP tools. 100% local, MIT licensed.
Updated 2 months ago (2026-07-03 18:20 UTC)
100
873
27
AGPL 3.0
widemem-ai
Knowledge & Memory RAG Systems AI & Machine Learning
remete618
A
license
Not graded
quality
A
maintenance
Open-source AI memory layer for LLM agents. Importance scoring, temporal decay, hierarchical memory (facts, summaries, themes), YMYL prioritization, and active retrieval with contradiction detection. Supports OpenAI, Anthropic, Ollama. Local-first with SQLite + FAISS.
Updated 21 hours ago (2026-09-05 11:12 UTC)
48
Apache 2.0

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/ShipItAndPray/mcp-memory'

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