MegaMemory: an MCP knowledge graph where the coding agent is the indexer

The problem: an agent that forgets your architecture between sessions

A coding agent starts every session with no memory of the last one. It re-reads the same files, re-derives the same conclusions about which module owns which responsibility, and re-litigates decisions the team settled weeks ago. MegaMemory's answer is to make the agent write those conclusions down as concepts and query them before the next task. The README frames the loop as understand, work, update: at session start the agent calls list_roots to orient itself, before a task it calls understand with a natural language query or get_concept for an exact ID, and after a task it calls create_concept or update_concept. The audience is narrow and specific: developers who already run an agent through an MCP client and want continuity that survives a session boundary. It is not a code search tool, and the README is explicit that the graph stores concepts (features, modules, patterns, decisions) rather than code symbols.

The LLM is the indexer, and that is the whole design

There is no AST parsing and no static analysis in this project. The README states this plainly: the agent reads code, writes concepts in its own words, and queries them later. That single decision cascades through everything else. Because concepts are prose rather than symbols, the storage layer can be a plain SQLite database with no language-specific schema. Because retrieval is fuzzy, the project needs embeddings. Because there is no parser, there is nothing to re-run when a file changes; the graph only stays current if the agent updates it. The repository layout in the README confirms the shape: src/tools.ts holds nine tool handlers, src/db.ts handles persistence with libsql in WAL mode at schema v3, and src/embeddings.ts runs all-MiniLM-L6-v2 at 384 dimensions in-process. There is no parser directory, no language server, no file watcher. If you want the graph to reflect a refactor, some agent has to call update_concept.

How retrieval and storage actually work

Search is brute-force cosine similarity over node embeddings. The README says this is fast enough for graphs with fewer than 10k nodes, which is an honest statement of the ceiling rather than a benchmark claim. There is no vector index, no approximate nearest neighbour structure, and no sharding. Embeddings come from Xenova/all-MiniLM-L6-v2, an ONNX quantized model of roughly 23MB that downloads on first use; after that the README states there are no network calls and no API keys. Persistence is SQLite via libsql in WAL mode, with soft-delete history and schema migrations currently at version 3. Soft delete matters more than it sounds: remove_concept takes a reason and keeps history, so an agent that deletes a concept by mistake leaves a trail. The nine tools split into read (understand, get_concept, list_roots, list_conflicts), write (create_concept, update_concept, link, remove_concept) and repair (resolve_conflict). Concept kinds are feature, module, pattern, config, decision and component. Relationship types are connects_to, depends_on, implements, calls and configured_by. Those two enumerations are the entire vocabulary the agent has for describing your system, and they are fixed in code.

Getting it running: install targets and the database path

Installation is global via npm and requires Node.js 18 or later. The README gives npm install -g megamemory, then megamemory install for an interactive installer that asks you to choose an editor. Non-interactive targets exist for four clients. megamemory install --target opencode writes an MCP server entry into ~/.config/opencode/opencode.json, workflow instructions into ~/.config/opencode/AGENTS.md, a skill tool plugin at ~/.config/opencode/tool/megamemory.ts, and two commands, /user:bootstrap-memory and /user:save-memory. megamemory install --target claudecode writes to ~/.claude.json, ~/.claude/CLAUDE.md and ~/.claude/commands/. megamemory install --target antigravity writes a workspace-level ./mcp_config.json. megamemory install --target codex writes ~/.codex/config.toml and ~/.codex/AGENTS.md. For any other MCP client, register a stdio server whose command is just megamemory with no arguments. The README notes the installer only updates config files after a successful read and merge, and will not overwrite existing plugin or command files unless they are already marked as MegaMemory-managed, which is the right default for a tool that edits files you own. The database resolves to .megamemory/knowledge.db relative to the working directory, or to MEGAMEMORY_DB_PATH if you set it. The web explorer runs with megamemory serve, defaults to port 4321, prompts for another port if it is taken, and accepts megamemory serve --port 8080. In the explorer, nodes are coloured by kind and sized by edge count, dashed edges are parent-child links and solid edges are relationships.

The merge engine is the most interesting and least finished part

