Memora

Community

Persistent, collective memory for your AI agents

★ 719 Stars Category · Other Very popular

60FMRS · C

Memora is a community-maintained (MIT licensed, not vendor-official) MCP memory layer that turns cross-session agent memory into searchable, traceable, visualizable graph data. Its differentiators are absorb's LLM-classified writes with supersession lineage — updates add a version and retrieval follows the chain rather than overwriting — plus memory_digest's topic-level retrieval, structured document fragment storage, and the built-in graph UI. The cost is configuration surface: embeddings and the LLM are two separately configurable providers with a rejected partial split and a silent-degradation trap when the endpoint is wrong, and container deployment adds a long-running proxy and LaunchAgent. It suits teams willing to configure keys and endpoints themselves and who genuinely need cross-session memory; it is not for those wanting zero configuration or vendor support.

Reliability

12/20

Security and permissions

11/20

Maintenance

11/20

Documentation

14/20

Setup experience

12/20

Read the FMRS scoring method →

Memora is an MCP memory layer for AI agents: structured storage, semantic retrieval, graph relations, and source-backed cross-session context. It stores memories in SQLite with optional cloud sync (S3, R2, Cloudflare D1). Core capabilities include absorb (an LLM classifies each incoming fact against the store as duplicate / update / contradiction / related / new, skips duplicates, links relations, and consolidates related facts), supersession lineage (updates supersede old knowledge instead of deleting it, and retrieval follows the chain to the current version by default), memory_digest(topic) (bundles relevant memories, open TODOs/issues, related edges, and source IDs into one retrieval), semantic search over vector embeddings (TF-IDF, sentence-transformers, or OpenAI backends), LLM-powered deduplication, typed memory linking, structured document storage as searchable fragment trees, an interactive knowledge graph with a built-in live graph server and an optional Cloudflare Pages hosted graph, a RAG-powered chat panel with LLM tool calling, event notifications, statistics and insights, and action history. One process can serve multiple workspaces through the MEMORA_DATABASES registry, with clients selecting a store by URL path (/mcp/<name>).

Tools

memory_absorb

Feed facts in; an LLM classifies each against the store (duplicate/update/contradiction/related/new), skips duplicates, links relations, and consolidates related facts, with a dry_run preview

memory_digest

Bundle relevant memories, open TODOs/issues, related edges, and source IDs for a given topic into one retrieval

memory_create

Create a memory (embeddings and cross-references are computed automatically)

memory_update

Update a memory

memory_delete

Delete a memory; deleting a document fragment requires force=True

memory_delete_batch

Delete memories in batch

memory_get

Fetch a single memory by ID

memory_list

List memories

memory_list_compact

List memories in a compact form

memory_semantic_search

Vector semantic search over memories

memory_hybrid_search

Hybrid full-text and vector search

memory_related

Find memories related to a given one

memory_link

Create a typed edge between memories (references, implements, supersedes, extends, contradicts, related_to)

memory_unlink

Remove a link between two memories

memory_boost

Boost a memory's importance for ranking

memory_clusters

Detect clusters of related memories

memory_stats

Return statistics, including the database this session is bound to and its database_source

memory_tags

List tags

memory_create_todo

Create a TODO with status and priority

memory_create_issue

Create an issue with severity and component

memory_create_section

Create a section placeholder node (hidden from the graph)

memory_store_document

Store a markdown document, auto-parsed into typed fragments (claim, plan_item, reference, section_chunk, risk)

memory_get_document

Retrieve the full document or specific fragment kinds by document_key

memory_delete_document

Delete a document and all its fragments

memory_find_duplicates

Find potential duplicate memories using cross-references plus optional LLM analysis

memory_merge

Merge duplicate memories with append, prepend, or replace strategies; refuses to merge document fragments

memory_detect_supersessions

Detect supersession relationships between memories

memory_rebuild_embeddings

Rebuild all embeddings after a change of embedding model, endpoint, model id, or vector dimensions

memory_rebuild_crossrefs

Rebuild cross-references to update the knowledge graph

memory_insights

Return an activity summary, open items with stale detection, consolidation candidates, and optional LLM pattern analysis

memory_export_graph

Export memories as a static HTML graph file for offline viewing

Setup

Path 1 (pip, local stdio): 1) Run pip install memora-mcp (the PyPI package is memora-mcp; bare memora on PyPI is an unrelated project); for offline local embeddings, pip install "memora-mcp[local]" (~2GB for PyTorch). 2) Add "command": "memora-server" to .mcp.json in your project root, setting MEMORA_DB_PATH, MEMORA_ALLOW_ANY_TAG, MEMORA_GRAPH_PORT and other env vars as needed. 3) Restart your client.
Path 2 (container, HTTP service): the default runtime is Apple's container CLI, which needs Apple silicon and macOS 26. Run container system start; git clone the repo and cd into it; cp instances/example.env instances/myinstance.env and edit PORT plus a backend (STORAGE_URI, VOLUME, or MEMORA_DATABASES); create ~/.config/memora/credentials.mcp.json (an alternative path can be set via CRED_SOURCE) and chmod 600 it; copy scripts/memora_proxy.py to ~/.local/libexec/memora/; then run ./scripts/memora-instance.sh build myinstance, up myinstance, proxy myinstance and run the launchctl commands it prints. The workspace URL is http://127.0.0.1:<PORT>/mcp (append /<name> for a non-default store).
For Codex CLI, add an [mcp_servers.memora] section to ~/.codex/config.toml with command and env.

