The memory layer for AI coding tools. Local-first, developer-specific, works everywhere.
Most knowledge and memory work still happens through a UI a human drives. Amem MCP server moves it into the conversation instead. The memory layer for AI coding tools. Local-first, developer-specific, works everywhere.
Quick Start · How It Works · Benchmarks · Tools · Dashboard · Architecture
@aman_asmuei/amem on npm is all you need. Most clients run it directly, so configuration is a few lines and a restart.
The server publishes 14 tools. What each one is for:
memory_store — Store a memory with type, tags, confidence. Auto-redacts private content, auto-expires contradictionsmemory_recall — Semantic search — compact mode by default (~10x token savings). Use memory_detail for full contentmemory_detail — Retrieve full content by ID after compact recallmemory_context — Load all relevant context for a topic, organized by type with token budgetingmemory_extract — Batch-save multiple memories from conversationmemory_forget — Delete by ID or query (with confirmation)memory_inject — Surface corrections + decisions + graph neighbors before coding startsmemory_patch — Surgical field-level edit with auto-snapshotmemory_versions — View full edit history or restore any versionmemory_search — Exact full-text search via FTS5 with compact modememory_since — Temporal query with natural language ranges (7d, 2w, 1h)memory_relate — Build a typed knowledge graph between memoriesPlenty of knowledge and memory servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Amem's toolset — memory_store, memory_recall, memory_detail and 11 more — is a fair guide to whether it matches your workflow. It is maintained by amanasmuei; worth a glance at recent repository activity before you build anything load-bearing on it.
SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.
| Tool | What it does |
|---|---|
| memory_store | Store a memory with type, tags, confidence. Auto-redacts private content, auto-expires contradictions. |
| memory_recall | Semantic search — compact mode by default (~10x token savings). Use memory_detail for full content. |
| memory_detail | Retrieve full content by ID after compact recall. |
| memory_context | Load all relevant context for a topic, organized by type with token budgeting. |
| memory_extract | Batch-save multiple memories from conversation. |
| memory_forget | Delete by ID or query (with confirmation). |
| memory_inject | Surface corrections + decisions + graph neighbors before coding starts. |
| memory_patch | Surgical field-level edit with auto-snapshot. |
| memory_versions | View full edit history or restore any version. |
| memory_search | Exact full-text search via FTS5 with compact mode. |
| memory_since | Temporal query with natural language ranges (7d, 2w, 1h). |
| memory_relate | Build a typed knowledge graph between memories. |
| memory_multi_recall | Multi-strategy search with compact mode: semantic + FTS5 + graph + temporal. |
| memory_tier | Move memories between tiers: core / working / archival. |
Or add to your MCP config manually:
```json
{
"mcpServers": {
"amem": {
"command": "npx",
"args": ["-y", "@aman_asmuei/amem"]
}
}
}Configuration as documented by the project. Restart the client after saving.
A knowledge graph your assistant keeps between sessions — entities, relations and observations that persist.
Kill hallucinated APIs — version-accurate, up-to-date library documentation injected straight into context.
Your workspace, on speaking terms with AI — search, read and write Notion pages and databases.
A structured scratchpad for hard problems — stepwise reasoning with revisions, branches and visible logic.
Symbol-level code navigation, refactoring and memory for coding agents — the IDE brain your assistant has been missing.
Chat with your second brain — search, read and write vault notes through the Local REST API.