Amneshia
Amneshia is a local-first, deterministic knowledge-graph memory engine exposing 4 MCP tools that let an AI agent persist, search, invalidate, and traverse facts without any external LLM calls.
remember— Store one or more factual observations under an entity (auto-creates it if missing), tag them with an authority tier (invariant/architectural/contextual/ephemeral), declare logical dependencies viaderived_from, and get contradiction warnings when incoming facts oppose existing ones.recall— Keyword/concept search over stored facts and entities using SQLite FTS5 BM25, with a stricttoken_budgetto avoid context overflow, optionaldomainfilter, and optional graph expansion (depth0–3) for multi-hop retrieval.forget— Invalidate or permanently delete an entity or specific observation UUID; supports soft invalidation (preserves audit trail) or hard deletion, and cascades invalidation to dependent derived facts by default.context— GraphRAG relational traversal from seed entities outward up to 4 hops, returning a formatted Markdown document of entities, attributes, active observations, and relation links for holistic architectural understanding.Deterministic, offline operation — All operations run locally against embedded SQLite (sub-millisecond, zero token burn, no Docker/Neo4j/cloud keys required), with results dual-written to human-readable, Git-versionable Markdown.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@AmneshiaRemember that I prefer dark mode"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Technical Summary
Amneshia is a local-first memory engine for AI coding agents (Claude Desktop, Cursor, Antigravity, Windsurf) implementing the Model Context Protocol (MCP).
It replaces probabilistic, vector-only memory systems with a deterministic Truth Maintenance System (TMS) backed by embedded SQLite FTS5 and human-readable Markdown files.
Zero LLM Calls inside the Engine: Retrieval, conflict detection, decay calculation, and deduplication execute locally in
< 1msvia SQLite FTS5 and rule-based token analysis. Zero external tokens consumed.Markdown-as-Truth (
.amneshia/knowledge/): All entities and observations mirror directly to version-controlled Markdown files with YAML frontmatter. Auditable viagit diffand reviewable in Pull Requests.Truth Maintenance & Cascading Invalidation: Derived facts track their premises via directed acyclic graphs (
derived_from: [parent_id]). When a premise is revoked or updated, dependent conclusions automatically transition fromactivetostale.Pre-Insertion Contradiction Detection: Evaluates incoming facts against active entity records for polar opposition and explicit replacements, rejecting or logging conflicts before graph corruption occurs.
Self-Hostable Git-Native Cloud Sync & Smart Merge Driver: Decentralized cross-device memory synchronization using Git remotes with automatic SQLite FTS5 reindexing and a smart 3-way semantic Git merge driver that eliminates
<<<<<<< HEADconflict markers across PC and mobile.Local ONNX Hybrid Semantic Search: True hybrid search combining SQLite FTS5 BM25 lexical ranking and dense vector cosine similarity via Reciprocal Rank Fusion (RRF, $k=60$). Uses quantized
all-MiniLM-L6-v2(384 dimensions) with 100% local inference, zero external API dependencies, and dual-mode execution (native C++ AVX/GPU on PC, WebAssembly SIMD on Termux).Universal Memory Export: Export full or filtered knowledge graphs into standalone SQLite databases (
.db), Markdown bundle directories with catalog indexes, or structured JSON.Local-Memory Project Adoption: Seamlessly adopt, migrate, or cherry-pick accumulated global memories (
~/.amneshia) into workspace projects (.amneshia) with deduplication and contradiction checks.Lean Context Budget (85% Reduction): Default 4-tool surface (
remember,recall,forget,context) reduces prompt schema consumption from ~5,400 tokens to ~800 tokens.
Related MCP server: Graph-Memory
⚡ Quickstart & IDE Setup
Installation Options
Option A: Universal One-Liner (Recommended)
curl -fsSL https://raw.githubusercontent.com/SabilMurti/Amneshia/main/install.sh | bashOption B: GitHub Releases (Direct Tarball — Zero Login Required)
npm install -g https://github.com/SabilMurti/Amneshia/releases/latest/download/amneshia-latest.tgzOption C: JSR (TypeScript / Deno / Bun / Node)
# Add to project via JSR
npx jsr add @sabilmurti/amneshia
# or with Bun
bunx jsr add @sabilmurti/amneshiaOption D: GitHub Packages (npm.pkg.github.com)
# Add scope registry config to ~/.npmrc (once):
# @sabilmurti:registry=https://npm.pkg.github.com
npm install -g @sabilmurti/amneshiaOption E: Build from Source
git clone https://github.com/SabilMurti/Amneshia.git
cd Amneshia
npm install
npm run build && npm install -g .Keeping Amneshia Updated
Once installed, upgrade Amneshia in-place anytime with a single command:
amneshia update # Perform seamless in-place upgrade
amneshia update --check # Check for updates without installingMCP Client Configurations
Add Amneshia to your favorite MCP host configuration:
Claude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"amneshia": {
"command": "amneshia",
"args": ["--tool-profile", "core"]
}
}
}Cursor (.cursor/mcp.json)
{
"mcpServers": {
"amneshia": {
"command": "amneshia",
"args": ["--tool-profile", "core", "-l"]
}
}
}(Passing -l or --local scopes memory to .amneshia/ within the active working directory).
Google Antigravity IDE (mcp_config.json)
{
"mcpServers": {
"amneshia": {
"command": "amneshia",
"args": ["--tool-profile", "core"]
}
}
}Windsurf (mcp_config.json)
{
"mcpServers": {
"amneshia": {
"command": "amneshia",
"args": ["--tool-profile", "core", "-l"]
}
}
}VS Code (Roo Code / Cline / Continue)
{
"mcpServers": {
"amneshia": {
"command": "amneshia",
"args": ["--tool-profile", "core"]
}
}
}30-Second Verification
# 1. Initialize local repository knowledge graph
amneshia init
# 2. View knowledge graph statistics
amneshia stats
# 3. Launch interactive 3D Web Dashboard (runs on http://localhost:3457)
amneshia serve📑 Table of Contents
The Problem with Existing Agent Memory
Modern agent memory implementations fall into three flawed paradigms:
1. The "LLM-in-LLM" Antipattern
Systems like Mem0 or Zep invoke an external LLM inside the memory engine to summarize, deduce, or reconcile facts.
Latency Penalty: Every memory query triggers an HTTP request to an inference endpoint, taking 2,000–5,000ms.
Stochastic Mutation: Re-summarizing facts through a probabilistic model introduces hallucination risk and strips away exact technical specifications (e.g. port numbers, compiler flags, exact variable names).
Fragile Setup: Demands API keys, cloud credits, or local Ollama servers running in the background.
2. State Invalidation Failure in Vector Databases
Vector similarity search computes cosine distances between text embeddings. It has no concept of state transition over time ($A \to \neg A$).
If an agent stores
"Database is PostgreSQL"on Monday, and"Switched database to SQLite"on Wednesday, a vector query for"database setup"returns both embeddings with near-identical similarity scores ($0.88$ vs $0.86$).The calling model receives contradictory facts in its context window and hallucinates mixed architectures.
3. Opaque Storage Lock-in
Storing memory in proprietary cloud databases or binary embeddings makes it impossible for engineering teams to inspect, debug, or edit what an AI agent has remembered about a codebase.
Architectural Comparison: MCP Memory Ecosystem
Capability | Amneshia v3 | Official |
|
|
|
|
Zero External Infrastructure | Yes (Embedded SQLite) | Yes (Flat JSON file) | Yes | ❌ (Requires Docker PostgreSQL) | ❌ (Requires Neo4j Server) | ❌ (Requires Cloud API Key) |
Engine Token Burn | 0 tokens ($0.00) | 0 tokens | 0 tokens | 0 tokens | 0 tokens | ❌ (Consumes cloud tokens) |
Query Latency | < 1ms (SQLite FTS5) | Linear file scan | Relational scan | 50–120ms (HNSW index) | 20–60ms (Cypher query) | 1,500–3,500ms (HTTP round-trip) |
Markdown-as-Truth (Git) | Yes ( | ❌ (Single | ❌ (No file truth) | ❌ (PostgreSQL binary tables) | ❌ (Neo4j binary graph) | ❌ (Proprietary cloud storage) |
Truth Maintenance (TMS) | Yes (Authority Tiers) | ❌ (None) | ❌ (None) | ❌ (None) | ❌ (None) | ❌ (None) |
Cascading Invalidation | Yes (Recursive DAG) | ❌ (None) | ❌ (None) | ❌ (None) | ❌ (None) | ❌ (None) |
Contradiction Detection | Yes (Pre-insertion scan) | ❌ (None) | ❌ (None) | ❌ (None) | ❌ (None) | ❌ (None) |
Relational Traversal | Yes (GraphRAG Multi-Hop) | ⚠️ (Basic string graph) | ❌ (Tool call history) | ❌ (Flat vector only) | Yes (Cypher traversal) | ⚠️ (Basic entity linking) |
Token Budgeting | Yes (Enforced byte limits) | ❌ (Dumps raw nodes) | ⚠️ | ❌ (Top-K raw dump) | ❌ (Uncapped subgraphs) | ⚠️ |
Interactive Dashboard | Yes (Three.js on port 3457) | ❌ (No UI) | ❌ (No UI) | ❌ (No UI) | ⚠️ (Neo4j Desktop browser) | Yes (Cloud-hosted UI) |
Core Systems Deep Dive
1. Truth Maintenance System (TMS)
Authority Tiers
Every observation is tagged with an authority level that dictates its lifecycle and eviction priority:
Tier | Weight | Inactivity Threshold | Eviction Behavior | Intended Usage |
|
| ∞ | Never decays | User hard requirements, security rules, immutable architecture constraints. |
|
| 365 days | Transitions to | Framework choices, database schemas, structural API contracts. |
|
| 90 days | Transitions to | Current working conventions, active versions, environment configs. |
|
| 7 days / TTL | Hard purged on GC | Scratchpad notes, temporary debug logs, short-lived task state. |
Mathematical Decay Scoring
Decay evaluation runs deterministically during maintenance or GC passes:
$$\text{DecayScore} = w_{\text{tier}} \times \left(1 + \log_{10}(\text{accessCount} + 1)\right) \times \max\left(0, 1 - \frac{\text{daysInactive}}{\text{maxDays}}\right)$$
Observations where $\text{DecayScore} < 0.1$ are transitioned from active to decayed, excluding them from active search queries while preserving audit lineage.
Cascading Invalidation DAG
When an agent registers an observation that relies on previous facts, it declares derived_from: ["<uuid>"].
If a root observation is marked
supersededorinvalidated:The engine identifies all direct and transitive children via breadth-first search across the dependency graph.
All descendants transition status:
active→stale.Stale observations are filtered out from default
recallqueries, preventing downstream reasoning errors.
Pre-Insertion Contradiction Detection
Incoming facts pass through a zero-latency semantic filter prior to database insertion:
Tokenization: Text is normalized, lowercased, stripped of punctuation, and tokenized into distinct lexemes.
Polarity Check: Scanned against explicit negation patterns (
not,never,no longer,instead of,deprecated,removed,disabled).Opposition Evaluation: If token overlap between an incoming fact and an active fact on the same entity exceeds ≥ 50%, and one statement contains negation while the other does not, a contradiction event is recorded in
contradiction_logand returned as a warning payload to the calling agent.
2. Dual-Write Storage: Markdown-as-Truth
Amneshia operates a dual-write architecture:
Write Path: Graph mutations write simultaneously to SQLite and serialize to human-readable Markdown files located in
.amneshia/knowledge/{domain}/{entity}.md.Recovery Path: If the SQLite cache is deleted or desynced,
amneshia reindexreconstructs the entire FTS5 database directly from the Markdown directory in < 200ms.
Sample Entity File (.amneshia/knowledge/backend/database.md):
---
id: "8f7e2a1b-3c4d-4e5f-9a0b-1c2d3e4f5a6b"
name: "Production Database"
type: "infrastructure"
domain: "backend"
visibility: "public"
created: "2026-09-28T10:00:00.000Z"
updated: "2026-09-28T18:30:00.000Z"
---
## Observations
- **[invariant]** Primary database is PostgreSQL 16 hosted on AWS RDS
`id: obs-001 | confidence: 1.0 | status: active`
- **[architectural]** Connection pooling configured via PgBouncer with pool_size = 25
`id: obs-002 | confidence: 0.9 | derived_from: [obs-001] | status: active`
- ~~**[contextual]** SQLite used for local prototype development~~
`id: obs-003 | confidence: 0.5 | status: superseded | superseded_by: obs-001`
## Relations
- `depends_on` -> AWS VPC Security Group
- `monitored_by` -> Datadog Agent3. Deterministic Media Memory Engine (CAS Storage)
Amneshia v3.2.0 features an immutable Content-Addressable Storage (CAS) subsystem for multimodal artifacts (screenshots, architectural diagrams, audio notes, camera captures) associated directly with entities in the knowledge graph:
Streaming Cryptographic Hashing: Calculates streaming
SHA-256digests, avoiding memory bloat even on large media.Two-Level Sharded Storage: Media blobs are stored in
.amneshia/media/<sha256[:2]>/<sha256[2:]>.<ext>to prevent filesystem directory scaling bottlenecks.Zero-Token Binary Deduplication: Storing identical media across multiple entities or sessions reuses existing blobs instantly ($O(1)$) with zero duplicate disk consumption.
Orphan Garbage Collection: Unreferenced media files are automatically detected and safely reclaimed with
amneshia media prune.Zero Dependencies: Pure Node.js streams and deterministic MIME extension lookup table without external npm dependencies.
# Ingest local media and attach facts into Amneshia CAS
amneshia media remember ./architecture.png -e "Architecture Diagram" -f "Microservices visual topology"
# List stored media assets with SHA-256 digests and file sizes
amneshia media list
# Purge unreferenced orphan media blobs
amneshia media prune4. Local ONNX Hybrid Semantic Search
Combines deterministic SQLite FTS5 BM25 lexical ranking and dense vector cosine similarity via Reciprocal Rank Fusion (RRF, $k=60$):
100% Local Inference: Uses quantized
all-MiniLM-L6-v2(384 dimensions) with zero external API calls or cloud token costs.PC-First Acceleration with Mobile Fallback: Leverages native C++
onnxruntime-nodewith AVX2/AVX-512/GPU execution on PC workstations, and pure WebAssembly SIMD (onnxruntime-web) on Android Termux userspace.Precomputed Vector Index: Fast cosine similarity dot products calculated directly inside SQLite.
# Precompute vector embeddings for all active observations
amneshia embed
# Hybrid semantic search with RRF scoring
amneshia search "token expiration and refresh logic"5. Git-Native Cloud Sync & Smart Merge Driver
Amneshia synchronizes seamlessly across developer workstations (PC, laptop) and mobile terminals (Android Termux) backed by private Git repositories:
Smart 3-Way Git Merge Driver (
amneshia cloud setup-driver): Eliminates standard Git merge conflict markers (<<<<<<< HEAD) in Markdown knowledge files. Semantically merges YAML frontmatter, deduplicates observation UUIDs and contents, preserves highest authority tiers, and unions directional relations mathematically.Bidirectional Cloud Sync:
amneshia cloud syncpulls upstream changes, rebuilds SQLite FTS5 index automatically, and pushes local additions in a single command.
# Activate merge driver globally in ~/.gitconfig (PC / Workstation)
amneshia cloud setup-driver --global
# Synchronize across devices in one command
amneshia cloud sync6. In-Place Self-Updater (amneshia update)
Keeps your Amneshia installation up to date with zero manual steps:
Registry Failover: Queries GitHub Releases API first, with automatic fallback to JSR (
jsr.io).Environment Detection: Automatically detects Git clones (
git pull --rebase && npm install && npm run build) vs global package managers (npm/pnpm/buninstalling release tarballs).SemVer Delta Engine: Checks if the host installation is up to date (
--check), and allows forced re-installation (--force).
# Check if a new release is available
amneshia update --check
# Upgrade Amneshia in-place to latest release
amneshia update7. Tool Surface & JSON-RPC Schemas
When initialized with --tool-profile core (default), Amneshia exposes 8 high-level MCP tools:
MCP Toolset (Core Profile)
├── remember : Entity upsert, observation recording, contradiction checks
├── remember_media : Ingest local image/audio/document into CAS storage and link to entity
├── recall : Hybrid BM25 + dense vector semantic search with token budgeting
├── forget : Soft/hard invalidation with dependency cascade
├── context : GraphRAG multi-hop relational traversal
├── status : Inspect graph summary stats, node health, and cloud sync state
├── reindex : Rebuild SQLite FTS5 index from Markdown-as-Truth files
└── sync : Bidirectional Git cloud synchronization (pull / push / sync)remember
{
"name": "remember",
"arguments": {
"entity": "Authentication",
"facts": ["JWT access tokens expire after 15 minutes", "Refresh tokens stored in HTTP-only cookies"],
"tier": "architectural",
"derived_from": ["obs-001"]
}
}remember_media
{
"name": "remember_media",
"arguments": {
"file_path": "/path/to/architecture-diagram.png",
"entity": "Authentication",
"facts": ["Architecture visual spec showing JWT authentication flow"],
"domain": "architecture",
"tier": "contextual"
}
}recall
{
"name": "recall",
"arguments": {
"query": "JWT expiration window",
"token_budget": 1000,
"depth": 1
}
}forget
{
"name": "forget",
"arguments": {
"target": "obs-002",
"hard": false,
"cascade": true
}
}context
{
"name": "context",
"arguments": {
"query": "Authentication",
"depth": 2,
"limit": 5
}
}status
{
"name": "status",
"arguments": {}
}Returns total entity counts, breakdown of active/stale observations by authority tier, open contradictions, and Git remote sync state.
reindex
{
"name": "reindex",
"arguments": {}
}Reconstructs SQLite cache and FTS5 search index from Markdown-as-Truth files during disaster recovery or after manual external edits.
sync
{
"name": "sync",
"arguments": {
"action": "sync",
"message": "sync: update memory from agent session"
}
}Executes native Git cloud synchronization without needing terminal shell access (action: "sync" | "pull" | "push" | "status").
(For low-level entity and relation CRUD operations, specify --tool-profile full during server launch).
3D Web Dashboard (Port 3457)
Amneshia ships with a zero-dependency web dashboard built with React 18, Vite, and Three.js ForceGraph, pre-compiled into dist-ui/:
🌌 3D Neural Universe View
Force-directed spatial graph layout of all entities and typed edges, color-coded by architectural domain with real-time neural physics controls (repulsion force, synapse distance, and domain filtering).
🔍 Memory Inspector & Truth Maintenance View
Granular observation inspector filterable by Authority Tier (invariant, architectural, contextual, ephemeral) and DAG status (active, stale, invalidated, superseded). Supports observation auditing, access counter inspection, conflict resolution, and one-click Markdown sync.
Launching the Dashboard
# Launch server with dashboard on port 3457
amneshia serve --port 3457
# Open in browser: http://localhost:3457Agent System Rules & Prompt Presets
To ensure your coding agents (Cursor, Claude Code, Windsurf, Antigravity) actively read, persist, and maintain project memory throughout their lifecycle without human prompting, add this preset rule block to your project configuration (e.g. .cursor/rules/amneshia.mdc, .cursorrules, CLAUDE.md, .windsurfrules, or AGENTS.md):
# Long-Term Memory Directives (Amneshia v3 Engine)
You are connected to **Amneshia** (`amneshia`), an enterprise-grade SQLite FTS5 long-term memory engine with a deterministic Truth Maintenance DAG and Git-native cloud synchronization. You MUST adhere to the following memory lifecycle for every coding task:
## 1. Pre-Flight Engine Update & Retrieval (Start of Every Session)
- **Check for Amneshia Updates:** At the start of a new conversation or if it has been a while since your last chat, always verify if the Amneshia engine needs an update (e.g., via `npm update -g @sabilmurti/amneshia` or `git pull` & `npm run build` if running from source) so you don't write code against an outdated memory engine from another device.
- **Mandatory Recall:** Before writing code, planning refactors, or suggesting libraries, ALWAYS query Amneshia:
`recall({ query: "<topic/keyword>", token_budget: 1000 })` or inspect project context via `context({ domain: "<domain>" })`.
- **Hybrid Semantic Search:** Amneshia v3.1 leverages Reciprocal Rank Fusion (RRF) combining SQLite FTS5 BM25 lexical ranking with dense vector cosine similarity (via local ONNX `all-MiniLM-L6-v2`). You can query abstract concepts, symptoms, or architectural behaviors without needing exact keyword matches.
- **Never Guess Conventions:** Verify past architectural decisions, repository quirks, coding styles, and active credentials before scaffolding.
## 2. In-Flight Execution & Authority Tiers
- **Authority Levels:** Amneshia v3 enforces 4 strict authority tiers:
- `invariant`: Immutable truths, user constraints, security rules, and permanent architectural decisions (never decays).
- `architectural`: Framework choices, core database schemas, and API contracts (365 days retention).
- `contextual`: Working conventions, active configurations, and environment state (90 days retention, default for agent observations).
- `ephemeral`: Scratchpad notes, temporary debug logs, and short-lived session context (7 days TTL).
- **No Overwriting Invariants:** As an agent, your writes default to `contextual` authority. Never try to supersede or contradict user-defined invariant decisions without explicit user consent.
- **Contradiction Alerts:** If `remember` returns a contradiction alert (e.g. conflicting framework version or competing state library), halt and clarify with the user.
## 3. Post-Flight Persistence (End of Every Completed Task — Exhaustive & Detailed)
- **Proactive Auto-Memory:** Upon successfully completing a task, implementing a feature, or fixing a bug, you MUST proactively call `remember()` to persist a comprehensive debrief.
- **Strict Anti-Shallow Rule:** NEVER output lazy, one-line summaries (e.g. bans like *"Fixed bug in UI"* or *"Updated config"*).
- **Mandatory Debrief Structure:** Every stored observation must provide exhaustive technical density:
1. **Context & Rationale:** Problem statement, user intent, and why the solution was designed this way.
2. **Technical Implementation:** Concrete file paths modified, core components/classes built, algorithms chosen, and schema migrations applied.
3. **Operational Parameters:** Ports, endpoints, CLI parameters, and environment variable requirements.
4. **Verification & Test Outcomes:** Exact test suites run, number of passing assertions, and edge cases handled.
5. **Architectural Guardrails:** Traps, caveats, and conventions that future agents must follow to avoid regressions.
- **Example Call:**
```json
{
"name": "remember",
"arguments": {
"entity": "Web Dashboard Architecture",
"facts": [
"[Context & Rationale] Dashboard port changed to 3457 to prevent conflicts with Vite default 5173.",
"[Technical Implementation] Modified src/server.ts and src/index.ts to pass stdio: false on serve subcommand.",
"[Operational Parameters] Web Dashboard runs on http://localhost:3457. CLI: amneshia serve -p 3457.",
"[Verification & Test Outcomes] Verified with curl /api/stats (200 OK) and 60/60 vitest assertions passing.",
"[Architectural Guardrails & Gotchas] Stdio mode must be false when spawning daemon to avoid terminal SIGTTOU suspension."
],
"tier": "architectural",
"domain": "project:amneshia"
}
}
```
## 4. Soft Invalidation Over Deletion
- **Never Leave Stale Memory:** If a prior decision, dependency, or file path is deprecated or replaced, call `forget`:
`forget({ target: "<observation-id>", hard: false, cascade: true })`
- Amneshia automatically marks the node as `stale`/`invalidated` in the DAG while preserving audit lineage.
## 5. Dual-Write Transparency & Cloud Sync
- All stored memories are dual-written to `.amneshia/knowledge/{domain}/{entity}.md`. You may inspect or commit these files directly with git.
- **Pre-Flight Cloud Sync (Cross-Device):** At the start of a new conversation or if it has been a while since your last interaction, ALWAYS ensure memory is up-to-date with other devices. You can invoke the native MCP tool `sync({ action: "sync" })` (or terminal CLI `amneshia cloud sync`).
- **Memory Health Inspection:** Call `status({})` to verify node counts, authority tier distribution, active contradictions, and cloud Git remote status.
## 6. Smart 3-Way Git Merge Driver (Zero Conflict Markers)
- **Multi-Device Synchronization:** When synchronizing memory across machines (e.g. Workstation PC $\leftrightarrow$ Laptop $\leftrightarrow$ Mobile Termux), activate the custom merge driver:
`amneshia cloud setup-driver` (or `amneshia cloud setup-driver -g` globally on PC).
- **Deterministic Reconciliation:** Never manually resolve raw merge conflicts (`<<<<<<< HEAD`) in `.amneshia/knowledge/*.md`. The driver semantically reconciles YAML frontmatter, deduplicates observation UUIDs and contents, preserves highest authority tiers, and unions directional relations mathematically.
## 7. Vector Index Maintenance
- **Local ONNX Ingestion:** After large Markdown imports or initial repository adoption, ensure 100% semantic coverage by executing:
`amneshia embed`
- Memory embeddings run 100% offline via local ONNX with sub-millisecond SQLite BLOB lookups.
## 8. Content-Addressable Media Memory (CAS)
- **Media Ingestion:** If a task involves generating, receiving, or analyzing media (images, diagrams, binary files), ALWAYS ingest the file into Amneshia's CAS storage via `amneshia media remember <filepath> -e "<entity>"`.
- **Immutable Storage:** Media assets are deduplicated by SHA-256 and linked directly to entity facts. Never attempt to store raw base64 strings or absolute local paths inside standard text observations.
## 9. Disaster Recovery & SQLite Reindexing (`reindex`)
- **When to Reindex:** Invoke the MCP tool `reindex({})` (or CLI `amneshia reindex`) when:
1. Knowledge markdown files have been manually edited, created, or deleted outside the active session.
2. A Git pull/merge brought in external markdown updates without automatic index rebuilding.
3. FTS5 full-text search indexes or SQLite cache become corrupted or desynchronized from Markdown-as-Truth files.
- **Strict Guardrail:** NEVER call `reindex()` repeatedly on routine conversation turns. Amneshia handles real-time dual-write updates automatically; reserve `reindex()` strictly for initial imports, post-git pulls, or disaster recovery.CLI Reference
# Scaffold .amneshia/ directory and .gitignore in current workspace
amneshia init
# Scaffold local repo and automatically adopt memories from global ~/.amneshia
amneshia init -d backend # Adopt specific domain
amneshia init -a # Adopt all global memories
# Adopt / cherry-pick global memories into current project with deduplication
amneshia adopt -d project:core # Filter by domain
amneshia adopt -e "Auth Module" # Filter by specific entities
amneshia adopt --dry-run # Preview migration without modifying target
amneshia adopt --move # Move memories (delete from source after copying)
# Universal Memory Export (SQLite, Markdown bundle, or JSON)
amneshia export memory.db -f sqlite # Full standalone SQLite database
amneshia export ./md-export -f markdown # Markdown directory with index.md catalog
amneshia export memory.json -f json -d backend # JSON dump filtered by domain
amneshia export dump.json -f json -t invariant # Filter by authority tier
amneshia export search.json -f json -q "jwt token" # Filter by FTS5 BM25 search query
# Git-Native Cloud Synchronization (Self-Hostable across all devices)
amneshia cloud setup git@github.com:user/my-memory.git # Link private Git repository
amneshia cloud status # Inspect sync health & uncommitted facts
amneshia cloud pull # Pull remote updates & reindex SQLite FTS5
amneshia cloud push -m "Synced memory" # Commit & push local knowledge
# Smart 3-Way Git Merge Driver (Zero conflict markers across PC and mobile)
amneshia cloud setup-driver # Activate driver in knowledge repo (.gitattributes)
amneshia cloud setup-driver --global # Activate driver globally in ~/.gitconfig (PC / Workstation)
# Local ONNX Hybrid Semantic Search (FTS5 BM25 + Vector Cosine Similarity via RRF)
amneshia embed # Precompute vector embeddings for active observations
amneshia embed --force # Recompute all vector embeddings from scratch
amneshia search "Android memory limits" # Hybrid semantic search with Reciprocal Rank Fusion
# Deterministic Media Memory Engine (Content-Addressable Storage / CAS)
amneshia media list # Inspect stored media assets across the graph
amneshia media remember ./diagram.png -e "Architecture" -f "System design spec" # Ingest media into CAS
amneshia media prune # Purge unreferenced orphan media blobs
# Self-Updater (Automated in-place upgrade from GitHub Releases / JSR)
amneshia update --check # Check for updates without installing
amneshia update # Perform seamless in-place upgrade
amneshia update --force # Force re-installation / rebuild
# Rebuild SQLite FTS5 database from .amneshia/knowledge/ Markdown files
amneshia reindex
# Display memory storage statistics and authority tier breakdown
amneshia stats
# Purge expired and decayed observations
amneshia gc
# Run Web Dashboard server on port 3457
amneshia serve -p 3457
# Launch as a background daemon process
amneshia --backgroundArchitecture: PC-First with Seamless Mobile/Termux Fallback
Amneshia is engineered PC-first for workstation environments (Linux, macOS, Windows) while guaranteeing 100% functionality in constrained environments like Android Termux:
Component | PC / Workstation Environment | Android Termux Userspace |
Inference Engine |
|
|
Embedding Concurrency | Multi-core parallel chunking ( | Sequential chunking ( |
Git Merge Driver | Global | Repository-scoped |
FTS5 + Vector DB | SQLite WAL mode ( | SQLite WAL mode (Bionic libc compliant) |
Dependencies | Zero native compilation required for portable setup | Zero glibc requirement (pure WebAssembly + TS) |
Verified Test Suite
$ npm test
✓ tests/database.test.ts (8 tests)
✓ tests/export.test.ts (7 tests)
✓ tests/consolidation.test.ts (5 tests)
✓ tests/adopt.test.ts (6 tests)
✓ tests/api.test.ts (3 tests)
✓ tests/graph.test.ts (2 tests)
✓ tests/storage.test.ts (5 tests)
✓ tests/cloud.test.ts (4 tests)
✓ tests/tools.test.ts (4 tests)
✓ tests/cli.test.ts (5 tests)
Test Files 10 passed (10)
Tests 49 passed (49)
Duration 2.34sDesign Non-Goals & Architectural Boundaries
To maintain sub-millisecond execution and total determinism, Amneshia explicitly rejects:
Embedding Ingestion of Large Arbitrary Blobs: Amneshia is an agent knowledge graph and decision store, not an unstructured PDF semantic search engine. Use dedicated vector databases (e.g. Qdrant) for raw document embeddings.
Distributed Multi-Writer Consensus: Designed as a local-first single-writer engine. Team collaboration is handled natively through Git pull requests on
.amneshia/knowledge/Markdown files.Probabilistic LLM Processing in the Core Engine: Conflict resolution and decay scoring are strictly mathematical and rule-based. The calling agent is the reasoning layer; the memory engine is the ground truth.
Contributing & Community
Amneshia is open source under the MIT License. Contributions, bug reports, and architectural RFCs are welcome.
📖 Contributor Guidelines: See CONTRIBUTING.md for local environment setup, architecture standards, and PR workflows.
💬 GitHub Discussions: Ask questions, share workflows, and discuss features in GitHub Discussions.
🐛 Issue Tracker: Submit bug reports and feature proposals via GitHub Issues.
License
MIT © Sabil Murti
Available Tools
5 toolscontextA
Traverse the knowledge graph starting from query seed entities outward up to N hops using GraphRAG relational discovery.
WHEN TO USE:
Use "context" when you need holistic, multi-hop relational knowledge around an entity (e.g. architecture, connections, dependencies).
DO NOT use for simple keyword search or strict token-budget lookups — use "recall" instead.
RETURNS:
Formatted relational Markdown document detailing seed entities, their attributes, active observations, and outward relation links.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Traversal depth (default: 1) | |
| limit | No | Maximum seed entities (default: 5) | |
| query | Yes | Search query for starting seeds | |
| domain | No | Optional domain filter |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It helpfully discloses the return format (relational Markdown with seeds, attributes, observations, links) and the hop-based traversal model, but says nothing about cost/performance of deep traversal, rate limits, or how an empty/partial match is handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded one-line purpose followed by labeled WHEN TO USE and RETURNS sections; every sentence carries routing or payload information with no filler beyond minor wording repetition ('relational' twice).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description supplies the return shape and traversal semantics, which is most of what an agent needs. It omits the 'domain' filter's effect and any note on how depth interacts with result volume.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters (query, depth, limit, domain) are already documented in the schema with defaults and bounds. The description only maps 'N hops' to depth and 'seed entities' to limit, adding marginal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Traverse the knowledge graph') plus the mechanism ('GraphRAG relational discovery') and scope ('outward up to N hops'). An agent can distinguish it from the sibling 'recall' without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE section names the qualifying scenario (holistic multi-hop relational knowledge) and a DO NOT case with a named alternative ('use recall instead' for keyword search or token-budget lookups). This is exactly the routing guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetA
Invalidate or permanently remove an entity or a specific observation UUID. Supports soft invalidation, hard permanent deletion, and automatic cascading invalidation of dependent facts.
WHEN TO USE:
Use "forget" when a fact is superseded, contradicted, or deprecated.
Prefers soft invalidation (hard=false) to preserve audit trails. Use hard=true only when permanently expunging sensitive data.
DO NOT use to update a fact with new info — use "remember" with updated content.
PERMISSIONS & FAILURE BEHAVIOR:
Operates locally on SQLite storage. Returns an error if the target entity name or UUID is not found in the database.
Returns JSON containing { ok: true, type, targetId/entity, mode, cascadedStaleCount }.
| Name | Required | Description | Default |
|---|---|---|---|
| hard | No | true = permanent delete from database; false = mark invalidated (default) | |
| target | Yes | Entity name OR observation UUID to forget | |
| cascade | No | true = also invalidate facts derived from this target (default: true) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses local SQLite storage, the error returned when the target is not found, the irreversibility implied by hard=true permanent expunging, cascade semantics, and even the response shape (ok/type/targetId/mode/cascadedStaleCount). This covers safety, failure, and side-effect behavior an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded one-line purpose followed by labeled sections for usage and failure behavior; every sentence carries actionable content with no filler. The structure lets an agent scan the trigger, the mode trade-off, and the exclusion quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter mutation tool with no annotations and no output schema, the description supplies everything missing: when to use, when not to, preference between modes, error behavior, cascade behavior, and a description of the return payload. No relevant gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds genuine meaning by explaining the soft (audit-preserving) vs hard (permanent expunge) mode distinction for 'hard' and the dependent-fact invalidation for 'cascade'. It stops short of detailing the 'target' string format beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the exact operation (invalidate or permanently remove) and the two target types (entity or observation UUID), plus the cascading behavior. It clearly differentiates from siblings by naming remember as the tool for updating facts, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE section: forget when a fact is superseded/contradicted/deprecated, prefers soft invalidation (hard=false), hard=true only for sensitive data, and an explicit DO NOT clause pointing to the remember alternative. Both the positive trigger and the exclusion are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallA
Search memory observations and facts matching keywords or concepts using SQLite FTS5 BM25. Enforces a strict token budget to prevent context window overflow.
WHEN TO USE:
Use "recall" for focused keyword search, retrieving specific past facts, or when under a strict token budget.
DO NOT use for exploring structural, multi-hop entity relationships — use "context" instead.
RETURNS:
JSON object containing matched entities, facts with authority tiers and statuses, estimated tokens used, and truncation flag.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Graph expansion depth (0 = flat search, 1+ = multi-hop GraphRAG) | |
| query | Yes | Query text to search across facts and entities | |
| domain | No | Filter by domain | |
| token_budget | No | Maximum tokens to return (default: 2000) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and mostly delivers: it discloses the token budget enforcement, the context-window-overflow protection, result truncation, and that results carry authority tiers and statuses. It does not state side-effect profile (read-only) or any rate/permission constraints, but the disclosed behavior goes well beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose in one sentence, then uses compact WHEN TO USE and RETURNS sections. Every sentence is functional; the only mildly extraneous detail is the FTS5/BM25 implementation name, which is cheap and still useful for understanding ranking behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by describing the return payload (matched entities, facts with authority tiers and statuses, token usage, truncation flag). Combined with the routing guidance, this is essentially complete; only the read-only/no-side-effect guarantee is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so depth, query, domain, and token_budget are already documented in the schema. The description reinforces the token budget concept but adds no syntax, default semantics, or interaction details (e.g., how depth interacts with BM25) beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) plus resource (memory observations and facts) and even the matching mechanism (SQLite FTS5 BM25). It explicitly distinguishes itself from the sibling 'context' tool for structural/multi-hop queries, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains an explicit WHEN TO USE block with positive conditions (focused keyword search, retrieving specific facts, token-constrained situations) and a negative condition (DO NOT use for structural multi-hop relationships) that names the alternative tool. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberA
Store one or more factual observations under an entity in the knowledge graph. Automatically creates the entity if missing, evaluates pre-insertion contradiction detection against existing facts, assigns authority tiers, and records logical dependencies.
WHEN TO USE:
Use "remember" to record new knowledge, user preferences, architectural decisions, or verified facts.
DO NOT use to invalidate or delete outdated facts — use "forget" instead.
DO NOT use to query memory — use "recall" or "context" instead.
CONTRADICTION & RETURN BEHAVIOR:
Evaluates semantic opposition. If a contradiction is detected, a warning is returned and recorded in the audit log while persisting the fact.
Returns JSON containing { ok: true, entity, domain, tier, observationIds, contradictionWarnings }.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Authority tier: invariant (never decays), architectural (365d), contextual (90d), ephemeral (7d) | |
| type | No | Entity type (default: "concept") | |
| facts | Yes | List of facts/observations to remember | |
| domain | No | Domain namespace (default: "personal") | |
| entity | Yes | Entity name (e.g. "React Architecture", "Sabil Murti") | |
| derived_from | No | Observation IDs that these facts logically depend on (for truth maintenance) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so: auto-creation of missing entities, pre-insertion contradiction detection, authority-tier assignment, dependency recording, and the policy of persisting the fact while emitting a warning on contradiction. It also documents the side effect of audit-log recording and the return shape, which is exactly the kind of mutation/return transparency a no-annotation tool needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then cleanly sectioned into trigger and behavior blocks. Every line earns its place — the routing lines and the contradiction/return note each carry information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite six parameters and no output schema, the description supplies the return JSON keys (ok, entity, domain, tier, observationIds, contradictionWarnings) and the contradiction warning path. Combined with the usage and behavioral sections, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents entity, facts, tier, type, domain, and derived_from. The description echoes concepts (authority tiers, logical dependencies) but adds no syntax, defaults, or value guidance beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (store) and resource (factual observations under an entity in a knowledge graph) and explicitly distinguishes itself from the forget/recall/context siblings. An agent can identify this as the write path for memory without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The WHEN TO USE block gives explicit positive triggers (new knowledge, preferences, decisions, verified facts) and two explicit exclusions routing to 'forget' (invalidation) and 'recall'/'context' (querying). Nothing about when to pick this over a sibling is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remember_mediaA
Ingest an immutable media asset (image, audio, video, PDF, document) into Content-Addressable Storage (CAS) with SHA-256 deduplication. Automatically creates an entity representing the media, records descriptive observations about what the media depicts or contains, evaluates pre-insertion contradiction detection, establishes semantic relations to other entities, and synchronizes to dual-write Markdown.
WHEN TO USE:
Use "remember_media" when you have a local media file (screenshot, photo, voice note, document, diagram) and want to attach structured knowledge, descriptions, or relationships to it.
Amneshia handles storage, hashing, and relations deterministically with ZERO LLM overhead.
To query media facts later, use "recall" or "context".
RETURNS:
JSON containing { ok: true, entity, media: { sha256, mimeType, fileName, fileSize, relativePath, deduplicated }, observationIds, relations, contradictionWarnings }.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Authority tier for attached observations: invariant, architectural, contextual, ephemeral | |
| facts | Yes | Factual observations describing the media content, context, or visual elements | |
| domain | No | Domain namespace (default: "personal") | |
| entity | Yes | Entity name representing this media item (e.g. "Sabil Murti Profile Picture", "Architecture Diagram v3") | |
| filePath | Yes | Absolute or workspace-relative path to the source media file on disk | |
| relations | No | Semantic relationships linking this media entity to other entities |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses immutability, deterministic hashing/dedup, automatic entity creation, pre-insertion contradiction detection, relation establishment, and dual-write Markdown synchronization. It does not cover permission/auth requirements or failure modes (e.g. missing file, unsupported MIME), which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then cleanly sectioned into WHEN TO USE and RETURNS. Every sentence carries information an agent needs; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates with an explicit RETURNS block listing the JSON shape (sha256, mimeType, deduplicated, observationIds, relations, contradictionWarnings). Combined with the usage guidance, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents filePath, entity, facts, tier, domain and relations. The description only loosely links 'records descriptive observations' to facts and adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Ingest an immutable media asset ... into Content-Addressable Storage') and specifies the mechanism (SHA-256 deduplication). It is clearly distinguishable from siblings like remember, recall, context and forget, which are mentioned by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
An explicit WHEN TO USE block names the trigger condition (a local media file such as screenshot, photo, voice note, document, diagram) and routes the agent to 'recall' or 'context' for later querying. When-to-use and the alternative-tool path are both spelled out.
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.
1 tool update
v3.1.0- Added
remember_media
4 tool updates
v0.1.0- First observed
context - First observed
forget - First observed
recall - First observed
remember
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: remember and remember_media handle writing, recall and context handle reading, and forget handles deletion. Descriptions explicitly cross-reference and differentiate use cases, making selection unambiguous.
Most names are lowercase action verbs (remember, recall, forget), but 'context' is a noun and 'remember_media' uses an underscore. These are minor deviations from an otherwise consistent and readable convention.
Five tools is well-scoped for a memory/knowledge graph server, covering the essential operations without redundancy. Each tool clearly earns its place.
The core lifecycle (create, read, delete) is covered, with update handled via remember as documented. Minor gaps like no explicit update tool or entity listing exist, but workarounds prevent dead ends.
Maintenance
Related MCP Connectors
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA local memory engine for AI agents. Stores conversation episodes, consolidates knowledge through a neuroscience-inspired lifecycle, and builds a personal knowledge graph — all in a local SQLite database.18MIT
- AlicenseAqualityBmaintenanceSelf-hosted personal knowledge graph for Claude that persists across sessions, devices, and tools. Built on Neo4j with local semantic embeddings; OAuth 2.1 lets Claude Code, Claude Desktop, and claude.ai web all hit the same graph.2488 npm2MIT
- AlicenseNot gradedqualityBmaintenanceDynamic SQLite memory bank with semantic search, table management, and knowledge graphs for LLM agents.2MIT

mem0-mcpofficial
AlicenseAqualityCmaintenanceSelf-hosted Mem0 MCP server integrating Qdrant, Neo4j, and Ollama for semantic memory search, graph entity relationships, and memory management via OpenMemory API.64MIT