AgensGraph knowledge-graph memory MCP server (entities, relations, observations).
Listed on its own since 2026-09-26. Until then it was part of mcp-agensgraph-common, where its earlier checks remain.
Wellknown found it in public sources; nobody has proven control of it yet. Claiming takes one click if the repository is under your GitHub account, or a small file on your domain otherwise. Verified owners get the badge, 15-minute checks, status alerts, edits that outrank crawled data, and a ranking boost.
Agents can do it too: POST https://wellknown.network/api/v1/claims with {"agent":"mcp-agensgraph-memory","method":"well_known_file"} — machine-readable steps at claim.json, guide at /docs/claim.
Everything here was measured by our prober or read from a registry. Nothing is self-reported.
Attributed to the source that supplied each field. Treated as claims, not facts.
# 🧠🕸️ AgensGraph Knowledge Graph Memory MCP Server ## 🌟 Overview A Model Context Protocol (MCP) server implementation that provides persistent memory capabilities through AgensGraph graph database integration. By storing information in a graph structure, this server maintains complex relationships between entities as memory nodes and enables long-term retention of knowledge that can be queried and analyzed across multiple conversations or sessions. The MCP server leverages AgensGraph's graph database capabilities to create an interconnected knowledge base that serves as an external memory system. Through Cypher queries, it allows exploration and retrieval of stored information, relationship analysis between different data points, and generation of insights from the accumulated knowledge. ### 🕸️ Graph Schema * `Memory` - a vertex label holding an entity's `name`, `type` and `observations`. A **unique** property index on `name` is what makes an entity's name identify one vertex, so two callers writing the same entity write one. * One edge label per relationship type, named by the type upper-cased — `WORKS_AT`, `LIVES_IN`. A type given in any other case names the same relationship. Each label carries a unique index on the pair of ends it joins, so one relationship of a type between two entities is one edge. * A GIN index over `to_tsvector('english', ...)` of the name, type and observations, which `search_memories` reads. It is built out of PostgreSQL's own functions; the server installs nothing in the database. All of these are made at startup and checked afterwards. Starting up over a store written before they existed merges entities that share a name (unioning their observations and keeping their relationships), moves relationships off a miscased type, collapses duplicate relationships onto the one written first, and rebuilds the full-text index. What it collapsed is written to the log. ## 📦 Components ### 🔧 Tools The server offers thes…
Mapped onto the structured taxonomy from declared text and observed tool names. Confidence shown for derived entries.
Every source is kept verbatim. Field changes are logged as events.