How do I use Local Memory MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Local Memory MCP store my birthday is in July" 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.

Local Memory MCP

by AQuietRiver

Overview Schema Related Servers Score Discussions

Python

Local

Local Memory MCP

Persistent, local semantic memory for tools that speak the Model Context Protocol. A connected client can save notes, context, and preferences during one session and recall them later by meaning rather than exact wording. Everything is kept in a single SQLite file on your machine, and embeddings are computed locally on the CPU.

License: MIT Python 3.11+ Tauri

Overview

The server runs over stdio and exposes three tools: one to store text, one to search it semantically, and one to clear a namespace. Stored text is embedded with a small sentence-transformer model and indexed for vector search with sqlite-vec. After a one-time model download, no network connection is needed.

An optional desktop application is included for inspecting and managing what has been stored.

Related MCP server: mesh-memory

Features

Three tools over MCP: store_memory, search_memory, wipe_project_memories.
Local embeddings with all-MiniLM-L6-v2 (384 dimensions).
Vector search backed by sqlite-vec in a single SQLite database.
Per-project namespaces through a project_tag field.
An importance score for each memory that decays with age and rises each time the memory is recalled.
A blacklist that stops chosen terms, such as .env or password, from being stored or written to the log.
An optional desktop dashboard with an activity feed, a memory table, and privacy controls.

How it works

flowchart LR
    C["MCP client"] -- "stdio" --> S["server.py (FastMCP)"]
    S --> E["memory_engine.py"]
    E -- "embeddings" --> M["all-MiniLM-L6-v2 (local CPU)"]
    E -- "read / write (WAL)" --> DB[("memory.db: SQLite + sqlite-vec")]
    UI["Desktop dashboard"] -- "read / delete / blacklist" --> DB

The server and the dashboard share one SQLite file in WAL mode. The dashboard can read and manage memory while the server is writing to it, and neither side blocks the other.

Requirements

Python 3.11 or newer
uv
For the desktop app: Rust, Node.js, and a C/C++ toolchain. On Windows that means the Visual Studio C++ Build Tools. See the Tauri prerequisites for other platforms.

Running the server

git clone https://github.com/AQuietRiver/local-memory-mcp.git
cd local-memory-mcp
uv sync
uv run python server.py

The first run downloads the embedding model (about 90 MB) and caches it. Later runs do not touch the network.

Connecting a client

Add a server entry to your MCP client's configuration file, using an absolute path:

{
  "mcpServers": {
    "local-memory": {
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/local-memory-mcp", "python", "server.py"]
    }
  }
}

Restart the client and the three tools become available.

Tools

Tool	Signature	Purpose
`store_memory`	`(content, metadata="", project_tag="global")`	Embed and save a piece of text. Rejected if it matches a blacklisted term.
`search_memory`	`(query, project_tag="global", limit=5)`	Rank stored text by semantic similarity to the query.
`wipe_project_memories`	`(project_tag)`	Delete every memory in a namespace.

Each tool has a docstring that the client reads to decide when to call it.

Desktop dashboard

A companion application for watching and managing the memory bank. It sits in the system tray and opens to three panels.

Panel	Function
Activity Feed	A chronological log of tool calls, showing the tool, the project, the text passed, and the result.
Memory Vault	A searchable table of stored memories with their tag, timestamp, and importance score, plus a per-row delete.
Privacy Center	A control to erase all memory at once, and a manager for blacklisted terms.

Deleting from the dashboard removes the embedding from disk as well as the row, not just the metadata.

Building

cd tauri-ui
npm install
npm run dev      # development window with hot reload
npm run build    # standalone installer and executable

The Windows vector extension (vec0.dll) is included under tauri-ui/src-tauri so the app can load sqlite-vec and remove embeddings. For macOS or Linux, place the matching vec0.dylib or vec0.so from the sqlite-vec releases in the same directory and update the resources entry in tauri.conf.json.

Scoring and blacklist

The importance score is 100 * 0.5^(age_days / 30) plus a small capped bonus for each recall, clamped to the range 0 to 100. Recency is the main factor; recalling a memory slows its decay. The Python engine and the dashboard compute the score the same way.

