Skip to main content
Glama
MihaiBuilds

Memory Vault

by MihaiBuilds

Memory Vault

Tests License: MIT Python 3.11+ Latest Release Docker Image MCP Registry Ruff

The memory database for AI applications. Self-hosted Postgres + pgvector with hybrid search, MCP-native, and a knowledge graph baked in.

Every conversation with Claude or ChatGPT starts from zero. No memory of what you built last week, what decisions you made last month, what problems you've already solved. You either re-explain everything from scratch, or paste in a wall of context and hope it fits in the window.

Memory Vault is the persistent layer underneath. It stores what you want your AI to remember — decisions, conversations, notes, project context — in a single Postgres database with hybrid semantic + keyword search. Claude can recall and store memories during any session via MCP, you can chat with your own memories through a local LLM, or you can build your own AI tool on top of the REST API.


Memory Vault chat with sources

Chat with your vault using a local LLM. Every answer shows the exact memories it was grounded in — click any source to verify.


Status

v1.0 — released 2026-05-07. First stable release of Memory Vault. M1-M7 (hybrid search, Docker, MCP, REST API, dashboard, knowledge graph, local LLM chat) all shipped and stable.

See CHANGELOG.md for the full per-release history, or GitHub Releases for the platform-native view.

Semver from here forward — the public surface (REST API endpoints, MCP tool signatures, DB schema) is stable. Breaking changes only on a major version bump.


Related MCP server: Frinus MCP Server

Quick Start (Docker)

git clone https://github.com/MihaiBuilds/memory-vault.git
cd memory-vault
docker compose up -d

That's it. PostgreSQL + pgvector + Memory Vault, running and ready. Migrations run automatically on first start.

# Check it's working
docker compose exec app memory-vault status

# Ingest a file
docker compose exec app memory-vault ingest /path/to/file.md --space default

# Search
docker compose exec app memory-vault search "your query here"

Data persists in a Docker volume — docker compose down and up again, your memories are still there.

Open http://localhost:8000 in your browser to use the dashboard (Chat, Search, Browse, Graph, Ingest, Stats).

Windows users: clone into WSL2, not a Windows path, and read docs/windows.md if you hit a line-ending error.


No-Docker quick start

If you prefer running without Docker:

Prerequisites

  • Python 3.11+

  • PostgreSQL 16 with pgvector extension

  • uv (recommended) or pip + venv

# Clone
git clone https://github.com/MihaiBuilds/memory-vault.git
cd memory-vault

# Create virtual environment and install dependencies
uv sync

# Install the spaCy language model
uv run python -m spacy download en_core_web_sm

# Configure
cp .env.example .env
# Edit .env with your PostgreSQL credentials

# Run migrations
uv run memory-vault migrate

# Verify
uv run memory-vault status

Setup with pip + venv (fallback)

If you don't want to install uv, plain pip + venv works too:

# Clone
git clone https://github.com/MihaiBuilds/memory-vault.git
cd memory-vault

# Create virtual environment
python -m venv .venv
source .venv/bin/activate

# Install dependencies
pip install -e .

# Install the spaCy language model
python -m spacy download en_core_web_sm

# Configure
cp .env.example .env
# Edit .env with your PostgreSQL credentials

# Run migrations
memory-vault migrate

# Verify
memory-vault status

Usage

If you set up with uv, prefix commands with uv run (e.g. uv run memory-vault search ...). If you used pip + venv, activate the venv first (source .venv/bin/activate) and run commands directly:

# Ingest a file
memory-vault ingest notes.md --space default

# Search memories
memory-vault search "hybrid search architecture" --limit 5

# Check status
memory-vault status

Features

  • Hybrid search — semantic similarity + keyword matching combined, so you find the right memory even when you don't remember the exact words

  • MCP integration — four tools (recall, remember, forget, memory_status) that Claude can use natively during any session

  • Local LLM chat — query your own memories through LM Studio without sending anything to the cloud, with sources shown for every answer

  • Knowledge graph — entities and relationships extracted automatically, connections between things emerge over time

  • Memory spaces — separate namespaces for different projects or domains

  • REST API — integrate AI memory into any application

  • One-command setupdocker compose up and it's running

  • Self-hosted — your data stays on your machine, always


Architecture

Memory Vault architecture

Postgres + pgvector at the core. The same memory layer is reachable from MCP (Claude), the dashboard chat page, the REST API, and any app you build on top.

