What can you do with this server?

This server gives an AI assistant a private, persistent local SQLite memory with five core tools. * Save facts: persist atomic facts, preferences, and technical rules with semantic deduplication and vector indexing, scoped by user and optional project/source tag. * Search memory: run hybrid FTS5 keyword + vector semantic search with RRF ranking; supports limits, user scoping, as_of point-in-time queries, and conversation-history query expansion. * Trace fact lineage: audit a fact's full revision/supersede history by UUID to see how rules changed and resolve conflicts. * Get current state: retrieve the active executive dashboard, project focus, and recent milestones for session bootstrap or task switching. * Consolidate memory: run AutoDream maintenance to synthesize progress, archive obsolete notes, update the project dashboard, and preserve other projects' cards.

Which integrations are available for this server?

Integrates with the Google Gemini API for cloud-based model inference across cognitive roles (e.g., notary, semantic arbiter, state orchestrator) and for embedding generation. Integrates with a local Ollama service to run cognitive role models (e.g., gatekeeper, notary) and generate embeddings (nomic-embed-text) for vector search. Provides persistent long-term memory storage using a local SQLite database, with hybrid search combining FTS5 BM25 and Int8 vector quantization for fast in-process retrieval.

sqlite-local-ai-memory

by cheveguerra

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

🧠 SQLite Local AI Memory

Give your AI assistant a real, permanent memory in 60 seconds.
No monthly database subscriptions. No Docker setup. Just a single private file on your computer.

🛑 The Problem: Why does your AI keep forgetting?

If you use AI coding assistants or chatbots (Claude Desktop, Cursor, Antigravity, etc.), you already know the frustration:

Total Amnesia: The moment you close the chat or start a new window, the AI forgets who you are, your tech stack, your server IPs, and your personal preferences.
Copy-Paste Hell: You have to re-explain the same context over and over, or paste giant text files into every single prompt.
Wasted Money & Sluggish Chats: Shoving massive chat histories into every prompt burns through your token budget, costs real money, and makes the AI slower and prone to confusion.

Related MCP server: ai-memory

✨ The Solution: A Private Brain in a Single File

sqlite-local-ai-memory gives your AI assistant a permanent, organized brain stored safely in a single file (memoria.db) right on your own machine.

How it works (In Plain English):

📝 1. The Active Notepad (What we are doing right now):
Keeps track of your immediate focus: active tasks, decisions made today, and next steps. When you open a fresh chat tomorrow, your AI instantly knows where you left off.
📚 2. The Knowledge Vault (Facts that rarely change):
Stores concrete knowledge—like your server configurations, preferred coding styles, or family rules. When something changes (e.g., an IP changes), it updates the active fact while keeping an audit trail of the past.
🌙 3. Nightly Cleanup / AutoDream (Keeping the brain tidy):
Just like the human brain organizes thoughts during sleep, when your AI is idle, it quietly reviews raw notes, merges duplicates, and connects related facts into a clean summary.

⚡ What Makes This Unique? (The "Secret Sauce")

Unlike simple chat logs or generic vector databases that dump raw text into a black box, this system uses 6 smart cognitive mechanisms that make your AI truly understand its memory:

🌙 1. AutoDream Engine (Sleep-Cycle Memory Cleanup)

Instead of letting thousands of chat messages pile up into an unreadable mess, AutoDream acts like the human brain during REM sleep:

Live Dashboard: Keeps an active summary of what you are building today.
Permanent Knowledge: Automatically distills key technical decisions into compact facts in SQLite.
Never Loses Unfinished Work: If a problem is left open or unresolved, AutoDream safely archives it with an [UNRESOLVED_CASE] tag so your AI can resume debugging weeks later without losing historical clues.

🐣 2. Open Case Incubator & Dynamic Memory Window

When troubleshooting a complex bug over multiple days, active investigations stay safely in an "incubator". When the AI finally consolidates the case, it doesn't just read the last message—it dynamically rewinds back in time to the exact moment the issue started, giving the AI 100% of the historical context to write the permanent fix.

⚖️ 3. Real-Time Contradiction Arbiter (Curing AI "Time Blindness")

Standard vector databases are completely blind to time. If you tell an AI "My server IP is .100" and two weeks later say "We moved the server to .205", normal vector search returns both and the AI hallucinates. Our Semantic Arbiter detects state contradictions instantly: it archives the old IP and sets the new IP as active in real time.