The blacklist is checked before any text is embedded. Comparison is case-insensitive and substring-based. A match is rejected, nothing is stored, and the activity log keeps a redacted record instead of the original text.

Data location

All data lives in a single file at ~/.config/local_memory_mcp/memory.db. There is no separate index or cache to manage.

Project layout

local-memory-mcp/
├── memory_engine.py     # database and embedding engine
├── server.py            # FastMCP server exposing the tools
├── pyproject.toml       # packaging and dependencies
├── test_smoke.py        # engine and tool-layer tests
├── test_features.py     # blacklist, scoring, activity, and wipe tests
└── tauri-ui/            # optional desktop dashboard
    ├── src/             # frontend (HTML, CSS, JavaScript)
    └── src-tauri/       # Rust backend (tray and read/write database layer)

Testing

uv run python test_smoke.py
uv run python test_features.py

cd tauri-ui/src-tauri
cargo test

License

MIT. See LICENSE.

Available Tools

3 tools

search_memoryA

Search local vector memory for context semantically similar to query.

Call this at the start of a task to surface relevant context from past sessions before you begin reasoning or writing code. The search is embedding-based (not keyword-based), so natural-language questions work better than exact terms.

Example queries:

"how does authentication work in this project?"
"user's preferred code style and formatting rules"
"database schema decisions"

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum results to return (1–20). Defaults to 5.
`query`	Yes	A natural-language description of what you are looking for.
`project_tag`	No	Restrict results to this namespace. Must match the tag used when storing. Defaults to "global".	global

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description bears the full burden. It discloses the tool reads from vector memory and is embedding-based, but lacks details on side effects (e.g., no write operations implied), performance, or error states. The description is adequate but not exhaustive for a read-only search.

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?

The description is about 5 sentences and includes a structured list of example queries. It front-loads the core purpose and usage guidance. While clear and efficient, it could be slightly more concise without losing information; hence 4.

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?

Given 3 parameters (1 required) with full schema coverage, a known output schema, and sibling tools provided, the description achieves reasonable completeness. It covers usage timing and query formulation well. However, it briefly mentions the output schema exists but does not reference it, which is acceptable.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing example queries that illustrate how to use the `query` parameter effectively, going beyond the schema's simple description. This helps the agent formulate better queries, earning a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches local vector memory for semantically similar context, with a specific verb ('search') and resource ('local vector memory'). It distinguishes from siblings (store_memory, wipe_project_memories) by focusing on retrieval. The embedding-based nature is explicitly mentioned, clarifying the tool's approach.

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?

The description explicitly advises calling this tool at the start of a task before reasoning or writing code, providing clear context. It explains that natural-language queries work better than exact terms. However, it does not explicitly mention when not to use it or direct alternatives, though sibling tools are listed separately.

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

store_memoryA

Store a piece of text as a semantic memory in the local vector database.

Call this tool whenever the user explicitly asks you to remember something, or whenever you observe context that should survive the current session:

Architectural decisions or design rationale
User preferences and working-style notes
Frequently-referenced file paths or API endpoints
Summaries of long conversations or research findings

One focused idea per memory retrieves better than a large wall of text.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	The raw text to remember.
`metadata`	No	Optional free-text or JSON annotation (source URL, category, author). Stored verbatim; not searched.
`project_tag`	No	Logical namespace, e.g. "my-api", "dotfiles", "global". Defaults to "global" for cross-project context.	global

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It explains the tool stores text as semantic memory with persistence across sessions. Adds content quality guidance. Does not disclose output format, error handling, or storage limits, but for a store tool it provides reasonable transparency.

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?

Concise description with clear main sentence, followed by bulleted usage examples and a best practice note. No unnecessary words or repetition. Front-loaded with purpose.

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?

