explainx / blog
code-review-graph builds a Tree-sitter graph of your codebase so AI coding agents read only the blast radius of a change via MCP — 38x to 528x fewer tokens per review question across 6 benchmarked repos. Setup and honest limits.
Jul 20, 2026
李博杰 (Bojie Li) open-sourced 《深入理解 AI Agent》 with 10 chapters, PDFs in four languages, and chapter-matched demos. This guide answers the questions GitHub Trending readers ask: cost, English lag, first runnable projects, and how it connects to explainx.ai's MCP, skills, and harness coverage.
Jul 8, 2026
Fork ai-job-search, run /setup on your profile, /scrape Danish job boards (or LinkedIn anywhere), and /apply to get a fit-scored, tailored CV and cover letter with a second agent review — plus mandatory PDF compile and ATS checks.
Jun 26, 2026
OpenKnowledge from Inkeep ships a Notion-like WYSIWYG markdown editor, LLM wiki with MCP and skills, and no-code GitHub team sync — now open source at 444 stars with a macOS app and ok CLI for every platform.
Every time an AI coding agent reviews a pull request, it has to decide how much of the codebase it actually needs to read — and most tools default to reading too much. code-review-graph, an open-source MIT-licensed tool with over 24,000 GitHub stars, tackles that specific inefficiency: it parses a repository into a structural graph with Tree-sitter, then serves an AI assistant only the blast radius of a change through MCP — the functions, files, and tests actually affected — instead of letting the agent re-scan large portions of the repo on every review question.
The pitch is backed by published, reproducible benchmarks rather than just marketing copy, and the project's own documentation includes an unusually honest limitations section. Here's how it works, what the numbers actually show, and where it falls short.
| Question | Answer |
|---|---|
| What is it? | MCP server that gives AI coding agents a structural code graph instead of raw file reads |
| License? | MIT |
| GitHub stars? | 24,600+ |
| Install? | pip install code-review-graph then code-review-graph install and build |
| Median token reduction? | ~82x per question (range 38x–528x across 6 benchmarked repos) |
| Supported tools? | Claude Code, Cursor, Codex, Windsurf, Zed, Gemini CLI, GitHub Copilot, and more |
| Languages? | Python, JS/TS, Go, Rust, Java, PHP, Ruby, Swift, and 20+ more via Tree-sitter |
| Sends code externally? | No — local SQLite by default; CI Action runs entirely on your own runner |
| CI integration? | GitHub Action posting risk-scored, sticky PR review comments |
The core inefficiency code-review-graph targets is specific: when an AI coding assistant is asked to review a change or answer "what does this function affect," a naive approach is to read broadly across the codebase looking for related code — expensive in tokens and slow, especially on large monorepos. code-review-graph's alternative is to build the dependency structure once, ahead of time, and then answer "what's affected by this change" as a graph query instead of a fresh full-text search every time.
The mechanism: a Tree-sitter parser builds an AST of the repository, which gets converted into a graph of nodes (functions, classes, imports) connected by edges (calls, inheritance, test coverage). When a file changes, the tool traces every caller, dependent, and test that could plausibly be affected — the "blast radius" — and that minimal set is what gets served to the AI assistant's context, rather than the whole file tree.
code-review-graph published benchmarks across 6 real open-source repositories (13 commits total), each pinned to a specific upstream commit SHA for reproducibility, with a deterministic community-detection algorithm (Leiden, fixed seed) so two runs on different machines produce identical results. The project provides a full reproduction recipe in its documentation rather than asking readers to take the numbers on faith.
The headline figure: a median per-question token reduction of ~82x comparing a whole-corpus baseline against the graph-query approach, with a range from 38x (express, a smaller repo where structural overhead eats into the savings) up to 528x on FastAPI, the best-case repo in the benchmark set. The project is explicit in its own documentation that 528x is a maximum, not typical — a distinction worth noting since that number is the one most likely to get quoted out of context in a marketing pitch. The more representative figure for planning purposes is the 82x median.
A second metric — impact accuracy, measured as 0.71 average F1 against graph-derived ground truth — comes with its own caveat directly from the project: because the "ground truth" used to score accuracy is derived from the same graph edges the tool predicts from, a perfect "recall 1.0" score is circular by construction, not independent validation. The project also reports a separate, harder "honest co-change mode" — grading against files that actually changed together in the same real commit — and states plainly that those numbers run "substantially lower" than the graph-derived comparison. Publishing the harder, less flattering metric alongside the favorable one is a level of methodological transparency that's genuinely uncommon in developer-tool benchmarking.
Installation is a three-command flow: pip install code-review-graph (or pipx install code-review-graph), then code-review-graph install, which auto-detects which AI coding tools are present on the machine and writes the correct MCP configuration for each — supporting Codex, Claude Code, CodeBuddy Code, Cursor, Windsurf, Zed, Continue, OpenCode, Antigravity, Gemini CLI, Qwen, Qoder, Kiro, and GitHub Copilot (both the VS Code extension and the CLI) — followed by code-review-graph build to parse the target repository. Platform-specific installs are also supported directly (--platform claude-code, --platform cursor, etc.) for teams standardizing on one tool rather than auto-detecting across several.
A symmetric uninstall command is provided as well, with a --dry-run preview mode, scoped removal that only touches CRG-owned config entries (leaving unrelated MCP servers and hooks untouched), and atomic file writes so a failed uninstall doesn't corrupt shared configuration files — a level of care around reversibility that's worth calling out given how many dev-tool installers leave partial state behind on removal.
Parser support spans a genuinely broad list — Python, JavaScript/TypeScript/TSX, Go, Rust, Java, C/C++, C#, Ruby, Kotlin, Swift, PHP, Scala, Solidity, Dart, R, Perl, Elixir, Zig, PowerShell, Julia, plus infrastructure-as-code formats like Terraform/OpenTofu and Ansible, and notebook formats (Jupyter/Databricks .ipynb). PHP gets extra framework-aware treatment: Composer PSR-4 import resolution, Blade template reference tracking, and Laravel Route/Eloquent semantic edges when the codebase shows explicit framework evidence.
For languages not natively covered, the project supports adding a language via a languages.toml config file mapping file extensions to any grammar bundled in tree_sitter_language_pack, plus the specific Tree-sitter node types for functions, classes, imports, and calls — no fork or code change required, which meaningfully lowers the bar for community-contributed language support versus tools that require a PR against the core parser.
The project's own documented limitations are worth taking at face value rather than glossing over, since they map directly onto real workflow decisions:
Small single-file changes can cost more tokens than a naive file read, because the structural metadata that enables multi-file blast-radius analysis is overhead that doesn't pay off on a trivial edit — the tool's own express-repo benchmark result (38x, the low end of the range) reflects exactly this dynamic. Keyword search ranking sits at an MRR of 0.35, meaning the right result usually lands in the top four matches but isn't reliably ranked first — with a specific known gap where express-style module-pattern naming returns zero hits. Execution-flow detection — tracing call chains from entry points — is strongest for Python and PHP/Laravel and described as needing work for JavaScript and Go specifically. And the precision-versus-recall tradeoff in impact analysis is deliberately conservative, meaning it flags files that might be affected, which produces some false positives in large dependency graphs rather than under-flagging and missing real impact.
Practically, that suggests the tool's value curve favors larger repos with non-trivial multi-file changes — exactly the monorepo scenario the project's own marketing leads with — over small projects or single-file diffs, where a plain file read may simply be cheaper. Teams evaluating it should run the tool's own reproduction recipe against their own repository shape before assuming the published 82x median transfers directly, since the 38x-to-528x spread shows how much that number can move based on codebase size and structure.
Beyond local editor use, code-review-graph ships as a composite GitHub Action that runs the same analysis entirely on your own CI runner — the project is explicit that no source code is sent to any external service in this mode — and posts a single sticky comment per pull request with risk-scored functions, affected execution flows, and test gaps, updating in place on every push rather than spamming a new comment per commit. An optional fail-on-risk input turns the review into an actual merge gate rather than just an informational comment.
This fits into the broader 2026 pattern explainx.ai has tracked around MCP-based tooling and agent skill security — giving coding agents structured, scoped context through a protocol-level interface rather than unrestricted file-system access, which both improves efficiency and narrows the blast radius (in the security sense) of what an agent can see and act on during a review task.
Star counts, version numbers, and benchmark figures reflect the project's GitHub repository as of July 22, 2026. Token-reduction figures are the project's own published, reproducible benchmark results — verify against the current reproduction recipe in the repository before citing in procurement or evaluation documents.