Three things are deliberate about this stack:

  • One database, not two. Vector embeddings, full-text indexes, and relational data all live in Postgres. No separate vector DB to keep in sync.

  • Frontend-agnostic. The dashboard is one consumer of the API, not the API itself. MCP, REST, CLI, and your own apps are equal first-class clients.

  • CPU-only by default. No GPU required. Embeddings (sentence-transformers) and entity extraction (spaCy) both run on a normal laptop.


Tech Stack

  • PostgreSQL 16 + pgvector — vector storage and hybrid search in one database

  • Python 3.11+ — async backend with psycopg 3

  • sentence-transformersall-MiniLM-L6-v2 embeddings (384-d, runs on CPU)

  • spaCyen_core_web_sm for entity extraction (CPU-only, no LLM calls)

  • FastAPI — REST API with bearer auth, rate limiting, and OpenAPI docs

  • React 19 + Vite + TanStack Query — web dashboard, baked into the main Docker image

  • Cytoscape.js + cose-bilkent — force-directed knowledge graph rendering on the dashboard

  • Docker — one-command deployment with docker compose up

  • MCP — Claude integration via FastMCP (stdio transport)


MCP Integration (Claude Desktop & Claude Code)

Memory Vault exposes four tools via the Model Context Protocol so Claude can read and write memories during any conversation.

Tools

Tool

Description

recall

Search memories with hybrid search (vector + full-text + RRF)

remember

Store a new memory — auto-classified and embedded

forget

Soft-delete a memory by chunk ID

memory_status

Database health, chunk counts, embedding model info

Resources

Resource

Description

memory://spaces

List all memory spaces with chunk counts

memory://stats

Current system statistics

Setup — Claude Code

Make sure you've completed the No-Docker quick start above (uv sync or pip install, plus the spaCy model download) so the memory_vault package is installed.

Project scope — add to your project's .mcp.json:

{
  "mcpServers": {
    "memory-vault": {
      "command": "/path/to/memory-vault/.venv/bin/python",
      "args": ["-m", "memory_vault.mcp"],
      "env": {
        "DB_HOST": "localhost",
        "DB_PORT": "5432",
        "DB_NAME": "memory_vault",
        "DB_USER": "memory_vault",
        "DB_PASSWORD": "memory_vault"
      }
    }
  }
}

Global scope — to make memory-vault available in every Claude Code session, add the same server block to ~/.claude/.mcp.json, then add memory-vault to enabledMcpjsonServers in ~/.claude/settings.json:

{
  "enabledMcpjsonServers": ["memory-vault"]
}

Verify with claude mcp listmemory-vault should show connected.

Setup — Claude Desktop

Add the same server block to Claude Desktop's config (Settings → Developer → Edit Config), then restart Claude Desktop.

Docker Users

If you're running Memory Vault via Docker, use DB_HOST: "127.0.0.1" and make sure port 5432 is exposed in your docker-compose.yml:

{
  "mcpServers": {
    "memory-vault": {
      "command": "/path/to/memory-vault/.venv/bin/python",
      "args": ["-m", "memory_vault.mcp"],
      "env": {
        "DB_HOST": "127.0.0.1",
        "DB_PORT": "5432",
        "DB_NAME": "memory_vault",
        "DB_USER": "memory_vault",
        "DB_PASSWORD": "memory_vault"
      }
    }
  }
}

The MCP server runs on the host (not inside Docker) and connects to the PostgreSQL container over the exposed port.

Verify It Works

Once configured, Claude will have access to the memory tools. Try:

"Use memory_status to check the memory system."

"Remember that we chose Redis for the session cache."

"Recall everything about hybrid search."

Troubleshooting

  • ModuleNotFoundError on startup — the virtual environment isn't installed; re-run uv sync (or pip install -e .) in the repo directory.

  • OSError: [E050] on startup — the spaCy language model isn't installed; re-run python -m spacy download en_core_web_sm.

  • Server shows failed in Claude Code — run claude --debug mcp to see the server's error output.

  • Tools not available in Claude Code despite server connecting — confirm memory-vault is listed in enabledMcpjsonServers in ~/.claude/settings.json.

  • Connection refused with Docker running — use DB_HOST: "127.0.0.1" instead of "localhost".


Local LLM Chat

Memory Vault includes a chat page that lets you talk to your own memories using a local LLM — no cloud, no OpenAI key, no telemetry. The dashboard runs hybrid search against your vault, builds a context block from the top hits, and streams the answer back from a model running on your machine.

