Local knowledge graph memory MCP server for AI assistants.
Model Context Protocol (MCP): io.github.nnar1o/kg-mcp
This MCP server provides a local knowledge graph memory for AI assistants. It stores persistent, structured, and editable project memory on the local machine. The repository states the project is in beta, with APIs subject to change and potential bugs.
🛠️ Key Features
Local knowledge graph memory for AI assistants
Persistent project memory
Structured memory representation
Editable project memory
Stored locally
🚀 Use Cases
Maintaining assistant context across sessions using a local knowledge graph
Representing and updating project information in structured form
Beta - APIs may still change and some bugs are still expected.
kg gives your AI assistant persistent, structured, editable project memory stored locally as a knowledge graph.
Instead of relying only on document chunk retrieval, you can keep architecture, decisions, incidents, rules, dependencies, and workflows in a graph that is readable, reviewable, and Git-friendly.
Use it when you want your assistant to understand an existing project across sessions — not start from zero every time.
Why use it
Persistent memory — keep project knowledge between conversations
Structured, not fuzzy — inspect nodes, edges, facts, and gaps directly
Editable and reviewable — store graphs as *.kg files with readable diffs
Local-first — your project memory stays on your machine in git-friendly format
Works with MCP clients — connect it as a local stdio MCP server
Why not just RAG
Classic RAG is good for retrieving text chunks from documents.
kg-mcp is better when you want:
stable project memory instead of repeated retrieval
explicit facts, relations, and dependencies
graph updates during real work with the assistant
something you can inspect, version, diff, and improve over time
Installation
From crates.io
sh
cargo install kg-cli
From script
Recommended install:
sh
curl -sSL https://raw.githubusercontent.com/nnar1o/kg/master/install.sh | sh
You can also download a ready binary from GitHub Releases.
This is the first workflow for a new project: ask the assistant to create or extend a graph from your documentation.
By default, graphs are stored in ~/.kg/graphs as *.kg files.
Minimal prompt:
text
You are connected to kg-mcp.
Project graph name: payments
Build or extend this graph from the project documentation I provide.
Use `payments` as the graph name for all graph operations.
Only add facts grounded in source material.
If an important fact is missing and can be inferred safely from the provided docs, update the graph.
If something is ambiguous, ask or record it as a note instead of inventing facts.
Example prompt with documents:
text
Use kg-mcp to build or extend the `payments` graph from these documents:
- docs/payments/overview.md
- docs/payments/retries.md
- docs/payments/providers.md
Only add facts grounded in the documents.
If something is ambiguous, keep it out of the graph or record it as a note.
When you finish, summarize what was added, what remains unclear, and what document should be ingested next.
For a ready-made repository example, run cargo run --bin repo-example to generate repo-example.kg from this repo.
Automatic graph for a directory
kg can turn an existing folder into a graph automatically. It scans the directory tree, recognizes many common file types, extracts symbols for Rust, Java, JavaScript/TypeScript, Python, and C/C++, and keeps the generated structure separate from the manual graph.
For markdown-like documents, it also creates document (GDOC) and chapter (GSEC) nodes with section content.
It is a fast way to get a useful map of a codebase or workspace without modeling everything by hand. The generated index is local, refreshable, and safe to ignore in git.
Example:
sh
cargo run --bin repo-example
This generates repo-example.kg from this repository as a local demo.
Ask the Assistant About Facts in the Graph
Once the graph exists, the normal workflow is to ask the assistant to inspect it and answer questions from it.
Example prompt:
text
Use kg-mcp to inspect my existing `payments` graph.
I want to understand:
- how payment authorization works,
- what triggers retries,
- which external providers are involved,
- which datastore reads and writes are part of the flow.
If the graph is missing critical information, say exactly what is missing.
Other useful questions:
"What rules control retries in the payments graph?"
"Which systems write to the orders datastore?"
"What is missing or weak in this graph?"
"Which nodes and edges explain the authorization flow?"
Add or Update Facts Through the Assistant
You can also ask the assistant to improve the graph while you work.
Example prompt:
text
Use kg-mcp to review my existing `payments` graph.
Find:
- missing important nodes,
- weak descriptions,
- missing facts,
- suspicious or low-value edges.
Apply safe improvements where possible.
Only add facts grounded in the graph, the provided docs, or the current discussion.
If something is ambiguous, leave it out or add a note.
When you finish, summarize:
- what was wrong,
- what you changed,
- what still needs manual review.
This works best when your main system prompt or project prompt already tells the assistant which graph belongs to the project.
Minimal project-level prompt:
text
You are connected to kg-mcp.
Project graph name: payments.
Use this graph for relevant reads and updates in this project.
If you notice important missing information that is grounded in the available docs or conversation context, update the graph as part of your work.
If uncertain, ask or add a note instead of inventing facts.
Tips
Project config (.kg.toml)
kg looks for .kg.toml in the current directory and its parent directories.