How code-review-graph Compares to LSP-Based Tools Like Pyright or TypeScript

code-review-graph builds a persistent, cross-language SQLite graph for multi-hop structural queries, while LSP-based tools like pyright and the TypeScript language server provide compiler-precise, in-memory symbol resolution optimized for single-language editing.

The open-source code-review-graph (CRG) repository creates a durable structural index of your codebase, fundamentally differing from Language Server Protocol (LSP) implementations in both architecture and intended workflow. While tools like pyright and tsserver focus on real-time editing assistance with exact type information, CRG optimizes for AI-assisted code review, impact analysis, and cross-language navigation through a persistent graph database. Understanding how code-review-graph compares to LSP-based tools helps teams choose the right approach for automated reviews versus interactive development.

Core Architectural Differences

Parsing Engines and Representation

LSP-based tools rely on compiler front-ends or language-specific type checkers—in pyright's case, a dedicated Python type-checker; for TypeScript, the tsserver leverages the official compiler API. These engines maintain sophisticated semantic understanding but operate strictly within their language boundary.

In contrast, code-review-graph uses Tree-sitter to parse source files into an abstract syntax tree (AST) across approximately 35 languages and notebook formats. As implemented in code_review_graph/parser.py, the parser extracts nodes representing functions, classes, imports, and tests, then persists edges (calls, inheritance, test coverage) into a SQLite graph store (code_review_graph/graph.py). This creates a language-agnostic structure where cross-language references are first-class citizens rather than unsupported boundaries.

Persistence Models

The persistence strategy marks a fundamental divergence between these approaches. LSP servers maintain in-memory indexes that exist only for the duration of the editor session; when the process restarts, all analysis must be rebuilt from scratch.

CRG persists its graph on disk at .code-review-graph/graph.db, surviving editor restarts, CI runs, and multiple client connections. According to the repository's FAQ documentation (docs/FAQ.md), this persistent storage enables the tool to answer complex historical queries without re-parsing entire repositories on every request.

Update Strategies

LSP tools typically re-parse files on each request or editor save event, which can become expensive in large monorepos. The TypeScript server and pyright both rebuild their internal state frequently to ensure diagnostic accuracy.

CRG implements incremental updates: only changed files trigger re-parsing (approximately 2 seconds for roughly 3,000 files). This optimization makes the tool suitable for continuous integration pipelines where full rebuilds would waste compute resources.

Query Capabilities and Performance

Single-Symbol vs. Multi-Hop Analysis

LSP excels at precise, compiler-level results for individual symbols—go-to-definition, find-references, diagnostics, and safe rename operations. These queries return exact locations because they leverage full semantic analysis.

CRG specializes in multi-hop structural queries that trace relationships across multiple files. Through MCP tools registered in code_review_graph/main.py—such as query_graph_tool, get_impact_radius_tool, and detect_changes_tool—the system can identify callers-of-callers, execution flow paths, test coverage gaps, and blast-radius analysis for proposed changes. As noted in docs/FAQ.md, CRG's call resolution operates at the AST level using heuristics, meaning edges may be marked as EXTRACTED, INFERRED, or AMBIGUOUS rather than compiler-guaranteed.

Token Efficiency for AI Reviews

When integrated with AI systems, CRG demonstrates significant efficiency gains over LSP-based approaches. LSP requires agents to repeatedly issue individual calls and re-read multiple files, making it token-inefficient for multi-file review tasks.

CRG returns compact, token-efficient context—approximately 100 tokens for ultra-compact queries—containing only relevant nodes and edges. The README benchmarks show a median 82× token reduction per question compared to traditional approaches, making it specifically designed for AI-assisted workflows.

Language Support and Extensibility

Cross-Language Edge Handling

LSP servers operate in isolation; pyright knows nothing about your TypeScript files, and tsserver cannot see your Python imports. Each daemon maintains its own state without cross-language awareness.

CRG treats cross-language edges as first-class entities. For example, a Python file importing a JavaScript module creates a direct edge in the graph queryable through the same interface as intra-language calls. This enables analysis of polyglot systems where boundaries between languages blur, such as Node.js applications with Python data processing scripts.

Adding New Languages

