store_memoryLABSCO SUMMARY
One SQL query does the retrieval, and you own the database.
Fusing vector and keyword search by rank rather than by score avoids the usual problem of two systems whose numbers are not comparable, and it happens in a single Postgres query rather than a pipeline of rerankers. The design detail worth copying is confidence: reinforce_memory and contradict_memory adjust a score instead of deleting, so an assistant that learns something was wrong records that rather than losing the history. Refusing to store a git diff is a small thing that saves the memory from filling with noise.
What it is
A memory server backed by your own PostgreSQL with pgvector. Retrieval fuses vector similarity with full-text search in a single query, and a relationship graph over the memories lets a search follow edges rather than only rank rows. Memories are grouped into profiles, so work and personal context stay apart.
What you get
- Store what matters — store_memory runs the enrichment pipeline, store_decision records a decision with its rationale, alternatives and reasoning trace, linked to the memories that support it
- Content is validated before it lands: too short, too long, or recognisably a git diff or shell dump and it is refused with a suggestion to store a summary instead
- hybrid_search — semantic and keyword together, filterable by tags and source, and able to follow relationship edges when you set a graph depth
- explore_knowledge and find_related — seed a search then traverse several hops out, or trace impact from one specific memory
- list_recent for the chronological view
- Confidence rather than deletion — reinforce_memory raises a memory's score, contradict_memory lowers it, so being wrong is recorded rather than erased
- update_memory, which re-embeds when the content changes, and delete_memory
- Profiles — switch_profile, current_profile, list_profiles with their memory counts, and set_profile_ttl for auto-expiry
- Maintenance that keeps it from rotting — compress_old_memories in tiers while preserving the original, link_unlinked to backfill relationships, cleanup_expired, and re_embed_all after switching embedding provider
- export_profile as JSON or markdown and import_memories_tool with similarity-based deduplication
- health_check and get_cache_stats for the database, embedding provider and cache
- An append-only audit log of every store, search, update and delete, in the same database
Requirements
A PostgreSQL database with pgvector — a free Supabase project, a Neon database, or your own Postgres — and the schema migration run against it. Set SUPABASE_URL and SUPABASE_KEY for Supabase, or DATABASE_URL for a direct connection, in which case install the postgres extra so the driver is present. Run it with uvx --from ogham-mcp ogham-serve. Stdio by default; OGHAM_TRANSPORT, OGHAM_HOST and OGHAM_PORT switch it to streamable HTTP with a health endpoint. An embedding provider is needed for semantic search. The data is in a database you control, and nothing leaves it except what your client asks for.
Setup effort
One command plus a key — uvx --from ogham-mcp ogham init, then supply credentials
USE CASES
Keeping decisions your agents can find later
Store the decision with its rationale and alternatives, linked to what supports it.
Finding something you half remember
Search semantically and by keyword at once, and follow the relationship edges outward.
Working out what a change would affect
Traverse the relationship graph from the memory in question.
Something you recorded turned out to be wrong
Lower its confidence rather than deleting it, and store what is true now.
Keeping work and personal context apart
Switch profiles, and set a time-to-live on the one that should not accumulate forever.
Stopping the store from growing without limit
Compress the old memories, backfill missing links and clear what has expired.
Moving it, or changing embedding provider
Export the profile, or re-embed everything in place after switching providers.
38 tools
Listed in project docs. Your client may show a different list.
store_decisionstore_preferencestore_factstore_eventupdate_memorydelete_memoryreinforce_memorycontradict_memoryhybrid_searchlist_recentfind_relatedlink_unlinkedexplore_knowledgesuggest_connectionsstore_triplequery_joinimport_linearswitch_profilecurrent_profilelist_profilesset_profile_ttlexport_profileimport_memories_toolre_embed_allcompress_old_memoriescleanup_expiredhealth_checkget_configget_statsget_cache_statscompile_wikiquery_topic_summarywalk_knowledgelint_wikiimport_claude_code_memoriesimport_claude_ai_exportbackfill_entitiesBEFORE YOU INSTALL
What to know first
Tools you get
38 tools named in the project's documentation.
Requires
- A database: a Supabase project (SUPABASE_URL and SUPABASE_KEY) or Postgres with pgvector, such as Neon (DATABASE_BACKEND=postgres and DATABASE_URL)
- An embedding provider: local Ollama by default, or the API key for the provider you pick (OPENAI_API_KEY, MISTRAL_API_KEY, VOYAGE_API_KEY or GEMINI_API_KEY)
- Python 3.13+ with uv (uvx), or Docker
INSTALLATION
Connect your client
Server setup
uvx --from ogham-mcp ogham initMCP Clients
Claude Code
claude mcp add ogham -- uvx --from ogham-mcp ogham-serveOpenCode
{
"mcp": {
"ogham": {
"type": "local",
"command": [
"uvx",
"--from",
"ogham-mcp",
"ogham-serve"
],
"environment": {
"SUPABASE_URL": "https://<YOUR_PROJECT>.supabase.co",
"SUPABASE_KEY": "{env:SUPABASE_KEY}",
"EMBEDDING_PROVIDER": "openai",
"OPENAI_API_KEY": "{env:OPENAI_API_KEY}"
}
}
}
}Claude Desktop, Cursor, Codex, Kiro
{
"mcpServers": {
"ogham-mcp": {
"command": "uvx",
"args": [
"--from",
"ogham-mcp",
"ogham-serve"
],
"env": {
"DATABASE_URL": "<YOUR_DATABASE_URL>",
"EMBEDDING_PROVIDER": "ollama"
}
}
}
}<YOUR_DATABASE_URL> is your PostgreSQL connection string (postgresql://user:pass@host/db); also set DATABASE_BACKEND=postgres — the default backend is Supabase. Running uvx --from ogham-mcp ogham init first writes these to ~/.ogham/.env for you.
The configuration on this page does not set MISTRAL_API_KEY, VOYAGE_API_KEY and GEMINI_API_KEY; the project's instructions put them in a .env file. To supply them without depending on where the server looks for that file, use the block's "env" section.
Any MCP client — Docker
{
"mcpServers": {
"ogham-mcp": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--env",
"DATABASE_URL=<YOUR_DATABASE_URL>",
"ghcr.io/ogham-mcp/ogham-mcp:latest"
]
}
}
}DATABASE_URL=... is your PostgreSQL connection string (postgresql://user:pass@host/db); the README's Postgres setup also sets DATABASE_BACKEND=postgres, passed the same way with another --env.
Any MCP client — HTTP
{
"mcpServers": {
"ogham": {
"url": "http://127.0.0.1:8742/mcp"
}
}
}