code-review-graph alternative: trace-mcp vs code-review-graph

TL;DR. code-review-graph (tirth8205/code-review-graph, 31.2K stars, Python, MIT) and trace-mcp share the same core architectural premise: parse code with tree-sitter into an incremental, persistent SQLite knowledge graph and serve it to AI coding agents over MCP, instead of letting agents burn context on raw file reads. Both provide cross-file symbol lookup, bidirectional call graphs, reverse-dependency impact analysis, and multi-repo support.

The split is between code review triage and comprehensive codebase intelligence. code-review-graph is designed for review exploration and CI blast-radius checks, with an elegant uncertainty contract that explains why empty results occur. trace-mcp goes deeper into repository semantics with 87 framework integrations, active refactoring, OWASP security scanning, and session memory that binds architectural decisions to code.

Head-to-head

Capability trace-mcp code-review-graph
GitHub stars 103 31.2K
License MIT MIT
Written in TypeScript Python
Current release v3.22.0 v2.3.8
Languages 81 23 + Jupyter notebooks
Framework integrations ✓ 87 integrations ✗ (Python entry points only)
Persistent graph storage ✓ SQLite + FTS5 ✓ SQLite (nodes / edges / metadata)
Edge confidence model ✓ 5 resolution tiers (scip_resolved > lsp_resolved > ast_resolved > ast_inferred > text_matched) 2 tiers (EXTRACTED / INFERRED)
Empty-result reasoning ✗ derived from edge tier (cap in progress) ✓ uncertainty.py (≤140 chars per empty result)
Impact analysis / blast radius ✓ reverse dependency traversal + decorator filter ✓ blast-radius + Leiden communities (igraph/networkx)
Call graph ✓ bidirectional ✓ graph-based
Refactoring tools ✓ rename, move, signature, AST codemod, dead code ✗
Security scanning ✓ OWASP Top-10, type-aware taint, SARIF 2.1.0 ✗
Control-flow / data-flow ✓ CFG with basic blocks, loop back-edges ✗
Session memory ✓ code-linked decision graph, staleness-verified ✗
Compiler-grade precision path ✓ opt-in LSP + offline SCIP ingestion ✗
Multi-repo support ✓ cross-repo API linking ✓ multi-repo daemon
CI / PR blast-radius Action ✓ quality gates + SARIF ✓ turnkey blast-radius GitHub Action
Graph visualization ✓ desktop app (cosmos.gl) ✗
MCP tools advertised (default) 28 (minimal, ~11.6K tok); 181 on full 29 advertised (~8K description tokens)
Tool surface trimming ✓ dynamic load_tools in session; 3 presets manual allowlist (serve --tools, CRG_TOOLS=)

Verified on September 2, 2026 against code-review-graph’s source at commit b58668751ab0 (v2.3.8). Tool registrations, parser dependencies, and graph architecture claims come directly from the source; star count from the GitHub API.

What code-review-graph actually is, from its source

Cloning the repository at commit b58668751ab0 and reading pyproject.toml, code_review_graph/graph.py, main.py, uncertainty.py, scoped_resolver.py, and parser.py surfaced four details worth understanding beyond the README.

Empty results as first-class answers. The clearest idea in code-review-graph is uncertainty.py. When a graph query returns result_count: 0, the agent does not know whether the symbol truly has no callers or whether the target was never indexed, the language has a static-analysis blind spot, or the graph is behind the working tree. A confused agent either assumes the relationship does not exist or abandons the tool and runs expensive brute-force scans. uncertainty.py attaches an explanation under a strict MAX_CONFIDENCE_CHARS = 140 budget when the result set is empty, while keeping normal non-empty results byte-identical. Blind spots are maintained in a LanguageGap table pairing language sets with query patterns, so call-resolution caveats land on call graphs and never on file summaries.

Conventional SQLite storage with string keys. The storage model is a single SQLite file containing nodes, edges, and metadata tables. Edge endpoints are stored as qualified-name strings rather than integer IDs. AST parsing uses tree-sitter-language-pack, traversal runs through networkx, and igraph is an optional extra for calculating Leiden communities.

Advertised tool cost. code_review_graph/main.py registers 29 @mcp.tool() handlers and advertises all 29 to the client by default. Its own docstrings estimate this at “~8k description tokens per LLM turn”. Trimming the surface requires setting the CRG_TOOLS= environment variable or launching with serve --tools .... There is no preset hierarchy and no mechanism for an agent to load deferred tools mid-session.

Headline claims. Its README claims a ~65× median per-question reduction across six repositories (36×–376×), measured against a whole-corpus baseline that the README itself concedes “no real agent pays”.

When to pick code-review-graph

When to pick trace-mcp

Where we are not being smug

Four honest points where code-review-graph leads or sets a standard.

Empty-result honesty is a genuine design win we did not think of first. Treating zero-results with respect by spending ~30 tokens of explanation prevents thousands of tokens of wasted manual file searching. We acknowledged this in our profiling pass and plan to adopt empty-result confidence markers derived from edge resolution tiers.

Their CI GitHub Action is more turnkey than our quality gates. They provide an out-of-the-box GitHub Action for blast-radius reporting on pull requests; our CI integration requires running trace-mcp quality gates or ingesting SARIF payloads.

Our security scanning has a ceiling, and it is stated on the comparisons page rather than only here. The control-flow graph is line-based, not AST-based, and taint analysis is lexical/regex, not a full dataflow engine. Type-aware pruning cuts false positives; it does not turn this into a full static application security testing platform.

Their popularity is roughly 300 times ours. At 31.2K stars, code-review-graph is a proven tool in many workflows, and we do not dismiss that difference.

If you maintain code-review-graph and something here is inaccurate, open an issue and we will correct it.

FAQ

What is the core difference between code-review-graph and trace-mcp? Both projects parse code with tree-sitter into an incremental SQLite knowledge graph so agents can query dependencies instead of re-reading raw files. code-review-graph focuses on code review navigation and blast-radius reporting in CI, pairing it with an uncertainty contract that explains why empty results occur. trace-mcp builds a deeper graph with framework semantics across 87 integrations, active refactoring, security scanning, and code-linked session memory.

What is code-review-graph’s empty-result uncertainty mechanism? Its uncertainty module treats an empty result as an answer that owes the caller a reason. Under a hard 140-character cap, it explains whether a zero result is genuine or the result of a known parser gap or unindexed dependency. This prevents agents from drawing false conclusions or falling back to costly whole-repository file scans.

How do their advertised tool surfaces compare in token cost? code-review-graph registers 29 MCP tools and advertises all 29 by default, costing roughly 8K tokens of descriptions alone every turn, trimmable only via manual allowlists. trace-mcp advertises 28 tools on its minimal preset costing roughly 11.6K tokens including instructions, and keeps ~140 additional tools reachable dynamically via load_tools without requiring an allowlist restart.

Can code-review-graph refactor code or run security scans? No. Reading code-review-graph’s source at commit b58668751ab0 confirmed it is read-only navigation and blast-radius analysis. It provides no rename, move, signature update, or AST codemods, and no OWASP taint analysis or SARIF reporting. trace-mcp ships full refactoring tools and OASIS SARIF 2.1.0 security scanning.

Which languages and frameworks do they support? code-review-graph supports 23 languages plus Jupyter notebooks via tree-sitter-language-pack, but has no framework awareness beyond Python entry points. trace-mcp parses 81 languages and understands 87 framework integrations, resolving route-to-handler, controller-to-template, and model-to-table edges.

Next steps

Last updated: September 6, 2026