Engraphy › Compare › the MCP memory server

Engraphy vs the MCP memory server

Checked 24 August 2026 · Engraphy v0.1.0

The short answer

Engraphy exists because of this comparison. The reference memory server that ships with the Model Context Protocol keeps a knowledge graph in a flat JSON file, speaks stdio to a single local client, has no authentication, no semantic search and no de-duplication. It is a fine demonstration of the protocol and a fine scratchpad for one person on one machine.

It stops working the moment you have concurrency, paraphrase, more than one user, or a few years of accumulated memory. Engraphy is the same idea, a typed knowledge graph an agent reads and writes over MCP, built on Postgres so that those four things are handled rather than avoided.

At a glance

Capability	Engraphy	the MCP memory server
Store	Postgres 16 + pgvector, migrated and backed up like any database.	A flat JSON file on disk.
Transport	HTTP with a bearer token. Any MCP client, local or remote.	stdio to a single local process.
Concurrency	Postgres transactions.	Last writer wins on the file.
Search	Vector plus full-text, fused with reciprocal rank fusion, plus graph traversal.	Substring matching over the file.
Duplicate handling	Banded on write before the row exists: merge / merge-link / pending / new.	None. The same fact written twice is stored twice.
Paraphrase	Matched on meaning, so a restatement merges into what it repeats.	Not matched. A reworded fact is a new, unrelated entry.
Multiple users	Spaces and principals, separated by Postgres row-level security.	One user. There is no concept of a second one.
Authentication	Bearer tokens minted per client, with read-only or read-write roles.	None.
When a fact changes	Retired and linked by a `supersedes` edge.	You delete the old entry, or you keep both and live with the contradiction.
Schema	Typed nodes and edges with attribute schemas, enforced in Postgres.	Entities, relations and free-text observations, unvalidated.
Worst-case read	25 capped nodes.	The whole file.

Which one to choose

Choose the MCP memory server when

You want zero infrastructure. The reference server is a single command with no database, and for one person taking notes on one laptop that is genuinely the right answer.
You are learning MCP and want the smallest possible working example of a memory tool.
Your memory is small enough to read end to end, and always will be.
You want MIT-licensed reference code to copy.

Choose Engraphy when

More than one client writes to the store, or more than one person uses it.
The same fact keeps arriving in different words, and you want it recognised rather than duplicated.
The store has grown past what fits comfortably in a context window, so retrieval has to actually rank.
Facts change, and you need the old version kept and linked rather than deleted.
Something in the store is not yours to lose, so it needs transactions, backups and a real access model.

The four things that break first

In roughly this order, as a JSON-file memory grows:

Paraphrase. The agent writes “Devon prefers dark mode” in January and “Devon likes the dark theme” in March. Substring matching sees two unrelated facts. Engraphy embeds both and merges the second into the first.
Volume. Retrieval that reads the whole store stops fitting in a context window. Engraphy's worst-case read is 25 capped nodes, ranked by fused vector and lexical search.
Concurrency. Two clients writing the same file is data loss, not a race you can retry. Engraphy writes are Postgres transactions.
Other people. There is no second user in the reference server. Engraphy has spaces and principals, separated by row-level security under a NOBYPASSRLS role, so an agent cannot read another space's memory even if the application asks it to.

What migrating actually involves

Both are MCP servers exposing memory tools, so the client side of the change is pointing your MCP configuration at an HTTP URL with a bearer token instead of spawning a local process.

The real work is the shape. The reference server stores entities, relations and free-text observations with nothing validating them. Engraphy wants a pack: the node types, the edge types, the attribute schemas, and which edges may connect which types. Writing that pack is the migration, and it is also the point: once it exists, Postgres enforces it on every write, from every client, forever.

What Engraphy does not do

Stated plainly, so that nothing here has to be walked back:

A near-verbatim restatement can lose its text. If an incoming body overlaps the stored one at a Jaccard of 0.8 or above it is not added as an addendum, and the write returns addendum_added: false. Nothing is deleted, and not everything written is kept as new text.
Contradictions merge. A negation sits close in meaning to the fact it overturns, so it scores above the merge threshold and is absorbed, measured at 28 of 36 pairs in our own contradiction set. The merge result names what it merged into, so the caller can repair it with supersede. The engine will not guess, because agreement is a judgment call and no model runs inside the engine.
Time travel goes as far as supersession, not further. Facts are retired and linked rather than overwritten, so history is walkable. Full bi-temporal querying, asking what the store believed at an arbitrary past instant, is not built.
Ranking is reciprocal rank fusion today. The cross-encoder slot is specified and stays disabled until there is evidence it earns its cost.
It is v0.1.0, and it is self-hosted only. There is no managed Engraphy to sign up for. You run Postgres, or nothing runs.

Questions people ask

What is the MCP memory server?

It is the reference memory implementation that ships with the Model Context Protocol: a knowledge graph of entities, relations and observations kept in a flat JSON file, served over stdio to one local client. It has no authentication, no semantic search and no de-duplication, and it is meant as a demonstration rather than a production store.

Why replace the MCP memory server?

Because it does not survive paraphrase, volume, concurrency or a second user. A reworded fact is stored as a new unrelated entry, retrieval reads the whole file, two clients writing at once lose data, and there is no concept of a second person. Engraphy handles all four on Postgres.

Is Engraphy harder to run than the reference server?

Yes, and that is the trade. The reference server needs nothing; Engraphy needs Docker and a Postgres. One docker compose command brings up Postgres and pgvector, runs the migrations, provisions the app role and starts the server, but it is still a database you now operate.

Can I keep using my existing MCP client?

Yes. Engraphy speaks MCP over HTTP with a bearer token, so any MCP client, whether a VS Code extension, a desktop app or another agent, connects to it. The change is pointing your MCP configuration at a URL instead of spawning a local process.

Sources

Model Context Protocol servers: The reference memory server implementation.
Model Context Protocol: The protocol Engraphy speaks.

Try it against your own memory

Engraphy is a server you host. Point any MCP client at it. Embeddings run in-process, so there is no API key and no data leaves the box.

Install for VS Code Self-host quickstart Developer docs