Crg

Better Code Review Graph

Renamed: repo is crg, PyPI distribution is n24q02m-crg (formerly better-code-review-graph, kept as a legacy command alias) — CLI-first (crg command); MCP server is a secondary surface.

mcp-name: io.github.n24q02m/crg

Knowledge graph for token-efficient code reviews -- semantic search and call-graph resolution across your codebase.

Sister projects from n24q02m (click to expand)

An MCP server that parses your codebase with Tree-sitter, builds a structural graph of functions/classes/imports, and gives Claude (or any MCP client) precise context so it reads only what matters instead of the whole tree. Semantic search runs through the local ONNX model registry from fastretrieval by default (zero config, no API key), with an optional cloud embedding chain. Fork of code-review-graph with fixed multi-word search, qualified call resolution, dual-mode embeddings, output pagination, and production CI/CD.

v2.0 migration (BREAKING)

v2.0 adds temporal columns (valid_from_sha / valid_to_sha on every node + edge) and an opt-in security scanner. The schema migration is auto-applied on first GraphStore open, and a backup of the pre-2.0 DB is saved to .pre-2.0.bak so you can roll back. See BREAKING_CHANGES.md for the full schema-change list, behavior changes, environment requirements, and the downgrade procedure (CRG_DOWNGRADE_TO_1_X=1 uv run crg).

Table of contents

• v2.0 migration (BREAKING)
• Install
• Usage
• Smithery
• Configuration
• Tools
• CLI
• Features
• Comparison
• Security
• Build from source
• Trust model
• Migration & changelog
• Documentation
• License

Install

For OMP and other local coding harnesses, the primary surface is the package CLI plus the bundled skills/ workflows. The skills invoke the CLI directly and do not require an MCP server mapping.

# Run without a persistent install (short `crg` script; the PyPI distribution is

n24q02m-crg, so uvx needs the explicit --from form for the crg name)

uvx --python 3.13 --from n24q02m-crg crg graph build --full-rebuild \ --repo-root /path/to/repo uvx --python 3.13 --from n24q02m-crg crg graph stats \ --repo-root /path/to/repo

Or install the console scripts (installs both crg and the legacy long name)

pip install n24q02m-crg crg query search --search-query "authentication" \ --repo-root /path/to/repo

The optional Semgrep engine for deeper security scans is a separate extra:

pip install 'n24q02m-crg[security]'

MCP stdio remains a secondary protocol adapter for clients that require it:

{

"mcpServers": { "crg": { "command": "uvx", "args": ["--python", "3.13", "n24q02m-crg"], "env": { "MCP_TRANSPORT": "stdio" } } } }

Install matrix (stdio unless noted; the CLI-first usage above stays the primary surface):

Install with an AI agent -- paste this to your AI coding agent:

Install MCP server crg following the steps at

https://raw.githubusercontent.com/n24q02m/claude-plugins/main/plugins/crg/setup-with-agent.md

Full CLI usage is in CLI. Optional per-client MCP setup is at [docs.n24q02m.com/servers/crg/setup/](https://docs.n24q02m.com/servers/crg/setup/).

Usage

Two ways to run the server, plus the surfaces to consume it.

Dev: uv, no auth (loopback only)

# instance config lives at $CRG_CONFIG_DIR or ~/.crg (same schema as hull's

config.toml); a default no-auth template is fine for local dev

uv run n24q02m-crg server start

-> http://127.0.0.1:8000/mcp (no-auth is refused on any off-loopback bind)

Always-on: docker (token auth)

cp docker-config/config.example.toml docker-config/config.toml

mint a token + hash (hull CLI ships with crg's dependency tree):

TOKEN=$(python -c "import secrets; print(secrets.token_urlsafe(32))")

hull token hash "$TOKEN" # paste output into token_hash in config.toml

docker compose up -d

The compose file builds the Dockerfile's http target (image crg:http), publishes the container on host loopback only (127.0.0.1:${CRG_PORT:-8772}:8080), and mounts ./docker-config/config.toml read-only at the container's config dir (CRG_CONFIG_DIR=/data/config); graph state persists in the crg-data named volume. All state stays on your machine.

Consuming: CLI or MCP

CLI (local graphs, no server needed):

crg graph build --full-rebuild --repo-root /path/to/repo

crg query search --search-query "authentication" --repo-root /path/to/repo

MCP over HTTP (remote/always-on): point any MCP client at http://127.0.0.1:8772/mcp with Authorization: Bearer :

{

"mcpServers": { "crg": { "url": "http://127.0.0.1:8772/mcp", "headers": { "Authorization": "Bearer " } } } }

Per-task model configuration

Each task (embed / rerank / chat / jev_score) resolves its own OpenAI-spec provider cell from [models. ] in the instance config: an independent base_url + api_key + model. Cloud or local is purely a config choice — point base_url at OpenRouter, a vendor, or your own local gateway (e.g. http://host.docker.internal:11434/v1). API keys are host-only material: keep them in config.toml (gitignored under docker-config/) or supply via HULL_ _API_KEY env; they are never end-user supplied.

Local-first boundary

CRG is local-first for coding workflows:

• CLI and bundled Skills are the primary surfaces for graph build/query, impact analysis, review context, security scans, and repository onboarding.
• MCP stdio is the secondary protocol adapter over the same local domain services; it does not maintain a separate graph implementation.
• Graph state stays in /.crg/graph.db unless an explicit multi-user/self-host configuration selects another data directory.
• PyPI, CI, security scanning, GitHub releases, and eligible stable MCP Registry publication remain active. Historical public OCI tags are retained, but new public Docker Hub/GHCR images are no longer published.
• CRG has no hosted Cloudflare runtime in the target topology.

Smithery

The repo ships a smithery.yaml so the server can be built and run through Smithery. It deploys over stdio and needs no startup configuration -- the config schema is empty, and any optional cloud embedding/summary keys are supplied at runtime through the server's own config flow (see Configuration below). The launch command is the same uvx invocation as a local install:

startCommand:

type: stdio commandFunction: |- (config) => ({ command: 'uvx', args: ['--python', '3.13', 'crg'] })

Configuration

Everything w