Extending LSP functionality requires language-specific plugins or custom protocol extensions, demanding significant development effort for each new language.

CRG simplifies this through declarative configuration. New languages can be supported by dropping a languages.toml file into the configuration without modifying core source code (code_review_graph/parser.py handles the Tree-sitter grammar integration dynamically).

Practical Usage Examples

Building and Querying the Graph

Initialize or incrementally update the structural index:

code-review-graph build

For a 500-file repository, this completes in approximately 10 seconds.

Querying Multi-Hop Callers

Query callers across languages using Python against the MCP server:

import json
import urllib.request

def query_callers(name):
    payload = {
        "jsonrpc": "2.0",
        "method": "query_graph_tool",
        "params": {"pattern": "callers_of", "target": name},
        "id": 1,
    }
    data = json.dumps(payload).encode()
    resp = urllib.request.urlopen("http://127.0.0.1:5555", data=data)
    return json.load(resp)

print(query_callers("handleRequest"))

Unlike pyright or tsserver, this returns both TypeScript and any cross-language callers (such as Python scripts invoking compiled JavaScript modules) in a single request.

Impact Analysis and Blast Radius

Detect changes and assess risk efficiently:

code-review-graph detect-changes --brief

This produces a JSON payload containing affected functions, tests, and risk scores, while displaying token savings metrics. Achieving equivalent results with pyright would require chaining multiple --verifytypes calls with custom scripting to traverse the call graph manually.

When to Use Each Tool

Choose LSP-based tools when you need compiler-precise editing features: safe refactoring, exact type diagnostics, or guaranteed-accurate symbol renaming within a single language. Pyright and the TypeScript language server provide the semantic accuracy necessary for writing and editing code safely.

Select code-review-graph when your workflow requires cross-file, multi-hop insights: AI-assisted code reviews, architectural impact analysis, risk scoring across repository boundaries, or understanding blast radius of changes. The persistent SQLite graph and MCP tool interface optimize for these review-centric scenarios where token efficiency and cross-language visibility matter more than compiler-level type precision.

Summary

• code-review-graph persists a cross-language SQLite graph (graph.db) supporting ~35 languages, while LSP tools maintain temporary, language-specific in-memory indexes.
• CRG provides multi-hop structural queries (callers-of-callers, blast-radius analysis) via MCP tools like query_graph_tool and get_impact_radius_tool, whereas LSP excels at single-symbol resolution.
• Updates are incremental in CRG (~2 seconds for 3,000 files), compared to on-demand re-parsing in LSP servers.
• CRG achieves approximately 82× token reduction for AI contexts by returning compact subgraphs rather than full file contents.
• Cross-language edges are first-class in CRG (e.g., Python importing JavaScript), while LSP servers remain isolated by language.
• New languages integrate via languages.toml configuration in CRG, versus requiring language-specific LSP extensions.

Frequently Asked Questions

Is code-review-graph a replacement for pyright or TypeScript language server?

No. code-review-graph complements rather than replaces LSP-based tools. Use pyright or tsserver for daily editing, diagnostics, and refactoring where compiler-precise type information is essential. Use CRG for automated code reviews, impact analysis, and AI-assisted workflows that benefit from persistent cross-language graph queries.

How accurate are the call relationships in code-review-graph compared to LSP?

CRG's call resolution is AST-level and heuristic. According to docs/FAQ.md, edges can be EXTRACTED, INFERRED, or AMBIGUOUS. LSP tools provide compiler-guaranteed accuracy because they use full type checkers. CRG trades absolute precision for speed, persistence, and cross-language coverage.

Can I use code-review-graph with my existing LSP setup?

Yes. CRG operates independently through its MCP server interface (exposed in code_review_graph/main.py). You can run code-review-graph build alongside your existing LSP configuration without conflicts, since CRG writes to its own SQLite database (.code-review-graph/graph.db) rather than interfering with editor-specific caches.

Does code-review-graph support TypeScript and Python equally?

Yes. Both TypeScript and Python are supported via Tree-sitter parsers. CRG handles .ts, .tsx, and .py files within the same graph, enabling queries that trace execution flow across TypeScript frontend code and Python backend services—something impossible with isolated LSP servers.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}