🚀 4. 100% Embedded Storage (Zero Database Servers)

Zero Docker containers to maintain. You don't need to install Chroma, run PostgreSQL with pgvector, or pay for cloud databases like Pinecone. Everything—keyword indexing and vector math—lives inside a single local SQLite file. It retrieves active notes in under 0.1 ms and deep memories in under 1.5 ms.

🛡️ 5. Two-Layer Noise Firewall (Chatter Blocker)

Protects your database and API bill from clutter:

Layer 1 (Instant Filter, 0 ms): Discards casual pleasantries ("hello", "thanks", "sounds good") immediately.
Layer 2 (Smart Sifter, 10 ms): Uses a tiny, fast model to drop non-knowledge conversation before invoking larger models.

🔎 6. Dual Hybrid Search (Exact Match + Meaning Combined)

Runs two searches simultaneously in parallel:

Exact Keyword Search (FTS5): Finds exact IP addresses, variable names, and error codes in < 0.5 ms.
Semantic Vector Search: Finds concepts even if you use completely different words.
It blends both results using reciprocal rank scoring to return the exact right answer every time.

🛡️ 7. Graceful Offline Fallback (Never Crashes)

If your internet drops or you run without API keys, the system never hangs or crashes. It gracefully falls back to bare-metal mode: your AI can still save facts directly and search everything locally via fast keyword search.

NOTE

Degradation Notice: While the system operates reliably without an LLM, the real magic and intelligence (AutoDream consolidation, contradiction arbitration, and semantic vector search) come alive when connected to an AI model (Google Gemini or local Ollama).

🔍 Honest Transparency: What is Local vs Cloud?

We believe in 100% honesty about how your AI memory operates:

Your Data & Storage: 100% Local & Private.
All your memories, search indexes, and notes live in a single standard SQLite file on your drive. You never pay for cloud vector databases (no Pinecone, no Qdrant, no monthly SaaS bills).
The AI Reasoning Layer (3 Operating Modes):
To organize notes, detect contradictions, and synthesize summaries, the system needs an AI model:
- 🟢 Mode 1: Cloud-Assisted (Recommended / Default): Uses lightweight Google Gemini API. It gives you flawless JSON formatting and deep reasoning for literally pennies (<$0.50 a month for thousands of notes).
- 🟡 Mode 2: 100% Offline with Ollama (Private Local AI): Works out-of-the-box with Ollama (qwen2.5-coder + nomic-embed-text) if you prefer to run entirely offline on your own hardware without sending a single byte to the internet.
- 🔴 Mode 3: Pure Bare-Metal Zero-LLM (Not Recommended): If you provide no API keys and Ollama is not installed, the engine gracefully falls back to raw SQLite FTS5 keyword storage without crashing. Warning: This mode is not ideal. Without an LLM, you lose intelligent noise filtering, contradiction arbitration, entity extraction, and AutoDream consolidation. It behaves merely as a fast keyword database rather than an intelligent cognitive brain.

🚀 Quick Start: Choose Your Scenario

Feature	Scenario 1: MCP Server (Recommended)	Scenario 2: Direct Node.js Library
Best For	90% of users: Cursor, Claude Desktop, VS Code	Developers building custom agents, bots, or backends
Setup Time	60 seconds (Zero coding required)	5 minutes (Standard `npm install` import)
How it works	Your AI client talks to memory via stdio tools	In-process native execution with sub-millisecond calls

🌟 Scenario 1: As an MCP Tool (Cursor, Claude Desktop, VS Code)

1. Add to your MCP Config (`claude_desktop_config.json` or `.cursor/mcp.json`):

{
  "mcpServers": {
    "sqlite-memory": {
      "command": "npx",
      "args": ["-y", "sqlite-local-ai-memory"],
      "env": {
        "GEMINI_API_KEY": "your-gemini-api-key"
      }
    }
  }
}