claude_desktop_config.json

{"mcpServers":{"memora":{"command":"memora-server","args":[],"env":{"MEMORA_DB_PATH":"~/.local/share/memora/memories.db","MEMORA_ALLOW_ANY_TAG":"1","MEMORA_GRAPH_PORT":"8765"}}}}

Generate and validate client config

Fit and risk

Best for

Development teams using Claude Code, Codex CLI, or other MCP clients that need cross-session memory
Users who want to self-host SQLite or sync to Cloudflare D1/R2
Long-term memory use cases that need supersession lineage and deduplication rather than append-only text
Advanced users willing to configure embedding and LLM providers themselves (OpenAI, OpenRouter, Cloudflare Workers AI, etc.)

Not for

Users who want a zero-configuration setup — embeddings and the LLM require your own keys and endpoints
One-off question-answering tasks that do not need persistent memory
Environments that cannot absorb the operational cost of a long-running container or a LaunchAgent-managed proxy
Users expecting vendor support or an SLA — the project is community-maintained

Required permissions

Local file access: creates and reads/writes a SQLite database file (default ~/.local/share/memora/memories.db) and a cache directory
Network access: calls the configured embedding endpoint and LLM endpoint (OpenAI, OpenRouter, Cloudflare Workers AI, etc.)
Cloud storage credentials: AWS_PROFILE and AWS_ENDPOINT_URL for S3/R2 sync, or CLOUDFLARE_API_TOKEN for D1
Local port binding: the graph server listens on 127.0.0.1:8765 by default; HTTP transport defaults to 127.0.0.1:8000
Container deployment requires running Apple's container CLI and installing a LaunchAgent-managed local proxy process

Risks and side effects

If the embedding endpoint is misconfigured (for example pointed at OpenRouter), Memora silently falls back to TF-IDF keyword bags unless MEMORA_EMBEDDING_STRICT=1 is set, degrading vector quality while looking healthy
A wrong store name in MEMORA_DATABASES is undetectable by errors: reads succeed but writes land in another project's store; verify with the database field from memory_stats
Credentials are injected into the process via environment variables; an over-permissive credential file may be readable by other local accounts (the docs recommend chmod 600)
Memory content is sent to the configured embedding and LLM providers, which matters for sensitive data
The container runtime reassigns the container's IP on every start; connecting directly instead of through the proxy produces a permanent silent hang
LLM deduplication and absorb can merge or supersede memories; lineage is preserved, but wrong judgments still affect retrieval results
Document fragments are protected by integrity guards, but deleting the whole document deletes every fragment with it

Troubleshooting

Writes appear to succeed but searches come back empty: call memory_stats first and confirm the session's bound database is the workspace store you intended
Semantic search behaves like keyword matching: check that MEMORA_EMBEDDING_STRICT=1 is set and that MEMORA_EMBEDDING_BASE_URL actually points at an embeddings endpoint
Retrieval breaks after changing embedding model, endpoint, or dimensions: run memory_rebuild_embeddings and then memory_rebuild_crossrefs
absorb times out on D1: lower MEMORA_VECTOR_SCAN_PAGE_SIZE (the docs recommend 100 on D1)
The client starts but never answers: the container runtime reassigns IPs, so confirm you are connecting through the stable 127.0.0.1:<PORT> provided by scripts/memora_proxy.py
A store cannot be reached in a multi-database process: the name in /mcp/<name> must be a registry entry; unknown names return 404 unknown database
Fewer tools than expected: check MEMORA_TOOL_PROFILE — full exposes all 43 tools, leader 19, agent 12
HTTP deployment health checks: GET /health is liveness, GET /health/db aggregates stores, GET /health/db/{name} probes a single store

Use cases

Share one persistent project memory across multiple agent sessions so context is not re-explained

Use memory_absorb to turn agent output into graph memory with lineage

Retrieve a topic's relevant memories, open TODOs/issues, and source IDs in one call with memory_digest(topic)

Semantically search large historical memory stores for relevant conclusions

Store research reports, architecture decisions, and post-mortems as fragment trees that are searchable claim by claim

Explore the relationship graph, timeline, and action history in the built-in graph UI

Ask questions about the memory store from the RAG chat panel and let the model create, update, or delete memories

Supported clients

Claude CodeFull support

Codex CLIFull support

Neovim (Telescope)Partial support

Related MCP servers

Compare with other MCP servers