LongtermMemory-MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MEMORY_DB_PATH | No | Path to the SQLite memory database file. Defaults to ~/.longterm-memory-mcp/memories.db. Set this to isolate memories for a specific project. | |
| MEMORY_BACKUP_PATH | No | Path to the backups directory. Defaults to ~/.longterm-memory-mcp/backups/. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| save_memoryA | Save information to long-term memory. The content will be embedded locally and indexed for semantic search. Use this to store facts, decisions, preferences, or any context worth remembering across sessions. Text inside … is removed before storing; content that looks like a secret (tokens, keys, passwords) is rejected. |
| search_memoryA | Search long-term memory using semantic similarity. The query is embedded locally and compared against all stored memories using cosine similarity. |
| get_all_memoriesA | Retrieve all stored memories, ordered by most recent first. Results are paginated. |
| update_memoryA | Update an existing memory. Can modify content (triggers re-embedding), metadata, tags, importance, or memory type. |
| search_by_typeA | Search memories by category type (e.g. fact, preference, conversation). Returns memories ordered by importance. |
| search_by_tagsA | Find memories that match any of the provided tags. Returns memories ordered by importance. |
| search_by_date_rangeB | Find memories created within a specific date range. Use ISO date format. |
| delete_memoryA | Delete a specific memory by its ID. Only delete when the user explicitly requests it or when a memory is confirmed outdated or incorrect. |
| delete_all_memoriesA | Delete ALL stored memories. This action is irreversible. Only use when the user explicitly asks to clear all memories. |
| memory_statsA | Get statistics about the memory store — total count and database location. |
| create_backupA | Create a manual backup of the memory database and export all memories as JSON. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
The tools are mostly distinct: save/update/delete/backup/stats are clearly separate, and the search variants target semantic similarity, type, tags, and date range respectively. However, five retrieval-oriented tools (search_memory, get_all_memories, search_by_type, search_by_tags, search_by_date_range) create some choice ambiguity for an agent deciding how to fetch memories.
Most names follow a predictable snake_case verb_noun pattern (search_memory, save_memory, update_memory, delete_memory, create_backup). Minor deviations include memory_stats, which is a noun phrase rather than an action, and the search_by_* family, but the overall convention is readable and consistent.
With 11 tools, the set is well-scoped for a long-term memory server. Each tool covers a meaningful operation, and there is no excessive proliferation for the domain.
The surface covers core lifecycle operations: create, read/search, update, delete, bulk delete, stats, and backup/export. Minor gaps exist, such as no direct get-by-ID tool or restore/import operation, but agents can work around these using existing search and listing tools.