Why a feature grid lies
A row like "can it write files?" scores a read-only retriever as an empty cell — the toaster losing at air-frying. But read-only isn't a missing feature; for an agent it's a deliberate smaller attack surface. The grid flattens a design choice into a deficit.
The fix: declare the appliance before you compare.
Nobody's confused when you say "a toaster and an air fryer both apply dry heat to food; they differ at heat source, chamber geometry, airflow, and target food." Name the axes and the comparison becomes honest. Every tool below is the same six-stage pipeline making different choices — so we name the class, then profile the stages.
The operational pipeline
Every code-context tool is this pipeline. A tool's identity is just its column of choices down it.
Ingestion
How is source acquired & parsed?
Representation
What artifact gets stored?
Retrieval
How do you ask?
Grounding
Is output tied to real source lines?
Action
What can it do to the code?
Delivery
How does it reach the agent?
Componentry — the parts list
Orthogonal to the stages: the physical parts a tool is built from. Two tools can share a stage choice yet differ sharply in parts (a graph in SQLite vs a graph in KuzuDB).
Five classes, declared up front
Before any scoring, every direct alternative sorts into one of these. The class tells you what the tool is for — and what it deliberately trades away to be good at it.
Grounded read-only retriever
Graph-database code intelligence
Embedding / RAG search
Whole-repo packer
Mutate / execute runtime
Every tool, profiled down the pipeline
Grouped by class, then profiled across all six stages. Where an axis is honestly graded, colour shows it; Action is a class declaration, not a score (see the caveat below).
| Tool | IngestionHow is source acquired & parsed? | RepresentationWhat artifact gets stored? | RetrievalHow do you ask? | GroundingIs output tied to real source lines? | ActionWhat can it do to the code? | DeliveryHow does it reach the agent? |
|---|---|---|---|---|---|---|
| GROUNDED READ-ONLY RETRIEVER | ||||||
| jCodeMunch | tree-sitter AST | SQLite symbol index | symbol + ranked hybrid | line-exact | read-only | consolidated, token-annotated |
| cymbal | tree-sitter | SQLite / FTS5 | symbol lookup | line-exact | read-only | Go CLI |
| trace-mcp | tree-sitter (AST-first) | symbol index | symbol + flow trace | line-exact | read-only | ~170 tools (bloated surface) |
| vexp | Rust parser | local index | hybrid context | line-exact | read-only | native binary |
| SigMap | parse | ranked file list + signature file | query → ranked files | synthesized signatures | read-only (writes artifact) | file artifact, not agent tools |
| Pharaoh | open AST parser | hosted layer | symbol | line-exact | read-only | OSS parser + hosted service |
| GRAPH-DATABASE CODE INTELLIGENCE | ||||||
| GitNexus | graph build | knowledge graph | graph traversal | graph-derived | read-only | "nervous system" framing |
| Dual-Graph (GrapeRoot) | parse | dual graph | graph traversal | graph-derived | read-only | very active release cadence |
| code-review-graph | tree-sitter | persistent SQLite graph | graph traversal | line-linked | read-only | review-oriented |
| Context+ | TS parse | hierarchical feature graph | graph + search | synthesized | read-only | feature-graph framing |
| Axon | parse | KuzuDB graph + vector | hybrid (BM25 + vector + fuzzy) | probabilistic | read-only | community detection (Leiden) |
| Octocode | tree-sitter | LanceDB vector + typed graph | hybrid | probabilistic | read-only | Rust binary + CLI |
| CodeGraph | TS parse | pre-indexed knowledge graph | graph lookup | line-linked | read-only | ships prebuilt to Claude Code |
| codebase-memory-mcp | parse | persistent knowledge graph | graph | probabilistic | read-only | claims learning / memory |
| EMBEDDING / RAG SEARCH | ||||||
| SocratiCode | AST-aware chunking (ast-grep) | per-branch Qdrant vectors | dense vector + BM25 | probabilistic | read-only | enterprise vector intel |
| WHOLE-REPO PACKER | ||||||
| Repomix | read files | flat file (XML / MD / text) | one-shot dump | verbatim (whole repo) | read-only | single artifact |
| RepoMapper | tree-sitter | token-budgeted map | map generation | synthesized map | read-only | single map artifact |
| MUTATE / EXECUTE RUNTIME | ||||||
| Raw File Tools | none (raw) | none | grep / glob | line-exact (whole file) | read + write (bash) | native to the agent |
| mcp-server-filesystem | none | none | path / list / search | line-exact | read + write | 13 filesystem ops |
| Serena | LSP | in-memory (LSP) | semantic symbol (IDE-level) | line-exact | read + write + execute | coding-agent toolkit |
| SDL-MCP | tree-sitter (Rust indexer) | embedded graph-DB | graph + symbol delta | line-exact | read + write + execute | gateway + delta ledger |
| TokenSave | tree-sitter (50+ langs) | libSQL symbol index | symbol + search | line-exact | read + write | ~80 tools, token TUI |
jCodeMunch's row is the only one that is line-exact grounding + read-only + a consolidated, token-annotated surface at the same time.
Where the taxonomy stops being a ranking
Two of the six stages are incommensurable — you can describe them, but you can't honestly rank them. Pretending otherwise is exactly the air-fryer/toaster mistake in reverse.
Action is a class, not a score
A mutate/execute runtime isn't a "better" retriever than a read-only one — it's a different appliance doing a different job. If a grid renders read-only as a loss in a "can it write?" row, it has drawn the toaster failing at air-frying. Declare it; let the reader weigh it against their own charter.
Grounding is a real trade, not a defect
Embedding/RAG search trades line-exact fidelity for semantic recall — it finds "the thing that handles auth" when you don't know the symbol name. That's a genuine design axis. Calling it "less accurate" misses that it answers a question the grounded class structurally can't.