Sources are shown with every answer. Every response includes the exact chunks the LLM used, with similarity scores and content previews. Click any source to verify the answer is grounded in your data, not invented. This is the differentiator vs. opaque chat-over-docs tools — you always know what the model saw.

Setup

Memory Vault uses LM Studio as the local LLM provider in v1.0.

  1. Download and install LM Studio.

  2. Load a non-thinking model — Qwen2.5 (7B+), Llama 3 (8B+), or similar. Avoid Qwen3, DeepSeek-R1, and o1-style reasoning models — they emit chain-of-thought into the answer and break the RAG flow.

  3. Start the local server (LM Studio → Developer tab → Start Server). Default address: http://localhost:1234.

  4. Open the Memory Vault dashboard → Chat page → ⚙️ Settings → confirm the Local LLM URL points at your LM Studio instance. The model is auto-detected.

That's it. Ask a question; the dashboard retrieves relevant chunks, sends them with your question to LM Studio, and streams the answer back.

How it works

  1. Hybrid search retrieves the top chunks for your question (same engine as /api/search and MCP recall)

  2. Top hits are packed into a 6,000-token context budget — oldest history dropped first, then lowest-similarity chunks

  3. LM Studio generates an answer streamed token-by-token via Server-Sent Events

  4. Sources arrive first in the stream, so the UI shows "based on N memories" before tokens start flowing

Why LM Studio first

LM Studio's native API supports reasoning="off", which is the only reliable way to suppress chain-of-thought from thinking models in a RAG flow. Memory Vault uses the native API by default and falls back to OpenAI-compat (/v1/chat/completions) with <think>...</think> stripping if the native API isn't available.


REST API

Every MCP tool is also exposed as an HTTP endpoint so you can integrate Memory Vault into any app, script, or language. The API is served by FastAPI at http://localhost:8000 when you run docker compose up.

The auto-generated /docs page is the canonical API reference — it stays in sync with the code. The summary below is for orientation.

Authentication

All endpoints except /api/health require a bearer token. Create one via the CLI:

docker compose exec app memory-vault token create my-app

The plaintext token is shown once — copy it immediately. Then send it as a header:

curl -H "Authorization: Bearer mv_..." http://localhost:8000/api/spaces

Manage tokens:

memory-vault token list
memory-vault token revoke mv_abc1234

To disable auth entirely (local dev only), set API_AUTH_ENABLED=false.

Endpoints

Method

Path

Description

GET

/api/health

Service + database health (no auth)

GET

/api/spaces

List memory spaces with chunk counts

POST

/api/search

Hybrid search (vector + full-text + RRF)

GET

/api/chunks

List chunks with pagination and filters

GET

/api/chunks/{id}

Get a single chunk

DELETE

/api/chunks/{id}

Soft-delete (forget) a chunk

POST

/api/ingest/text

Ingest a text string as a chunk

POST

/api/ingest/file

Upload a file through the ingestion pipeline

POST

/api/chat

RAG chat over hybrid search (non-streaming)

POST

/api/chat/stream

RAG chat with token-by-token SSE streaming

curl -X POST http://localhost:8000/api/search \
  -H "Authorization: Bearer $MV_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "how does hybrid search work",
    "spaces": ["default"],
    "limit": 5
  }'

Example — ingest text

curl -X POST http://localhost:8000/api/ingest/text \
  -H "Authorization: Bearer $MV_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"text": "Decided to use RRF for hybrid merging", "space": "default"}'

Example — upload a file

curl -X POST http://localhost:8000/api/ingest/file \
  -H "Authorization: Bearer $MV_TOKEN" \
  -F "file=@notes.md" \
  -F "space=default"

Configuration

Variable

Default

Description

API_HOST

0.0.0.0

Bind address

API_PORT

8000

Port

API_AUTH_ENABLED

true

Set false to disable bearer auth (local dev only)

API_CORS_ORIGINS

*

Comma-separated allowed origins, or *

API_RATE_LIMIT_PER_MIN

120

Per-IP request limit per minute


Dashboard

Memory Vault ships with a web UI baked into the same Docker image as the API — no separate deploy, no extra port. Open http://localhost:8000 in your browser after docker compose up.

Six pages:

  • Chat — talk to your vault with a local LLM, sources shown for every answer (default landing page)

  • Search — hybrid search with space filter, similarity scores, expandable hit content

  • Browse — paginated chunk list with space + sort filters, two-step inline delete

  • Graph — force-directed knowledge graph (Cytoscape.js), pan/zoom, click a node to see its mentions and related entities, filters for space / type / min-mentions / max-nodes

  • Ingest — paste text or upload files (one at a time in v1.0), per-file status, batch summary

  • Stats — system health, total chunks, spaces table with visual distribution, auto-refresh every 30s

