| name | Memory |
| description | Persist and retrieve information using the MCP-Memory Server. Session start/end context is handled automatically by hooks. Use tools mid-session for explicit storage and retrieval. |
Memory (MCP Memory Server)
MCP Server: mcp-memory
Automatic triggers via hooks
- Session Start: Relevant memories injected automatically based on project context
- Session End: Insights captured automatically when conversation ends
- Mid-Conversation: Pattern detection triggers memory retrieval (e.g., "what did we decide about...")
Manual Tools
When you need context the hooks didn't provide:
retrieve_memory— semantic search by contentrecall_memory— natural language time queries ("last week", "yesterday")search_by_tag— find memories by project/topic tags
Storing Memories
Use store_memory when triggers below are met:
{
"content": "One atomic fact or learning",
"metadata": {
"tags": "project-name,topic,category",
"type": "note"
}
}
Content Structure
✅ ONE fact per memory — never combine multiple facts ✅ Atomic memories — split by component/feature/concern ✅ Use descriptive tags for searchability ❌ No code blocks or documentation dumps
Good tags: foggyball-auth, scala-bloop, database-schema
Bad tags: stuff, misc, temp
Automatic Storage Triggers
Store a memory when ANY of these occur:
- User corrects me — their preferred approach/style
- Non-obvious solution found — debugging insight that took effort
- Project convention discovered — naming, structure, patterns not in docs
- User expresses preference — explicit or implied ("I prefer X")
- Custom tooling encountered — scripts, aliases, workflows unique to user
- Architectural decision made — and its rationale
- Recurring issue identified — something that keeps coming up
- Domain knowledge learned — business logic, terminology, constraints
When NOT to Store
- Ephemeral session-specific details
- Information easily found in project files
- Trivial facts that won't aid future work
- Sensitive credentials or secrets
- Standard library usage (use Context7 instead)
- One-off tasks unlikely to recur
Quality Criteria (for HIGH scores ≥0.7)
The MCP Memory Service scores memories 0.0-1.0 using AI + usage signals.
Content Quality (DeBERTa classifier - 70% weight)
| DO | DON'T |
|---|---|
| Specific, concrete details | Vague ("maybe", "todo", "look into") |
| Self-contained context | Requires external knowledge |
| Include rationale/why | Just facts without reasoning |
| Searchable keywords | Generic terms |
Example HIGH:
Python async: Use `asyncio.gather(return_exceptions=True)` for parallel API calls.
Prevents one timeout from cancelling siblings. Learned debugging webhook handler.
Example LOW:
async stuff - gather does something with exceptions?
Usage Signals (30% weight)
- Access frequency (40%) — Store things you'll search for
- Recency (30%) — Active knowledge beats stale
- Search ranking (30%) — Use specific, findable terms
Network Bonuses
| Tag | Retention Multiplier |
|---|---|
critical |
2.0× |
important |
1.5× |
reference |
1.3× |
Memories with ≥5 connections to others get +20% quality boost.
Quality Checklist
Before storing, verify:
- One atomic fact (not multiple combined)
- Includes context/rationale
- Contains searchable keywords
- Tagged with project + topic
- Would be useful if retrieved in 6 months