Given the tool's simplicity (3 parameters, required 1), description covers purpose, usage guidance, and parameter details adequately. Output is not described, but output schema likely covers that. Missing potential constraints like storage limits, but overall complete for the context.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds value: explains content should be focused; metadata is optional free-text or JSON, stored verbatim and not searched; project_tag is a logical namespace defaulting to global. These details enhance schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Store a piece of text as a semantic memory in the local vector database,' defining verb and resource. Distinguishes itself from siblings 'search_memory' and 'wipe_project_memories' as the creation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Explicitly says when to call: when user asks to remember something or when context should survive the session. Lists concrete examples (decisions, preferences, file paths, summaries). Provides best practice (one focused idea). Doesn't explicitly state when not to use, but guidance is strong.

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

wipe_project_memoriesA

Permanently delete all memories stored under project_tag.

This action is irreversible — vectors and metadata are removed from disk immediately. Only call this when the user has explicitly asked to clear or reset memory for a project. When in doubt, confirm with the user before calling.

ParametersJSON Schema

Name	Required	Description	Default
`project_tag`	Yes	The namespace to wipe (e.g. "my-api"). Passing "global" clears cross-project memories.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A5/5.0

Behavior5/5

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

Clearly states irreversibility, immediate disk deletion, and what gets removed (vectors and metadata). No annotations provided, so description fully compensates by disclosing destructive nature.

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 sentences: action+scope, consequences, usage guidance. No fluff. Front-loaded with key information.

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?

Single-parameter tool with output schema. Description covers purpose, usage, behavior, and parameter semantics comprehensively. No gaps given simplicity and existing structured fields.

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

Parameters5/5

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

Schema description already explains project_tag as namespace and global special case. Description adds context: 'namespace to wipe', examples, and clarifies scope. Adds value beyond schema despite 100% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description specifies exact verb ('Permanently delete') and resource ('all memories stored under project_tag'). Clearly distinguishes from siblings (search_memory, store_memory) by stating it's a destructive wipe operation.

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?

Explicitly states when to invoke ('only when the user has explicitly asked to clear or reset memory') and provides a caution ('when in doubt, confirm with user'). Also implies irreversibility, guiding appropriate use.

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

Install Server

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

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: search retrieves, store adds, wipe deletes. No ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (search_memory, store_memory, wipe_project_memories).

Tool Count5/5

3 tools cover the core operations for a local memory server (search, store, delete). The count is well-scoped and earns its place.

Completeness4/5

The set covers essential memory operations, but lacks an update or list tool. However, delete+re-store can update, and search serves as discovery. Minor gap.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Taproot
com.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Knowledge & Memory Note Taking
2
nexsus
io.github.dbnexsus
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Knowledge & Memory RAG Systems
2
WorkingMemory A
ai.workingmemory
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Knowledge & Memory Search
42
mcp-server
in.creo-memories
Memory system for AI agents with semantic search. Store and recall memories with ease.
Knowledge & Memory Search RAG Systems
2

Related MCP Servers

Memento
Knowledge & Memory Databases Vector Databases
iAchilles
A
license
A
quality
C
maintenance
A local, fully-offline MCP memory server that enables persistent storage and retrieval of information using SQLite with both keyword and semantic vector search capabilities.
Updated 3 months ago (2026-06-12 22:05 UTC)
10
23
12
MIT
mesh-memory
Knowledge & Memory RAG Systems
dklymentiev
A
license
Not graded
quality
D
maintenance
Self-hosted semantic memory for AI agents. Save worklogs, decisions, and notes via MCP, then recall them across sessions by meaning rather than keyword. Backed by Postgres + pgvector with local embeddings (multilingual-e5-base).
Updated 4 months ago (2026-04-28 20:11 UTC)
1
MIT
hypermnesia
Knowledge & Memory Vector Databases Search
others-git
A
license
Not graded
quality
B
maintenance
A semantic memory store for AI agents, enabling persistent memory across sessions via MCP tools with semantic search, scoped access, and local embeddings.
Updated a month ago (2026-07-24 04:40 UTC)
MIT
HKC Memory Server
Knowledge & Memory RAG Systems Vector Databases
ag1357
F
license
Not graded
quality
D
maintenance
An MCP server for managing persistent AI memory using hybrid search (keyword + semantic vector) with SQLite storage and offline-first local embeddings.
Updated a year ago (2025-10-06 10:58 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AQuietRiver/Synapse-MCP'

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