Access

The dashboard uses the same bearer token as the API. Create one and paste it into the dashboard's token screen:

docker compose exec app memory-vault token create dashboard

The plaintext token is shown once — copy it immediately. Open http://localhost:8000, paste into the prompt, and the dashboard stores it in localStorage under memory-vault-token. You won't be asked again on that browser.

Rotating or revoking

# See which tokens exist
docker compose exec app memory-vault token list

# Revoke by prefix (shown in list output)
docker compose exec app memory-vault token revoke mv_abc1234

# Create a new one
docker compose exec app memory-vault token create dashboard

After revoking, the dashboard will hit a 401 on its next request and auto-clear the stored token, forcing you to paste the new one.

Troubleshooting

  • Prompted for token every reload: your browser is blocking localStorage (private mode, strict cookie settings). Use a normal window or allow storage for localhost.

  • 401 on every request: the token was revoked or API_AUTH_ENABLED changed. Create a fresh token and paste it in.

  • Dashboard shows but API calls fail with CORS: you're hitting the API on a different origin than the dashboard. The baked-in build avoids this — use http://localhost:8000, not the dev server, unless you know what you're doing.

  • Running the dev server: cd web && npm install && npm run dev serves the UI at http://localhost:5173 with API calls proxied to :8000. For development only.

  • Windows-specific issues: see docs/windows.md.

  • Reporting a bug: run docker compose exec app memory-vault diagnose (or memory-vault diagnose on the host for a fuller bundle including docker compose ps + db logs). The command writes a memory-vault-diagnostic-YYYY-MM-DD-HHMMSS.zip containing app logs, status, OS info, and redacted env vars. Bearer tokens, passwords, and mv_ tokens are auto-scrubbed — but please review the bundle before attaching it to a public GitHub issue.

  • Quoting a request ID: every API response carries an X-Request-ID header (UUID hex). Include it in bug reports — it lets the maintainer grep the same request across the structured JSON logs.


How It Works

Memory Vault combines two search methods and merges the results:

  1. Vector search — converts your query to an embedding, finds semantically similar chunks via HNSW index

  2. Full-text search — keyword matching via PostgreSQL tsvector + GIN index

  3. RRF merging — Reciprocal Rank Fusion combines both ranked lists so neither method dominates

This means you find the right memory whether you remember the exact words or just the concept.

Query Enrichment

Before searching, Memory Vault generates up to 3 query variations using the embedding model's WordPiece tokenizer to extract key technical terms. This improves recall without losing precision.

Ingestion Pipeline

Async queue-based pipeline with adapters for different input formats:

  • Markdown — splits by headings, preserves structure

  • Plain text — paragraph-based with smart merging

  • Claude JSON — parses Claude conversation exports

Knowledge Graph

Memory Vault extracts entities and relationships from every ingested chunk and stores them alongside your memories. Click the Graph page in the dashboard to see how the things you've stored connect to each other.

How extraction works:

  • spaCy NER — the small en_core_web_sm model (~15 MB, CPU-only) tags PERSON, ORG, and PRODUCT entities, mapped to Person, Project, and Tool respectively.

  • Concept extraction — multi-token noun phrases that appear at least twice within a chunk become Concept entities. No LLM, no API calls.

  • Co-occurrence relationships — any two entities found in the same chunk produce a related_to relationship. Edge weight grows with co-occurrence count across chunks.

  • Per-space deduplication — entities are deduplicated by (lower(name), type, space), so the same entity stays one node within a space without merging across unrelated projects.

The whole pipeline runs synchronously on ingest, on the same CPU that runs the embeddings — no extra services, no external API costs.

These trade-offs are deliberate. spaCy + co-occurrence is fast, free, and gets you 80% of the way to a useful graph at 0% of the LLM cost. The honest gaps are documented in the Limitations section below.


Performance Tuning

Memory Vault ships with maintenance_work_mem = 1 GB as the default in the bundled docker-compose.yml. The stock PostgreSQL default is 64 MB, which makes HNSW index builds on pgvector painfully slow once your corpus grows past a few thousand chunks.

If you're running on a host with 16 GB of RAM or more, bumping this to 2 GB gives noticeably faster index rebuilds with no downside. Edit the command: block in docker-compose.yml:

db:
  image: pgvector/pgvector:pg16
  command:
    - postgres
    - -c
    - maintenance_work_mem=2GB

If you're running on a small box (4 GB total RAM or less, e.g. a tiny VPS), you may want to drop this back down to 256 MB so the rest of the system has breathing room. Memory Vault still works at the stock 64 MB default — it's just slower on large index rebuilds.


Limitations

v1.0 limitations (honest)

  • English-only NER. en_core_web_sm is English-trained; non-English text gets little to no useful entity extraction. Hybrid search and chat work fine in any language — only the auto-extracted knowledge graph is English-limited.

  • NER is context-dependent. spaCy decides PERSON vs. ORG based on the surrounding sentence. The same name can land as both Person and Project entities depending on syntactic role.

  • No fuzzy entity matching. "PostgreSQL" and "Postgres" are separate entities. No alias merging in v1.0.

  • No re-extraction on edit. If you forget a chunk and re-ingest a corrected version, the new entities are added; the old ones aren't cleaned up automatically.

  • Single-instance. No multi-user / multi-tenant. One vault per deployment. Team features are PRO.

  • LM Studio only for chat. No Ollama provider in v1.0.


PRO tier (planned)

Team features, advanced analytics, hosted tier. The free / open-source core stays free forever — open-core, not bait-and-switch.


FAQ

How is this different from claude-mem / cognee / Mem0?

Different layer of the stack. Filesystem-based tools (claude-mem, claudesidian, obsidian-second-brain) keep markdown notes on disk and use grep/read at retrieval time. They work great until your vault grows past a few thousand notes — then grep gets slow and semantic recall isn't there. Memory Vault is a database-backed memory layer (Postgres + pgvector + tsvector + RRF) designed to scale and to be built on top of. Frontend-agnostic. Use it through MCP, REST, the dashboard, or your own app — all equal first-class clients.

cognee and Mem0 are closer in stack but cloud-first or SDK-first. Memory Vault is self-hosted infrastructure-first.

Do I need a GPU?

No. Default embeddings (all-MiniLM-L6-v2, 384-d) and entity extraction (en_core_web_sm) both run on CPU. Local LLM chat uses LM Studio on whatever hardware you have — a modern 16 GB-RAM machine handles 7B-parameter models comfortably.

Is my data sent to the cloud?

No. Memory Vault is self-hosted end-to-end. Embeddings are local (sentence-transformers), entity extraction is local (spaCy), chat uses your local LM Studio instance. No telemetry, no API calls to OpenAI / Anthropic / anyone. Your data stays on your machine, period.

Can I use it without Claude?

Yes. The MCP integration is one of three interfaces. The REST API and dashboard work standalone. Use the chat page with any local LLM (LM Studio supports many open-weights models), or build your own AI tool on top of the API.

What languages does NER support?

English only in v1.0. The default spaCy model is English-trained — non-English text gets little to no useful entity extraction. No multilingual NER in v1.0. Hybrid search and chat work fine in any language; only the auto-extracted knowledge graph is English-limited.

How much disk and RAM does it need?

Roughly: 2 GB disk (Docker image + Postgres data + spaCy + embedding model), 1-2 GB RAM idle, 4 GB+ recommended for active use. The bundled config sets maintenance_work_mem=1GB for fast HNSW index builds — drop it to 256 MB on a small VPS.

Can I run multiple Memory Vault instances?

Yes. Each instance is a single docker compose up. Use separate compose project names (docker compose -p mv-personal up, docker compose -p mv-work up) to keep them isolated, or clone into separate directories.

What happens to my data on future updates?

Migrations are versioned and forward-only. docker compose pull && docker compose up -d runs new migrations on start. Schema changes will be additive within v1.x — no destructive migrations on a minor version bump. That's part of the v1.x semver promise.


Contributing

Memory Vault is MIT-licensed and PRs are welcome. See:

Single-maintainer project. PRs are reviewed when I have time. Big features should be discussed in an issue first.


License

The core is MIT licensed — free forever. Everything that makes Memory Vault useful as a personal memory system (hybrid search, MCP integration, knowledge graph, dashboard, local LLM chat, Docker setup) will always be free and open source.

A PRO tier for teams and advanced features is planned.


Credits

  • @rivestack — Postgres + pgvector tuning tips that landed in v1.0 (maintenance_work_mem=1GB for fast HNSW builds). More of his suggestions are on the list.

  • Beta testers — the people who cloned, broke, and reported things during M1-M7

  • The open source giants this is built on — PostgreSQL, pgvector, sentence-transformers, spaCy, FastAPI, FastMCP, React, Cytoscape.js


