codegraph-mcp vs MegaMemory
No-train, on-prem code knowledge graph served to AI agents over MCP — symbols, call edges, cross-language links and blast-radius queries, with a hash-chained audit log of every read. — versus — MCP server that lets a coding agent build and query a typed concept graph of the project — SQLite store, in-process embeddings, merge-conflict resolution and a local web graph explorer.
Two ways to hand an agent a graph of the repo: codegraph-mcp derives symbols, call edges and blast radius mechanically from source, MegaMemory stores the concepts and decisions an agent wrote down. Mechanical facts vs. curated intent.
| codegraph-mcp | MegaMemory | |
|---|---|---|
| Stars | 7 | 459 |
| Forks | 0 | 41 |
| Language | Python | TypeScript |
| License | NOASSERTION | MIT |
| Last activity | 1 months ago | 3 months ago |
| Topics | code-intel, rag | memory, knowledge-graphs, coding |
| Curated connections | 10 | 5 |
codegraph-mcp — the curator's take
Niche but real: if agents must understand code that cannot leave your building AND compliance asks 'what exactly did the agent read', the tamper-evident audit chain is the only game in town; cross-language call edges (TS fetch → Go/Python handler) catch what one-file context misses. NOT for most teams yet: 5 stars, single vendor, and — deal-breaker until fixed — no clear open-source license (NOASSERTION on GitHub). Treat it as an evaluation candidate, not a dependency.
MegaMemory — the curator's take
The memory that stores design intent rather than code structure: the agent writes `feature`/`module`/`pattern`/`decision` concepts with typed links, and `understand` does semantic search over them. One npm install, a ~23MB embedding model, `.megamemory/knowledge.db` in the repo, nothing leaves the machine, installers for Claude Code, Codex, OpenCode and Antigravity. Its weakness is inherent: the graph is only as true as the last agent that wrote it — hence the merge/conflict tooling — so treat the DB as regenerable and pair it with an AST-derived index rather than replacing one. Small, single-maintainer project; fine for a repo you own, thin for a fleet.