Engraphy

An MCP server giving AI agents associative memory, modelled on the human mind.

Quickstart · Documentation · Tool reference · Design set · Contributing

The name comes from engraphy, an old term from memory science for the process of laying down an engram, the trace a memory leaves in the brain. Engraphy does that for agents: it checks each new memory against what it already knows before the write lands, merging restatements, linking genuinely new facts, and never silently overwriting. Nothing is deleted, so history stays walkable.

Engraphy is self-hosted. It stores what an agent learns as a typed knowledge graph on Postgres + pgvector: writes deduplicate themselves against existing memory, retrieval fuses semantic and lexical search, isolation between users is enforced by the database, and the whole shape of memory is declared per application as a pack.

It exists to replace the reference MCP memory server's flat-JSON, single-user, stdio model with something that survives concurrency, paraphrase, duplicates, and years of accumulated memory. It speaks the Model Context Protocol, so any MCP client (a VS Code extension, a desktop app, another agent) can use it over HTTP.

Source-available. Licensed under the Business Source License 1.1: read it, run it, build on it, and use it in production for your own product. Offering Engraphy itself as a hosted or managed service to third parties is reserved to the Licensor until the Change Date, when it converts to Apache-2.0. See License.

What it does

• A typed memory graph. Memories are typed nodes (fact, decision, person, event, …) joined by typed edges (involves, references, supersedes, …). The types, their attribute schemas, and the rules for which edges may connect which types are declared per space in a pack and enforced in Postgres.
• Writes that deduplicate themselves. Every write is embedded and banded against existing memory. A near-verbatim restatement auto-merges; a genuinely new but related fact is kept as its own searchable node and joined by an edge (nothing is silently absorbed); a borderline case parks as a pending duplicate-check verdict for the caller to resolve. Every write returns a resonance report of what it touched.
• Hybrid retrieval. search fuses a vector leg (cosine over embeddings) and a lexical leg (Postgres full-text) with Reciprocal Rank Fusion, and traverse walks the edges. Attribute values are folded into the searchable surface, so a fact stored only in a typed attribute is still findable.
• Isolation the database enforces. Multiple spaces, and multiple principals within a space, are separated by Postgres Row-Level Security running under a non-superuser role, not by application checks that can be forgotten. The server connects as a NOBYPASSRLS role.
• Scope routing built for LLMs. Every scope carries a description of what it governs; the read-only scope_guide tool returns that routing manifest so an agent can decide where a new memory belongs before it writes.
• An operator CLI and an MCP tool surface for everything from bootstrapping a space to minting tokens, importing data, applying packs, and verifying restores.

How it works

flowchart LR
    C[MCP client<br/>VS Code · desktop · agent] -->|HTTP + bearer token| S[Engraphy server<br/>FastMCP]
    S --> E[Embedding<br/>nomic-embed-text-v1.5]
    S --> DB[(Postgres 16 + pgvector<br/>nodes · edges · scopes<br/>RLS · schema enforcement)]
    P[Pack<br/>types · edges · briefing] -.declares.-> DB

A write is embedded, banded by similarity into merge / merge-link / pending / new, and committed under the caller's identity. A read (search, get, traverse, briefing) runs under RLS so a caller only ever sees the scopes they were granted. A pack declares the node types, edge types, attribute schemas, and session-start briefing for a space, so one engine serves many differently shaped memory applications. The architecture overview walks the full write and read paths.

Quickstart

Requirements: Docker (with Compose). The cloud profile brings up Postgres, runs migrations, provisions the app role, and starts the server in one command.

# 1. Configure secrets (never committed)
cp deploy/.env.example .env   # then edit, or:
printf 'POSTGRES_PASSWORD=%s\nENGRAPHY_APP_ROLE_PASSWORD=%s\n' \
  "$(openssl rand -hex 16)" "$(openssl rand -hex 16)" > .env

# 2. Bring up Postgres + migrate + provision + serve
docker compose up -d          # the embedding model ships baked into the image

# 3. Create a space, apply the starter pack, mint a client token
docker compose --profile admin run --rm admin \
  engraphy-admin space create --id personal --display-name "My Memory" --principal me
docker compose --profile admin run --rm admin \
  engraphy-admin pack apply packs/starter/pack.yaml --space personal
docker compose --profile admin run --rm admin \
  engraphy-admin token create --space personal --principal me \
    --client-name my-editor --role readwrite

The server is now on 127.0.0.1:8000 (put a TLS-terminating reverse proxy in front to expose it). Point any MCP client at it with the bearer token. The setup guide covers the local, no-Docker path as well.

Or let the scripts do it

up.sh and provision.sh (with up.ps1 / provision.ps1 as Windows equivalents) wrap exactly the sequence above, and add the waiting that a copy-paste quickstart cannot:

./up.sh          # writes .env with random passwords, starts the stack,
                 # then blocks until /healthz returns 200
./provision.sh   # creates the space, applies the starter pack, mints a token,
                 # and prints the client settings to paste in

up.sh polls /healthz rather than compose's health status, because on first boot compose reports starting for as long as the model cache takes to seed, which looks identical to a crash-loop from the outside. A 200 is the real signal.

Both scripts are safe to re-run: an existing .env is never overwritten, and an existing space or an already-applied pack is skipped rather than treated as an error, so a re-run still mints a fresh token.

Everything is parameterised, with defaults that work unchanged:

The token is printed once and never written to disk by the scripts; the server stores only its SHA-256. If you lose it, re-run provision.sh for a new one.

Using it from a client

Engraphy is an MCP server, so a client connects and calls tools:

See the tool reference for parameters, returns, and an example per tool. A first-party VS Code extension lives in vscode-extension/.

Documentation

• docs/: developer documentation, architecture, setup, packs, tool reference, deployment, and an end-to-end tutorial.
• design/: the design set, the data model, retrieval and dedup, auth and tenancy, operations, the pack/ontology system, and the benchmark harness. This is where the engineering reasoning lives.
• skills/: concise guidance an LLM agent can load to use Engraphy well (writing and dedup, retrieval, scopes and visibility, answer discipline).

Requirements