Acknowledgments

The GitHub contributor list credits everyone whose code is in the repo. This section acknowledges reporters and diagnosticians whose insight shaped shipped work but doesn't appear in commit authorship.

  • Leonard Janke (lcjanke2020), working with GPT-5.6-Sol through OpenAI Codex (@lcj-codex-coder) — 20+ issues reported across the v1.0.7–v1.0.10 window, spanning version-drift, MCP correctness, timezone handling, embedding-dimension validation, and knowledge-graph soft-delete semantics. Peer-tier diagnostics; every report came with a disposable-database reproduction.

  • @git-pharos — diagnostic bundle in #74 that exposed three underlying issues fixed in v1.0.7.

Security reports and correctness findings are always credited by handle, plus any format the reporter specified — including tooling attribution where requested.


Follow the Build

Watch the repo to follow along.

Available Tools

6 tools
forgetA

Soft-delete a memory chunk by ID.

The chunk is removed from search results but stays in the database for potential recovery. Sets importance to 0 and marks it in metadata.

Args: chunk_id: The UUID of the chunk to forget.

ParametersJSON Schema
NameRequiredDescriptionDefault
chunk_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/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 behavioral burden and does well: it discloses that the chunk is removed from search results, persists in the database, has importance set to 0, and gets marked in metadata. This goes well beyond a generic 'delete' statement.

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?

The description is compact and well-structured, with the key action front-loaded and each subsequent sentence adding meaningful detail. The Args block is clean and immediately useful.

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 one-parameter tool with an output schema present, the description is complete: it explains the operation, its effects, and the only input. No critical behavioral or usage detail is missing for correct invocation.

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 coverage is 0%, but the description fully compensates by defining chunk_id as 'The UUID of the chunk to forget.' This adds meaning beyond the schema's bare type and title.

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 opens with a specific verb and resource: 'Soft-delete a memory chunk by ID.' The soft-delete framing clearly distinguishes it from the sibling tool purge_forgotten, which implies permanent deletion.

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

Usage Guidelines3/5

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

The description implies when to use this tool by explaining the soft-delete behavior: the chunk is removed from search results but remains recoverable. However, it does not explicitly name alternatives or state when not to use it, so the usage guidance is inferred rather than direct.

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

memory_statusA

Get the current status of the memory system.

Returns database health, chunk counts per space, and embedding model info.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. 'Get' and 'Returns' clearly imply a read-only, non-destructive operation, and the listed return categories describe observable behavior. It does not discuss auth or side effects, but for a zero-parameter status endpoint this is a minor gap.

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?

The description is only two short sentences, with the primary action front-loaded and the return payload summarized immediately. Every sentence adds useful information and there is no filler or redundancy.

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 no-argument introspection tool with an output schema, the description covers the purpose and the categories of returned data. An agent has everything needed to select and invoke it correctly.

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?

The tool has zero parameters, so the baseline is 4 and no parameter-level documentation is needed. The description adds no parameter semantics, but none are required.

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 uses the specific verb 'Get' with a clear resource ('current status of the memory system') and enumerates exactly what is returned (database health, chunk counts, embedding model info). This clearly differentiates it from the mutation-oriented sibling tools recall/remember/forget/purge_forgotten/move_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?

The intended use is obvious: call this when you need the memory system's current health and statistics. It does not explicitly name alternatives or when-not-to-use conditions, but the sibling tools are all memory operations, so the context makes the choice unambiguous.

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

move_memoryA

Move a stored memory into a different space.

The memory keeps its content and embedding; only the space it belongs to changes. Its knowledge-graph entries are rebuilt in the target space so the graph and search agree about where it lives.

The target space must already exist — use the dashboard or the API to create one first.

Args: chunk_id: The UUID of the chunk to move. target_space: Name of the space to move it into.

ParametersJSON Schema
NameRequiredDescriptionDefault
chunk_idYes
target_spaceYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the memory retains its content and embedding, that only its space membership changes, and that knowledge-graph entries are rebuilt in the target space so graph and search agree. This reveals important side effects beyond the tool name.

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?

