Field Guide

A taxonomy of code-context tools
— because a feature grid can lie

Scoring these tools on a flat checkmark grid is like pitting an air fryer against a toaster: similar goals, wildly different machines. The fix is to declare each tool's appliance class first, then profile it stage-by-stage down the same retrieval pipeline.

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.

Stage 1

Ingestion

How is source acquired & parsed?

Stage 2

Representation

What artifact gets stored?

Stage 3

Retrieval

How do you ask?

Stage 4

Grounding

Is output tied to real source lines?

Stage 5

Action

What can it do to the code?

Stage 6

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).

Parser tree-sitter · LSP · native compiler Store SQLite index · vector DB · graph DB · flat file Ranker heuristic · embedding · learned weights Runtime none · write · execute-sandbox Scope single-repo · suite · org-rollup Transport stdio · SSE · HTTP

Appliance 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

For: Answer "where / what is this symbol" with line-exact source, spending the fewest tokens possible.
Trades: Deliberately cannot write or run code. Not a semantic-similarity search — it returns what is there, not what is like it.
jCodeMunch cymbal trace-mcp vexp SigMap Pharaoh

Graph-database code intelligence

For: Model the codebase as a graph (call edges, imports, entities) and traverse relationships.
Trades: A graph build and store to maintain; answers are as good as the graph, and edges can drift from source.
GitNexus Dual-Graph (GrapeRoot) code-review-graph Context+ Axon Octocode CodeGraph codebase-memory-mcp

Embedding / RAG search

For: Find code by meaning — "the thing that handles auth" — via vector similarity.
Trades: Recall over fidelity: results are ranked probabilities, not guaranteed line-exact facts. Needs an embedding step and a vector store.
SocratiCode

Whole-repo packer

For: Flatten the whole repo (or a budgeted map of it) into one artifact and hand it to the model in a single shot.
Trades: No query-time retrieval; the model pays to read the pack. Great for small repos, expensive as they grow.
Repomix RepoMapper

Mutate / execute runtime

For: Give the agent hands: read AND write files, run tools, refactor, apply edits.
Trades: A different appliance entirely. Larger attack surface and less predictable behaviour; retrieval is one feature among many.
Raw File Tools mcp-server-filesystem Serena SDL-MCP TokenSave

Context interception layer

For: Sit between the agent and the model, compressing what gets sent — prompt, history, tool results, shell output — so the bill falls without the agent changing.
Trades: The largest trust surface of any class here: it reads and rewrites every request in flight. Savings are real, but so is the failure mode — a compressor that drops a line drops it silently, and the agent cannot know what it did not receive.
LeanCTX

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).

line-exact facts tied to real lines probabilistic ranked similarity synthesized generated summary/map read-only write / execute
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 ~50-tool default since 2026-07-26 (~170 on opt-in full)
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
CONTEXT INTERCEPTION LAYER
LeanCTX tree-sitter AST (27 langs) property graph + embeddings BM25 + vector, RRF with graph proximity line-exact on read, rewritten in transit read + intercept + compress MCP tools plus an optional provider proxy

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.

See the full head-to-head grid → Try jCodeMunch free