A SQLite file per project means two developers on the same repository produce two divergent knowledge databases. MegaMemory addresses this with src/merge.ts, described as a two-way merge engine for knowledge.db files, and src/merge-cli.ts, which handles the merge, conflicts and resolve commands. Conflict detection is by concept ID. The README's description of the resolution path ends mid-sentence after mentioning AI-assisted conflict resolution, so the exact mechanism is not documented in the supplied material. What is documented is the tooling around it: list_conflicts groups unresolved conflicts by merge group, and resolve_conflict asks for verified, correct content based on the current codebase. That is a sensible design, because the correct resolution of a stale concept is whatever the code now says, not whichever side of the merge is newer. But it also means conflict resolution is a manual, agent-mediated step. There is no automatic three-way merge against a common ancestor, and nothing in the README suggests the merge is aware of file contents. If your team commits the database, expect conflicts to be a recurring chore rather than an exception.

Where this is the wrong tool

The failure mode is quiet staleness. Nothing in the architecture detects that a concept no longer matches the code. A rename, a deleted module, a reversed decision: the graph keeps the old concept until an agent updates it, and understand will happily return it with high cosine similarity because the wording has not changed. A symbol index would fail loudly here; a prose graph fails silently. The second limitation is the database path. Because it resolves relative to the working directory, one agent session that spans two repositories either writes into the wrong .megamemory directory or needs MEGAMEMORY_DB_PATH set per project. The README presents this as a feature, and for per-project isolation it is, but it constrains how you launch your agent. Third, the <10k node figure is a stated ceiling, not a measured one, and brute-force cosine similarity scales linearly with graph size. Fourth, the fixed vocabulary of six concept kinds and five relationship types will not fit every architecture; a project with heavy event-driven or data-pipeline structure has no natural relationship type for it. Finally, the whole system depends on the agent following the workflow instructions the installer writes into AGENTS.md or CLAUDE.md. The server cannot force an agent to call understand before a task, and an agent that skips that step gets no benefit from any of this.

Alternatives and the difference in approach

The obvious comparison is a conventional code index or language server, which parses source into symbols and answers queries about definitions, references and types. The difference is determinism. A language server's answer is derived from the current file contents and is wrong only if the parser is wrong; MegaMemory's answer is derived from whatever an LLM wrote earlier and is wrong whenever the code moved on without a matching update. The trade is coverage against freshness. A symbol index cannot tell you why a module exists or what was decided about it, because that information is not in the syntax tree. MegaMemory can, because the agent wrote it down in prose. If your questions are of the form where is this function defined, use a language server. If they are of the form why does this module exist and what depends on it, a prose graph is the only structure that holds the answer. The two are complementary, and MegaMemory does not attempt to replace the first.

Licence, maintenance and what upgrading costs you

MegaMemory is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation, though the embedding model it depends on, Xenova/all-MiniLM-L6-v2, is a separate artefact with its own terms, and the README does not state them. Check the model card before shipping anything that bundles it. On maintenance: the repository shows three releases between March and May 2026, with v1.6.2 as the most recent, and the schema is at version 3, which implies the storage format has changed at least twice. The README describes schema migrations as a feature of db.ts, so upgrades should be handled, but a format change is still the moment to back up .megamemory/knowledge.db before running a new version against it. Because the database is a local file you own, the migration cost of leaving MegaMemory is low: nothing is hosted and nothing is locked in. The cost of staying is the ongoing discipline of having agents write concepts after tasks, which the /user:save-memory command exists to make routine.

Editorial conclusion

Adopt MegaMemory if your team already runs opencode, Claude Code, Antigravity or Codex, and you want session knowledge to survive in a per-project SQLite file without any API key or network call after the first model download. Do not adopt it if you need symbol-level code indexing or work across many projects from a single agent session, because the database is resolved relative to the working directory unless you set MEGAMEMORY_DB_PATH. Before committing, verify three things: that your agent actually calls understand before tasks (the README describes this as a workflow instruction the installer writes into AGENTS.md or CLAUDE.md, not as something the server enforces), that your graph stays under the <10k node range the README gives for brute-force search, and that a two-way merge of two developers' .megamemory/knowledge.db files produces conflicts you can resolve rather than silent overwrites.

Official sources

1. 0xK3vin/MegaMemory on GitHub
2. Issues
3. License: MIT
4. README
5. Releases