The description is tight and well-structured: purpose, behavioral effect, prerequisite, then arguments. Every sentence earns its place, and no redundant or vague filler is present.

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 two-parameter mutation tool with an output schema, the description covers the operation, side effects, prerequisites, and parameter meanings. Nothing critical is missing, and return-value details are handled by the output schema.

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 coverage is 0%, so the Args section must compensate. It does: chunk_id is defined as the UUID of the chunk to move, and target_space is defined as the name of the destination space. This adds real meaning beyond the bare schema titles.

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 opens with a specific verb and resource: 'Move a stored memory into a different space.' It clarifies what changes (space) and what stays the same (content and embedding), making the tool's purpose distinct from siblings like recall, remember, and forget.

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 clearly states the use case and an important prerequisite: the target space must already exist, and it points the user to the dashboard or API to create one. It does not explicitly call out alternatives or when-not-to-use scenarios, but the usage context is unambiguous.

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

purge_forgottenA

Permanently delete memories that were forgotten a while ago.

forget is a soft delete: the memory stops appearing in search but the row stays, so it can be recovered. Nothing removed it afterwards, so a vault that is edited often accumulated one dead row per edit forever.

This is the deliberate, irreversible half. It is never automatic — there is no timer that quietly deletes your memories — and it only touches memories already marked forgotten, never active ones.

Args: older_than_days: Only purge memories forgotten at least this many days ago. The default keeps a month of recovery, so purging right after an accidental forget still spares it. Pass 0 to purge every forgotten memory regardless of age.

ParametersJSON Schema
NameRequiredDescriptionDefault
older_than_daysNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It states the operation is permanent and irreversible, explains that it is never automatic, and reassures that it only touches forgotten memories. It also includes the default retention period as a safety behavior, which is valuable context for an agent deciding to invoke a destructive operation.

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?

The description is front-loaded with the primary action and then uses compact paragraphs for contrast, safety guarantees, and parameter semantics. Each sentence earns its place: even the 'dead row' background explains why the tool exists and supports the usage decision. It is detailed without being bloated.

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 destructive one-parameter tool with an output schema present, the description is complete. It covers what the tool does, when to use it, how the parameter behaves, the safety default, and the boundary conditions. No essential information for invoking it correctly is missing.

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 coverage is 0%, so the description is the only source of parameter meaning. It fully explains `older_than_days`: only forgotten memories at least that many days old are purged, the default preserves a month of recovery, and passing 0 purges all forgotten memories regardless of age. This is exactly the semantic detail the schema lacks.

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 opens with a specific verb and resource: 'Permanently delete memories that were forgotten a while ago.' It clearly distinguishes itself from `forget`, which it explicitly identifies as a soft delete, and marks this tool as the irreversible counterpart. An agent can tell exactly what this tool does and how it differs from siblings.

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?

The description explicitly contrasts with `forget`, explaining that `forget` keeps the row for recovery while this tool is the 'deliberate, irreversible half.' It also clarifies when it is appropriate: only for memories already marked forgotten, never active ones, and never automatically. This gives an agent clear guidance on when to choose this tool over alternatives.

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

recallA

Search your memories for information relevant to a query.

Returns chunks ranked by relevance using hybrid search (vector + full-text + RRF). Uses query enrichment (keyword extraction + variation) for better recall. Results are budgeted to fit within max_tokens to avoid flooding context.

Args: query: The search query — a question, topic, or keyword phrase. spaces: Filter to specific memory spaces (e.g. ["default", "projects"]). If omitted, searches all spaces. since: Only return memories after this date (ISO format, e.g. "2025-01-01"). limit: Maximum number of results (default 10, max 50). max_tokens: Token budget for results (default 2000). ef_search: How much of the vector index to search, 1-1000. Omit to use the default (40). Raise it when a search should have found something and did not — better recall, slower query. Worth trying before concluding a memory is missing.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
sinceNo
spacesNo
ef_searchNo
max_tokensNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden, and it delivers: it explains hybrid search (vector + full-text + RRF), query enrichment, relevance ranking, token budgeting to avoid context flooding, and the trade-off of raising ef_search. This gives the agent a strong model of what happens when the tool is invoked.

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?

The description is well organized with a brief behavioral overview followed by a clear Args list. Every sentence adds useful information, and the ef_search guidance is valuable rather than filler. The structure is front-loaded and scannable.

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?

Given six parameters, no annotations, and no inline schema descriptions, the description covers all necessary invocation details: defaults, formats, filtering, and tuning behavior. The output schema exists, so not detailing return values is acceptable. The description is complete enough for an agent to call the tool correctly.

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 coverage is 0%, so the description must document every parameter, and it does. It explains query, spaces, since with ISO example, limit and max_tokens with defaults, and ef_search with a concrete tuning recommendation. This fully compensates for the absent 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?

