Collapsing CRUD into one script runner keeps the tool definitions small while still exposing the whole surface, and pairing it with a live schema call means the model can look up valid relations before it invents one. The trade-off is explicitness: a graph-scoped command is rejected unless you pass `graph`, use `use <graph>`, or write the canonical prefix — there is no implicit fallback graph, which is safer but means every script has to say where it is writing.
A local stdio server over the kg knowledge graph. Architecture, decisions, incidents, rules and dependencies live as typed nodes and edges in `*.kg` text files you can read, diff and commit, instead of as chunks retrieved from a vector store.
- Three tools, not thirty: `kg_schema` returns the live schema — valid node types, relations, ID prefixes and edge rules — so the model checks before it writes
- `kg_help` returns the manual with examples for one domain: node, edge, graph, schema, kql, feedback, batch, script or all
- `kg` is the script runner that executes everything else: find, get, add, modify, remove, connect, disconnect, list, stats and audit, several commands per call
- IDs read as `<type>:snake_case`, and relations are a fixed vocabulary — HAS, USES, TRIGGERS, DEPENDS_ON, DECIDED_BY, READS_FROM and the rest — so the graph stays queryable
- Resources expose the working directory and discovered graphs; `kg://graph/{name}` returns stats for one graph
- Graphs export to an interactive HTML page with `kg graph <name> export-html`
The `kg-mcp` binary, from `cargo install kg-cli`, the install.sh script, or a GitHub release download, added to your client as a local stdio command. No account and no network service. Graphs default to `~/.kg/graphs`; a `.kg.toml` in the project moves them somewhere you can commit.
One command — cargo install kg-cli