(Prefer 100% offline with Ollama? Replace GEMINI_API_KEY with ORCHESTRATOR_MODEL=ollama/qwen2.5:1.5b and OLLAMA_HOST=http://localhost:11434!)

2. The Secret Sauce: Add this Prompt to your `.cursorrules` or `CLAUDE.md`

To get true autonomous persistent intelligence, paste this instruction into your AI's rules:

# Persistent Memory Protocol
You have access to the `sqlite-memory` MCP server. Follow this operating cycle:

1. 🌅 Session Start: On your very first turn, call `get_current_state` silently to load your active working dashboard and tasks.
2. 🔎 Memory Recall: Before answering that you don't recall a technical decision or bug, run `search_memory("keywords")`.
3. 🔨 Milestone Learning: When you solve a bug or make an architectural decision, call `save_fact` with Causal Syntax:
   `[TYPE: BUGFIX|ARCHITECTURE] [CAUSE: <symptom>] -> [DECISION: <fix>] -> [EFFECT: <impact>]`
4. 🌙 Session Wrap-up: When wrapping up or when the user says goodbye, call `consolidate` to synthesize the dashboard and prune resolved issues.

💻 Scenario 2: As a Direct Node.js / TypeScript Library

For developers building standalone agents, CLI tools, or Discord/WhatsApp bots:

npm install sqlite-local-ai-memory

import { MemoryEngine } from "sqlite-local-ai-memory";

const memory = new MemoryEngine({
  dbPath: "./agent_memory.db",
  userId: "developer_1"
});

// 1. Cold-start: Load active working state in < 0.1 ms
const dashboard = memory.getDashboard("developer_1");

// 2. Just-in-Time RAG: Search hybrid memory in < 1.5 ms
const hits = await memory.search("PostgreSQL port configuration");

// 3. Save atomic causal facts (anti-collision arbiter built-in)
await memory.saveFact("[BUGFIX] [CAUSE: Port conflict] -> [DECISION: Moved to 5433] -> [EFFECT: Resolved]");

// 4. Maintenance: Run AutoDream cognitive consolidation at close
const result = await memory.consolidate("developer_1", "BACKEND_PROJECT");

🛠️ The 5 Simple Tools your AI Gets

Once connected via MCP, your AI assistant automatically gains these 5 commands:

Command	What it does in plain words
`save_fact`	"Remember that my PostgreSQL runs on port 5432." Saves an important fact permanently with automatic deduplication.
`search_memory`	"How do we deploy this project?" Searches your memory vault using hybrid keyword + semantic search in < 2 ms.
`get_current_state`	"What was I working on?" Reads the active project blackboard. (Note: Requires running `consolidate` at least once so the AI can synthesize the initial dashboard).
`get_fact_lineage`	"How did this server IP change over time?" Inspects the complete historical audit trail and past superseded versions of any fact.
`consolidate`	"Organize my notes and catch up." Reviews recent interactions, merges duplicates, archives resolved tasks, and builds the active `currentState` dashboard.

🔬 Need deep technical specs?
For in-depth math on Int8 scalar quantization, Reciprocal Rank Fusion (RRF), benchmark telemetry, and database PRAGMAs, check out the full Technical Architecture Reference (README_TECHNICAL.md).

💬 Frequently Asked Questions (FAQ)

Q: Where are my files stored?
A: In ~/.local-ai-memory/memoria.db on your computer. You can back it up, copy it, or delete it anytime. It is a standard SQLite file.

Q: Do I need Docker or complex database software?
A: No! Zero Docker containers, zero database servers. It runs directly inside Node.js.

Q: Is it safe for my privacy?
A: Yes. Your database never leaves your machine.

📄 License

MIT License — Free and open source for everyone.

Available Tools

5 tools

consolidateA

Executes cognitive memory maintenance (AutoDream): synthesizes progress, archives obsolete notes, and updates the project dashboard (batch write). Call only at session close or after major milestones, NOT on every turn. Preserves other projects' cards. Returns triage summary report.

Name	Required	Description	Default
`source`	No	Project or subsystem tag to consolidate (e.g. 'HOMELAB', 'AUDIOBOOK', 'TOTALCONNECT'). Preserves items belonging to other project tags in the dashboard. Alphanumeric and underscores only.
`userId`	No	User or agent namespace to consolidate. Defaults to 'user_default' when omitted.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that this is a batch write, that it archives obsolete notes (a destructive side effect), and that it preserves other projects' cards (scope boundary). It omits reversibility, required permissions, and any rate/cost caveats, so not 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences: purpose first, then the critical timing constraint, then the safety guarantee, then the return. Every sentence earns its place with no filler.

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 2-param tool with no annotations and no output schema, it covers purpose, invocation timing, side effects, scope boundaries, and the return value (triage summary report). Remaining gaps (reversibility of archiving, auth requirements) are modest.

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% and the schema already documents 'source' (tag semantics, preservation, allowed characters) and 'userId' (default namespace). The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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 names a specific verb+resource (cognitive memory maintenance / AutoDream) and enumerates concrete sub-actions: synthesizes progress, archives obsolete notes, updates the project dashboard. This is clearly distinguishable from the read/save siblings (get_fact_lineage, get_current_state, save_fact, search_memory).

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?

It gives an explicit when-to-call condition ('session close or after major milestones') and an explicit when-not ('NOT on every turn'), which is strong routing guidance. It stops short of naming alternative siblings for adjacent needs, so it is not a full 5.

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

get_current_stateA

Retrieves the active executive working dashboard, active project focus, and recent milestones (read-only). Use during session bootstrap or task switching for high-level orientation. Do NOT use for granular fact searches (use 'search_memory'). Returns formatted markdown dashboard.

Name	Required	Description	Default
`userId`	No	User or agent namespace whose active dashboard to read. Defaults to 'user_default' when omitted.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the read-only nature and the return format (formatted markdown dashboard), which covers the key behavioral traits. It does not mention auth requirements or namespace behavior beyond what the schema already states, leaving minor gaps.

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?

Front-loaded with the core verb and resources, then usage routing, then the return format. Three sentences with no wasted text.

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?

For a simple one-parameter read tool with no output schema, the description covers purpose, usage context, alternative, and return format. Nothing an agent needs to invoke it correctly is missing.

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?

There is a single parameter (userId) with 100% schema description coverage that already documents its meaning and default. The description adds no additional parameter semantics, so the baseline 3 applies.

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?

States a specific verb (Retrieves) plus three concrete resources (executive working dashboard, active project focus, recent milestones). It also explicitly contrasts itself with the sibling search_memory, so an agent can distinguish it 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('session bootstrap or task switching for high-level orientation') and when-not ('Do NOT use for granular fact searches') with the named alternative 'search_memory'. No inference is required.

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

get_fact_lineageA

Traces the full evolutionary history and supersede chain of a fact by its UUID (read-only). Use when auditing how or why a rule changed, or resolving conflicting facts. Obtain the UUID via 'search_memory'. Returns chronological revisions and rationale.

Name	Required	Description	Default
`point_id`	Yes	The exact UUID of the memory fact to trace (e.g. 'cc0675f1-4274-4854-9eac-4e85beadea05'). Obtainable from 'search_memory' results.

TDQS

A4.2/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 and does well: it declares the operation read-only and previews the return shape ('chronological revisions and rationale'). It stops short of disclosing depth limits, pagination, or behavior when a UUID has no lineage.

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?

Three short sentences with zero waste: purpose first, usage triggers second, acquisition path and return preview last. Every sentence 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?

For a single-parameter read tool with no output schema, the description covers purpose, trigger, ID sourcing, and a rough return summary. Missing only finer return semantics — how revisions are ordered/truncated or what an empty chain looks like.

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% and the single parameter already documents the exact UUID format and its source in 'search_memory'. The description restates that sourcing but adds no syntax or constraint information beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource — traces the evolutionary history and supersede chain of a fact — with the identifier type (UUID) named. It is clearly distinguishable from siblings like get_current_state and search_memory, which deal with present state or lookup rather than lineage.

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?

Gives explicit triggers ('auditing how or why a rule changed, or resolving conflicting facts') and a prerequisite path: obtain the UUID via 'search_memory'. It lacks an explicit when-not/negative case, but the positive routing is unambiguous.

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

save_factA

Persists an atomic fact, preference, or technical rule into long-term memory with automatic semantic deduplication and vector indexing (append-only write). Use for immediate logging; for search use 'search_memory', for evolution audits use 'get_fact_lineage', and for batch synthesis use 'consolidate'. Returns the assigned fact UUID and status.

Name	Required	Description
`fact`	Yes	The concise fact, technical decision, architecture rule, or user preference to store (e.g. 'PostgreSQL runs on port 5432 with peer authentication'). Must be self-contained and clear without pronouns.
`source`	No	Project or subsystem tag (e.g. 'HOMELAB', 'AUDIOBOOK', 'TOTALCONNECT'). Alphanumeric and underscores only. Used to partition and filter project memories.
`userId`	No	User or agent namespace to scope the memory. Defaults to 'user_default' when omitted.

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 carries the full burden and does substantial work: it discloses append-only semantics, automatic semantic deduplication, vector indexing, and the return payload (UUID + status). It stops short of explaining what happens on a dedup hit (is the existing UUID returned, is the write rejected?) and says nothing about permissions or capacity limits, so a mutation tool is not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and behavior, then a compact sentence covering alternatives and returns — no wasted content. It is dense, packing four sibling references and the return contract into one sentence, which costs a little readability.

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 3-param write tool with no output schema, the description supplies the return contract (UUID and status), which is exactly what's otherwise missing. The remaining gap is the dedup outcome — an agent cannot know whether a duplicate creates a new entry, returns the existing UUID, or errors, which materially affects repeated logging.

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% and the parameter docs are already rich (format constraints, examples, defaults), so the baseline is 3. The description only adds the semantic framing that 'fact' can be a preference or technical rule, which is marginal value beyond the schema.

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?

Specific verb+resource ('Persists an atomic fact... into long-term memory') with concrete scope (atomic fact, preference, technical rule) and explicit distinguishing from siblings by naming the roles of search_memory, get_fact_lineage, and consolidate. An agent can identify this as the write path 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States the selection condition directly ('Use for immediate logging') and routes each alternative case to a named sibling: search_memory for search, get_fact_lineage for evolution audits, consolidate for batch synthesis. Explicit when-to-use plus alternatives.

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

search_memoryA

Searches long-term memory using hybrid FTS5 BM25 lexical and vector cosine similarity with RRF ranking (read-only). Supports Point-in-Time queries via 'as_of'. Use for factual lookup and technical recall. For active high-level board use 'get_current_state'; for fact revisions use 'get_fact_lineage'. Returns ranked list of scored memory items.

Name	Required	Description
`as_of`	No	ISO 8601 timestamp (e.g. '2026-10-15T12:00:00Z') or date ('2026-10-15') for Point-in-Time retrospective queries. Returns only facts that were active and not yet superseded at that specific moment.
`limit`	No	Maximum number of ranked results to return (1-20). Defaults to 5 when omitted.
`query`	Yes	Search keywords, error messages, concepts, or questions (e.g. 'Proxmox vzdump backup schedule', 'auth token expiration'). Avoid conversational filler.
`userId`	No	User or agent namespace to search within. Defaults to 'user_default' when omitted.
`history`	No	Recent conversation dialogue (e.g. 'User: ... Assistant: ...'). When provided, the internal Query Expander resolves ambiguous pronouns and conversational context into explicit search terms.

TDQS

A4.4/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 burden and does so well: it declares the operation read-only, discloses the ranking approach and that Point-in-Time retrospectives are supported, and states the return shape ('ranked list of scored memory items'). It stops short of permission/auth requirements or any rate/limit behavior, keeping it out of the top band.

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?

Four compact sentences with no filler, each doing distinct work: capability, the as_of capability, routing to alternatives, and return shape. The core purpose is front-loaded before any technical detail.

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 five-parameter hybrid-search tool with no output schema, the description covers operation semantics, return format, and routing, and the schema covers every parameter fully. The only real gap is the absence of any note on scope or permissions, which is minor given the documented read-only nature.

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 all five parameters (as_of, limit, query, userId, history) are already fully documented in the schema. The description restates the 'as_of' capability but adds no syntax, format, or edge-case detail beyond what the schema specifies, which is the baseline-3 case.

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?

States a precise verb and resource ('Searches long-term memory') and adds the retrieval mechanism (hybrid FTS5 BM25 + vector cosine with RRF). It explicitly names the siblings it is not for ('get_current_state', 'get_fact_lineage'), 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives both a positive use case ('factual lookup and technical recall') and two explicit alternatives with the conditions that select them: high-level board state and fact revisions. When-to-use, when-not-to-use, and alternatives are all present.

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.

5 tool updatesv0.1.2Oct 20, 2026

Changedconsolidate2 fields changed

changedInput schema / properties / source / description

Previous value: -"Current project or source being consolidated (e.g. 'TOTALCONNECT'). Preserves items from other projects in dashboard. Alphanumeric only."New value: +"Project or subsystem tag to consolidate (e.g. 'HOMELAB', 'AUDIOBOOK', 'TOTALCONNECT'). Preserves items belonging to other project tags in the dashboard. Alphanumeric and underscores only."

changedInput schema / properties / userId / description

Previous value: -"User ID to consolidate (optional, default: user_default)."New value: +"User or agent namespace to consolidate. Defaults to 'user_default' when omitted."

Changedget_current_state1 field changed

changedInput schema / properties / userId / description

Previous value: -"Optional user ID to read the dashboard for."New value: +"User or agent namespace whose active dashboard to read. Defaults to 'user_default' when omitted."

Changedget_fact_lineage1 field changed

changedInput schema / properties / point_id / description

Previous value: -"UUID of the memory fact to trace"New value: +"The exact UUID of the memory fact to trace (e.g. 'cc0675f1-4274-4854-9eac-4e85beadea05'). Obtainable from 'search_memory' results."

Changedsave_fact3 fields changed

changedInput schema / properties / fact / description

Previous value: -"The fact or information to save."New value: +"The concise fact, technical decision, architecture rule, or user preference to store (e.g. 'PostgreSQL runs on port 5432 with peer authentication'). Must be self-contained and clear without pronouns."

changedInput schema / properties / source / description

Previous value: -"Source or project tag, e.g. 'TOTALCONNECT', 'SQLITE_MEMORY' (optional, alphanumeric only)."New value: +"Project or subsystem tag (e.g. 'HOMELAB', 'AUDIOBOOK', 'TOTALCONNECT'). Alphanumeric and underscores only. Used to partition and filter project memories."

changedInput schema / properties / userId / description

Previous value: -"Optional user ID to scope the memory fact."New value: +"User or agent namespace to scope the memory. Defaults to 'user_default' when omitted."

Changedsearch_memory5 fields changed

changedInput schema / properties / as_of / description

Previous value: -"Optional ISO timestamp (e.g. '2026-10-01T00:00:00Z') or date ('2026-10-01') for Point-in-Time retrospective queries. Returns facts as they existed at that exact moment in time."New value: +"ISO 8601 timestamp (e.g. '2026-10-15T12:00:00Z') or date ('2026-10-15') for Point-in-Time retrospective queries. Returns only facts that were active and not yet superseded at that specific moment."

changedInput schema / properties / history / description

Previous value: -"Optional recent conversation history (e.g. 'U: hi\\nA: hello\\nU: what was that thing?'). When provided, the Query Expander uses it to resolve ambiguous references."New value: +"Recent conversation dialogue (e.g. 'User: ... \nAssistant: ...'). When provided, the internal Query Expander resolves ambiguous pronouns and conversational context into explicit search terms."

changedInput schema / properties / limit / description

Previous value: -"Maximum number of results to return (default: 5, max: 20)."New value: +"Maximum number of ranked results to return (1-20). Defaults to 5 when omitted."

changedInput schema / properties / query / description

Previous value: -"Search terms or topic to recall."New value: +"Search keywords, error messages, concepts, or questions (e.g. 'Proxmox vzdump backup schedule', 'auth token expiration'). Avoid conversational filler."

changedInput schema / properties / userId / description

Previous value: -"Optional user ID to scope the search."New value: +"User or agent namespace to search within. Defaults to 'user_default' when omitted."

2 tool updatesv0.1.1Oct 19, 2026

Addedget_fact_lineage

Changedsearch_memory1 field changed

addedInput schema / properties / as_of

Added value: +{
+  "description": "Optional ISO timestamp (e.g. '2026-10-01T00:00:00Z') or date ('2026-10-01') for Point-in-Time retrospective queries. Returns facts as they existed at that exact moment in time.",
+  "type": "string"
+}

4 tool updatesv0.1.0Oct 19, 2026
- First observedconsolidate
- First observedget_current_state
- First observedsave_fact
- First observedsearch_memory

Deploy Server

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A4.4/5.0

Scored 2026-10-20 05:40 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: two targeted reads (get_fact_lineage, get_current_state), a broad search (search_memory), an atomic write (save_fact), and a batch maintenance write (consolidate). The descriptions explicitly cross-reference each other with 'use X instead of Y' guidance, eliminating selection ambiguity.

Naming Consistency4/5

Four tools follow a clean verb_noun or verb_noun-ish pattern (get_fact_lineage, get_current_state, save_fact, search_memory), while 'consolidate' is a bare verb. This is a minor deviation that remains readable and predictable.

Tool Count5/5

Five tools is well-scoped for a local memory server, with each earning its place across read, search, write, audit, and maintenance roles. No redundant or trivially fragmented tools.

Completeness4/5

The surface covers search, atomic persistence, lineage auditing, dashboard state, and batch consolidation, which spans the core memory lifecycle. An explicit forget/delete or update operation is absent, though append-only supersede via save_fact mostly compensates.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

MemorySync AOAuth
io.memorysync
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Autonomous Agents Developer Tools Knowledge & Memory
151
https://mcp.memorysync.io/mcp
mifactory-agent-memory C
io.github.mifactory-bot
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
22
https://agent-memory-api.vercel.app/mcp
Ace Memory BOAuth
io.github.rudedoggg
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Knowledge & Memory RAG Systems Autonomous Agents
4
https://ais.agentsandswarms.ai/mcp
goldhold
io.github.jerrysrodz
Persistent memory for AI agents. Search, store, and recall across sessions.
Knowledge & Memory Autonomous Agents RAG Systems
2
https://relay.goldhold.ai/mcp

Related MCP Servers

Local Memory MCP Server
Knowledge & Memory RAG Systems
danieleugenewilliams
-
license
Not graded
quality
Not graded
maintenance
Provides persistent local memory functionality for AI assistants, enabling them to store, retrieve, and search contextual information across conversations with SQLite-based full-text search. All data stays private on your machine while dramatically improving context retention and personalized assistance.
Updated a year ago (2025-08-10 13:02 UTC)
3
-
ai-memory
Knowledge & Memory RAG Systems
alphaonedev
A
license
Not graded
quality
A
maintenance
Persistent memory for any AI assistant. Zero token cost until recall. Stores memories in local SQLite, ranks by 6-factor scoring, returns results 79% smaller than JSON. Works with Claude, ChatGPT, Grok, Cursor, Windsurf, and any MCP client.
Updated 15 hours ago (2026-10-31 07:43 UTC)
56
Apache 2.0
sqlite-memory-mcp
Knowledge & Memory Developer Tools Autonomous Agents
RMANOV
A
license
A
quality
A
maintenance
Governed cross-agent memory for coding agents with hybrid retrieval, provenance tracking, and cross-machine sync.
Updated 14 days ago (2026-10-17 13:48 UTC)
9
18
MIT
Gingugu
Knowledge & Memory RAG Systems Developer Tools
gingugu
A
license
A
quality
A
maintenance
Persistent long-term memory for AI coding assistants. Local SQLite, no cloud - 16 MCP tools to store, search, relate, and consolidate typed memories with a confidence lifecycle, hybrid BM25 + semantic search, namespaces, a knowledge graph, and a built-in OS keychain credential vault.
Updated a day ago (2026-10-30 21:22 UTC)
23
7
MIT

🧠 SQLite Local AI Memory

🛑 The Problem: Why does your AI keep forgetting?

✨ The Solution: A Private Brain in a Single File

How it works (In Plain English):

⚡ What Makes This Unique? (The "Secret Sauce")

🌙 1. AutoDream Engine (Sleep-Cycle Memory Cleanup)

🐣 2. Open Case Incubator & Dynamic Memory Window

⚖️ 3. Real-Time Contradiction Arbiter (Curing AI "Time Blindness")

🚀 4. 100% Embedded Storage (Zero Database Servers)

🛡️ 5. Two-Layer Noise Firewall (Chatter Blocker)

🔎 6. Dual Hybrid Search (Exact Match + Meaning Combined)

🛡️ 7. Graceful Offline Fallback (Never Crashes)

🔍 Honest Transparency: What is Local vs Cloud?

🚀 Quick Start: Choose Your Scenario

🌟 Scenario 1: As an MCP Tool (Cursor, Claude Desktop, VS Code)

1. Add to your MCP Config (claude_desktop_config.json or .cursor/mcp.json):

2. The Secret Sauce: Add this Prompt to your .cursorrules or CLAUDE.md

💻 Scenario 2: As a Direct Node.js / TypeScript Library

🛠️ The 5 Simple Tools your AI Gets

💬 Frequently Asked Questions (FAQ)

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. Add to your MCP Config (`claude_desktop_config.json` or `.cursor/mcp.json`):

2. The Secret Sauce: Add this Prompt to your `.cursorrules` or `CLAUDE.md`