← Back to directory
M

Memora

Community
Persistent, collective memory for your AI agents
Category
Other #71 of 230
Stars
★ 742 Very popular
Transport
stdio (local process) · SSE · Streamable HTTP
Runtime
Python
Credentials
Optional API key
License
MIT
Last commit
Tools
31
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.

Strongest · Documentation 14/20 Weakest · Security and permissions 11/20

Reliability
12/20
Security and permissions
11/20
Maintenance
11/20
Documentation
14/20
Setup experience
12/20
Why each score
Reliability 12/20
The README describes a coherent main path (pip install memora-mcp, memora-server entry point, stdio/HTTP transports, startup tool-profile attestation, health endpoints) and honestly enumerates several failure modes (OpenRouter lacking an embeddings endpoint causing silent TF-IDF fallback after 404s, D1 single-response racing the 30s ceiling, container IP reassignment causing silent MCP hangs, and the LaunchAgent supervising the proxy rather than the container). That candor is genuine diagnosability evidence. However, all of it is prose: no CI workflows and no committed test files are present as verifiable execution evidence, and the server manifest is not cached. Under the static calibration cap, reliability cannot exceed 12 (happy path plausible, tests/edge cases thin); popularity adds nothing.
Security and permissions 11/20
The README shows deliberate credential and privilege design: credentials never enter the image, instance file, or client HTTP config, but are injected at runtime from a separate credential file with a chmod 600 recommendation; MEMORA_HEALTH_TOKEN gates detailed health bodies while non-loopback peers get aggregate status; an unknown MEMORA_TOOL_PROFILE aborts startup (fail closed) so destructive maintenance tools (memory_rebuild_embeddings, memory_delete_batch) are not re-exposed to workers; MEMORA_DATABASES validates names, returns 404 for unknown databases without listing others, and sticks a session to one DB. Deductions: the guided examples have users place real OPENAI_API_KEY/CLOUDFLARE_API_TOKEN values into .mcp.json and ~/.config/memora/credentials.mcp.json (placeholders are used, but the pattern is normalized); no explicit confirmation is documented for memory_delete/merge/batch-delete destructive operations; the HTTP transport can be rebound via --host, and the README itself states FastMCP custom_route() health endpoints are unauthenticated even when MCP auth is configured. No red-line condition is met, so it does not fall into the 0-4 band.
Maintenance 11/20
Positive signals: MIT license, 719 stars, only 2 open issues, a version badge and releases link, an Awesome Claude Code mention, and README text citing concrete issue numbers (e.g. #973) with behavioral consequences, indicating active release/versioning discipline. But the static material contains no actual commit history, release dates, CI status, dependency-update records, or a stated security-response channel; ownership is only the organization name agentic-box with no governance/maintainer info; and the MCP SDK is hard-pinned to mcp>=1.27,<1.28 with a required test re-run on bump, a real versioning-coupling risk. These governance and evidence gaps keep it mid-range.
Documentation 14/20
Documentation is the project's strongest dimension: layered structure (Features/Install/Configuration/env-var table/tool profiles/multi-DB routing/containers/embeddings/graph/chat/dedup/document storage/insights/linking/Neovim), per-variable defaults, caps, invalid-value behavior, and scope (streamable-http only), plus copyable configs, a worked example (OpenRouter LLM + Cloudflare Workers AI embeddings), and explicit trap explanations (OpenRouter has no embeddings endpoint leading to silent TF-IDF degradation, mandatory embedding/crossref rebuild after fingerprint change, container IP movement requiring the proxy). Limitations are disclosed (D1 paging is mitigation not fix; container runtime needs macOS 26 + Apple silicon). Deductions: sections are verbose and laced with internal incident narrative, there is no minimal end-to-end example, tool-profile docs give counts and membership but not per-tool parameter schemas, no cost discussion, and troubleshooting is scattered rather than a dedicated section.
Setup experience 12/20
The pip path is genuinely short: pip install memora-mcp, then a memora-server command entry in the client config. The container path is markedly complex: it requires Apple's container CLI, macOS 26, and Apple silicon; manual creation of three ~/.config/memora directories, copying the proxy script, hand-writing a credentials JSON with chmod 600, authoring an instance file, then build/up/proxy plus manually running the printed launchctl commands. The README admits nothing creates those paths on a fresh clone and that the LaunchAgent supervises the proxy, not the container (after a host restart the listener can return while the upstream is stopped). Manual, platform-restricted, fragile setup combined with the absence of executable CI/test evidence keeps this below the 15 cap, hence 12.

Static review · not runListed 2026-09-10

Read the FMRS scoring method →

Fit and risk

What it can accessUses the networkConnects to a database

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

Setup

Before you start

Runtime:Python

CLOUDFLARE_API_TOKEN optionalsecret API token for Cloudflare D1, created in the Cloudflare dashboard; CF_API_TOKEN accepted as alias.
MEMORA_HEALTH_TOKEN optionalsecret Bearer token for detailed /health/db bodies; choose your own value.
MEMORA_EMBEDDING_API_KEY optionalsecret Embedding provider API key; must be set together with MEMORA_EMBEDDING_BASE_URL.
OPENAI_API_KEY optionalsecret OpenAI-compatible key for the LLM (dedup/chat); used for embeddings only if both MEMORA_EMBEDDING_* are unset.
Other optional settings (43)
MEMORA_DB_PATH optional Local SQLite database path, default ~/.local/share/memora/memories.db.
MEMORA_STORAGE_URI optional Cloud storage URI (d1:// or s3://), used when MEMORA_DATABASES is unset.
MEMORA_DATABASES optional JSON registry of {name: uri} for multi-database routing (streamable-http only).
MEMORA_DEFAULT_DB optional Registry database name bound to a bare /mcp path.
MEMORA_CLOUD_ENCRYPT optional Encrypt local file before uploading to S3/R2 (true/1/yes).
MEMORA_CLOUD_COMPRESS optional Compress local file before uploading to S3/R2.
MEMORA_CACHE_DIR optional Local cache directory for an S3/R2-synced database.
MEMORA_ALLOW_ANY_TAG optional Set to 1 to allow any tag without allowlist validation.
MEMORA_TAG_FILE optional Path to a JSON file containing the allowed tags array.
MEMORA_TAGS optional Comma-separated list of allowed tags.
MEMORA_HOST optional Bind address for HTTP transports, default 127.0.0.1.
MEMORA_PORT optional Bind port for HTTP transports, default 8000.
MEMORA_GRAPH_PORT optional Knowledge graph visualization server port, default 8765.
MEMORA_TRANSPORT optional Transport: stdio (default), sse, or streamable-http.
MEMORA_TOOL_PROFILE optional Tool subset exposed: full (43), leader (19), or agent (12).
MEMORA_MAX_SESSIONS optional Hard ceiling on concurrent MCP sessions, default 128, 0 disables.
MEMORA_MAX_INIT_PER_MIN optional New sessions admitted per minute, default 120, 0 disables.
MEMORA_MAX_INIT_BODY_BYTES optional Max initialize request body size, default 65536.
MEMORA_SESSION_IDLE_TIMEOUT optional Seconds before an idle session is reaped, default 1800, 0 disables.
MEMORA_HEALTH_TTL optional Seconds a readiness snapshot may be served before refresh, default 10.
MEMORA_HEALTH_TIMEOUT optional Bound on one refresh pass and each store probe, default 15.
MEMORA_HEALTH_REFRESH_INTERVAL optional How often the server refreshes readiness on its own, 0 = poll-only.
MEMORA_HEALTH_MAX_STALE optional Age after which a cached result may not be reported ready, default 60.
MEMORA_STALE_DAYS optional Days before a TODO/issue is stale; insights default 14, graph UI default 30.
MEMORA_EMBEDDING_MODEL optional Embedding backend: openai (default), sentence-transformers, or tfidf.
SENTENCE_TRANSFORMERS_MODEL optional sentence-transformers model, default all-MiniLM-L6-v2.
MEMORA_EMBEDDING_BASE_URL optional Embedding provider base URL; must be set together with MEMORA_EMBEDDING_API_KEY.
MEMORA_EMBEDDING_STRICT optional Recommended set to 1: fail hard on embedding errors instead of silent TF-IDF fallback.
OPENAI_BASE_URL optional OpenAI-compatible LLM base URL (e.g. OpenRouter).
OPENAI_EMBEDDING_MODEL optional Model ID for the openai embedding backend; must exist on the embedding host.
MEMORA_LLM_ENABLED optional Enable LLM-powered dedup comparison, default true.
MEMORA_LLM_MODEL optional Dedup comparison model, default gpt-4o-mini.
MEMORA_LLM_TIMEOUT optional Seconds the OpenAI client waits, default 60.
MEMORA_REWRITE_MODEL optional RAG query rewrite model for the graph chat panel; falls back to MEMORA_LLM_MODEL.
MEMORA_VECTOR_SCAN_PAGE_SIZE optional Rows per page when loading embeddings from D1; use 100 on D1.
CHAT_MODEL optional Local graph chat panel model; falls back to MEMORA_LLM_MODEL.
MEMORA_CLOUD_GRAPH_ENABLED optional Set true/1/yes to notify the hosted graph on writes.
MEMORA_CLOUD_GRAPH_WORKER_URL optional Worker base URL for write broadcasts.
MEMORA_CLOUD_GRAPH_DEBOUNCE optional Seconds to batch rapid writes before broadcasting, default 1.0.
MEMORA_CLOUD_GRAPH_SYNC_SCRIPT optional Sync script path captured at startup.
AWS_PROFILE optional AWS credentials profile from ~/.aws/credentials (useful for R2).
AWS_ENDPOINT_URL optional S3-compatible endpoint for R2/MinIO.
R2_PUBLIC_DOMAIN optional Public domain for R2 image URLs.

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.

.mcp.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"}}}}

Shown for Claude Code. Other clients may use a different file or key (VS Code uses "servers") — the configurator below converts it.

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

Goes in your project's .vscode/mcp.json (VS Code uses a "servers" key).

Terminal
claude mcp add memora -e 'MEMORA_DB_PATH=~/.local/share/memora/memories.db' -e MEMORA_ALLOW_ANY_TAG=1 -e MEMORA_GRAPH_PORT=8765 -- memora-server

Run it in a terminal; replace any <…> placeholders with your own values first.

Check that it works

After installing memora-mcp and configuring memora-server in your client, tools like memory_absorb and memory_semantic_search should appear in the tool list; calling memory_stats and getting a database field plus memory counts confirms the connection works.

Troubleshooting

  1. 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
  2. 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
  3. Retrieval breaks after changing embedding model, endpoint, or dimensions: run memory_rebuild_embeddings and then memory_rebuild_crossrefs
  4. absorb times out on D1: lower MEMORA_VECTOR_SCAN_PAGE_SIZE (the docs recommend 100 on D1)
  5. 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
  6. 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
  7. Fewer tools than expected: check MEMORA_TOOL_PROFILE — full exposes all 43 tools, leader 19, agent 12
  8. HTTP deployment health checks: GET /health is liveness, GET /health/db aggregates stores, GET /health/db/{name} probes a single store

Things to try

Once connected, you can ask your AI assistant things like:

  • Absorb the confirmed facts from this session into memory with memory_absorb, using dry_run first to preview
  • Use memory_digest to pull up what we know about the login flow, including open TODOs and issues
  • Semantically search memories related to the database migration and show the top matches
  • Run memory_stats to show which database this session is bound to and how many memories are stored

Tools 31

memory_absorb writes
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 read-only
Bundle relevant memories, open TODOs/issues, related edges, and source IDs for a given topic into one retrieval
memory_create writes
Create a memory (embeddings and cross-references are computed automatically)
memory_update writes
Update a memory
memory_delete destructive
Delete a memory; deleting a document fragment requires force=True
memory_delete_batch destructive
Delete memories in batch
memory_get read-only
Fetch a single memory by ID
memory_list read-only
List memories
Show 23 more tools
memory_list_compact read-only
List memories in a compact form
memory_semantic_search read-only
Vector semantic search over memories
memory_hybrid_search read-only
Hybrid full-text and vector search
memory_related read-only
Find memories related to a given one
memory_link writes
Create a typed edge between memories (references, implements, supersedes, extends, contradicts, related_to)
memory_unlink writes
Remove a link between two memories
memory_boost writes
Boost a memory's importance for ranking
memory_clusters read-only
Detect clusters of related memories
memory_stats read-only
Return statistics, including the database this session is bound to and its database_source
memory_tags read-only
List tags
memory_create_todo writes
Create a TODO with status and priority
memory_create_issue writes
Create an issue with severity and component
memory_create_section writes
Create a section placeholder node (hidden from the graph)
memory_store_document writes
Store a markdown document, auto-parsed into typed fragments (claim, plan_item, reference, section_chunk, risk)
memory_get_document read-only
Retrieve the full document or specific fragment kinds by document_key
memory_delete_document destructive
Delete a document and all its fragments
memory_find_duplicates read-only
Find potential duplicate memories using cross-references plus optional LLM analysis
memory_merge writes
Merge duplicate memories with append, prepend, or replace strategies; refuses to merge document fragments
memory_detect_supersessions read-only
Detect supersession relationships between memories
memory_rebuild_embeddings writes
Rebuild all embeddings after a change of embedding model, endpoint, model id, or vector dimensions
memory_rebuild_crossrefs writes
Rebuild cross-references to update the knowledge graph
memory_insights read-only
Return an activity summary, open items with stale detection, consolidation candidates, and optional LLM pattern analysis
memory_export_graph writes
Export memories as a static HTML graph file for offline viewing

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 Code
Codex
NeovimPartial support

Listed from the project's documentation, not tested by this site.

Overview

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>).

Similar servers

BioMCP 75 · B

One binary. One grammar. Evidence from the biomedical sources you already trust.

★ 659 · Tools 11 Compare with this →

Source revision c5624e8303f0 Data synced 2026-10-19 Read the FMRS scoring method