The description opens with 'Search your memories for information relevant to a query,' which clearly states a specific verb, resource, and intent. The sibling tools are all memory management operations (remember, forget, move), so this retrieval-focused description immediately distinguishes recall from them.

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

Usage Guidelines3/5

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

The description makes clear this tool is for searching and retrieving memory, and it gives specific guidance on when to increase ef_search. However, it does not explicitly state when to use this tool instead of the sibling tools, nor does it mention alternatives or exclusions. Usage context is implied rather than spelled out.

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

rememberA

Store a new memory in the system.

The text is embedded and stored as a searchable chunk. Use this to save important information, decisions, or knowledge.

Args: text: The text content to remember. space: Which memory space to store it in (default "default"). source: Where this memory comes from (default "mcp"). speaker: Who said/wrote this — "human" or "assistant" (default "human").

ParametersJSON Schema
NameRequiredDescriptionDefault
textYes
spaceNodefault
sourceNomcp
speakerNohuman

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful detail by saying 'The text is embedded and stored as a searchable chunk,' which explains the storage behavior beyond a bare 'store' verb. However, it does not mention potential side effects, failure conditions, deduplication behavior, or what happens after storage, leaving some uncertainty for a mutation tool.

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 moderately concise and front-loaded with the primary purpose. The Args section is compact and necessary given the schema's lack of descriptions. The sentence 'Use this to save important information...' is slightly redundant with the opening line but does not meaningfully hurt 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?

The description covers the tool's purpose, storage behavior, and all parameter meanings, and an output schema exists so return-value details are not required. It does not enumerate valid memory spaces or relate this tool explicitly to recall, forget, and other siblings, but for a straightforward write operation it is sufficiently complete.

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?

The input schema has 0% description coverage, so the description must fully document parameters. It does so clearly, defining text, space, source, and speaker, including all defaults and the allowed speaker values ('human' or 'assistant'). This fully compensates for the bare 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?

The description opens with 'Store a new memory in the system,' naming a specific verb and resource. It clearly distinguishes this as the write operation among siblings like recall and forget, and adds 'Use this to save important information, decisions, or knowledge' to reinforce the intended use.

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 provides clear usage context: 'Use this to save important information, decisions, or knowledge.' It does not explicitly name alternatives or state when not to use the tool, but the sibling set is intuitive enough that an agent can infer this is the right tool for storing rather than retrieving or deleting memories.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv0.1.0
    • First observedforget
    • First observedmemory_status
    • First observedmove_memory
    • First observedpurge_forgotten
    • First observedrecall
    • First observedremember

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: recall for searching, remember for storing, forget for soft-deleting, purge_forgotten for permanent cleanup, move_memory for relocating, and memory_status for health checks. There is no meaningful overlap or ambiguity between any pair of tools.

Naming Consistency4/5

Most tool names follow a verb-first pattern (recall, remember, forget, purge_forgotten, move_memory), which is predictable and readable. memory_status breaks the pattern slightly by being noun-first, but the naming is still clear and consistent in style overall.

Tool Count5/5

Six tools is a well-scoped size for a memory vault server, covering querying, writing, deletion, recovery/cleanup, organization, and monitoring without redundancy. Each tool earns its place and there is no sense of bloat or thinness.

Completeness4/5

The core memory lifecycle is well covered: store, search, soft-delete, permanent purge, move between spaces, and inspect status. Minor gaps exist, such as updating or editing an existing memory's content and creating spaces directly through the server, but these are workable limitations rather than fatal dead ends.

Maintenance

ActivityActive
ResponsivenessResponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    An MCP server that provides persistent memory capabilities for Claude, offering tiered memory architecture with semantic search, memory consolidation, and integration with the Claude desktop application.
    38
    68
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    An MCP server that provides Claude agents with a comprehensive memory management system for storing and retrieving episodic, semantic, and procedural knowledge. It enables working memory persistence, knowledge graph integration, and interaction stream capture to enhance agent learning and context retrieval.
    382
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    MCP server providing persistent, searchable memory management for AI workflows, enabling Claude Code to store, retrieve, and organize context through CRUD operations and knowledge tools.
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that gives Claude persistent memory by storing conversation context, entities, and enabling semantic search across sessions.
    18
    1
    MIT

Latest Blog Posts

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/MihaiBuilds/memory-vault'

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