# Code-Graph-RAG (pypi · code-graph-rag)

Knowledge-graph RAG for multi-language codebases: index, query and edit code in natural language.

- Trust score: 79/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- pypi · `code-graph-rag`: 79/100 (this document), [markdown](https://verifymcp.io/servers/vitali87-code-graph-rag/code-graph-rag.md), [page](https://verifymcp.io/servers/vitali87-code-graph-rag/code-graph-rag)

## Channel facts

- Registry: `pypi`
- Package: `code-graph-rag`
- Version: `0.5.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 93/100
  - No malware found by supply-chain analysis.
  - Known CVEs were checked across the 72 of 73 dependencies we could resolve, so this covers what we could see, not the whole tree.
  - Declares code that runs automatically (build-time code we could not rule out (a Hatch, PDM or setuptools build hook, a dynamic version we could not read statically, shipped VCS metadata or a stray root module)) and that we could not recognise. It may be perfectly ordinary, but we have not established what it does.
  - Dependency health was assessed across the 72 of 73 dependencies we could resolve, so this covers what we could see, not the whole tree.
- **Provenance & Transparency**: 100/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to vitali87/code-graph-rag).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 2 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 67/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6508 tokens (~191/item across 34 items; 34 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 10/100
  - Stability observed for 3 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 34 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the Code-Graph-RAG MCP server?

Code-Graph-RAG runs locally as a PyPI package, launched with uvx code-graph-rag. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add vitali87-code-graph-rag -- uvx code-graph-rag
```

### Cursor

```json
{
  "mcpServers": {
    "vitali87-code-graph-rag": {
      "command": "uvx",
      "args": [
        "code-graph-rag"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "vitali87-code-graph-rag": {
      "command": "uvx",
      "args": [
        "code-graph-rag"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add vitali87-code-graph-rag -- uvx code-graph-rag
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "vitali87-code-graph-rag": {
      "type": "local",
      "command": [
        "uvx",
        "code-graph-rag"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add vitali87-code-graph-rag --command uvx --arg code-graph-rag
```

### Hermes

```yaml
mcp_servers:
  vitali87-code-graph-rag:
    command: "uvx"
    args: ["code-graph-rag"]
```

### Netclaw

```json
{
  "McpServers": {
    "vitali87-code-graph-rag": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "code-graph-rag"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add vitali87-code-graph-rag -t stdio -c uvx -a code-graph-rag
```

### Other

```json
{
  "mcpServers": {
    "vitali87-code-graph-rag": {
      "command": "uvx",
      "args": [
        "code-graph-rag"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 79, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-11-04 (score 64, −14)

- [security regression] Malware scan: pass → unverified

### 2026-11-03 (score 78, +15)

- [security improvement] Malware scan: unverified → pass
- [functional improvement] Stability: unverified → 0.03
- [functional] Package version: 0.4.19 → 0.5.0

### 2026-11-02 (score 63)

First indexed and scored.

## MCP tools (34)

### `list_projects` (~29 tokens)

List all indexed projects in the knowledge graph database. Returns a list of project names that have been indexed.

### `delete_project` (~61 tokens)

Delete a specific project from the knowledge graph database. This removes all nodes associated with the project while preserving other projects. Use list_projects first to see available projects.

Input parameters:

- `project_name` (string, required): Name of the project to delete (e.g., 'my-project')

### `wipe_database` (~49 tokens)

WARNING: Completely wipe the entire database, removing ALL indexed projects. This cannot be undone. Use delete_project for removing individual projects.

Input parameters:

- `confirm` (boolean, required): Must be true to confirm the wipe operation

### `index_repository` (~46 tokens)

WARNING: Clears all data for the current project including its embeddings. Parse and ingest the repository into the Memgraph knowledge graph. Use update_repository for incremental updates. Only use when explicitly requested.

### `update_repository` (~28 tokens)

Update the repository in the Memgraph knowledge graph without clearing existing data. Use this for incremental updates.

### `reingest` (~265 tokens)

Re-ingest specific files into the knowledge graph after editing them. Re-parses only the given files and the files that depend on them, and re-resolves calls in that set only; an edit that leaves a file's interface unchanged (a comment, or a function body no other file's resolution reads) re-parses no dependents at all. An edit lands in the graph in the time it takes to parse the affected dependents (hundreds of milliseconds for a typical file, seconds for a hub imported by dozens) instead of a full update_repository pass. Paths are relative to the project root; files that no longer exist are removed from the graph; paths the project's ignore rules exclude are skipped and reported rather than indexed. Repository-wide passes are not re-run: code-quality findings (smells, vulnerabilities, patterns) and URL-to-endpoint links are rebuilt only by update_repository. Returns the files re-parsed, the dependents re-parsed with them, the files removed, the paths skipped, and the elapsed milliseconds.

Input parameters:

- `deleted` (array): Files to remove from the graph even if a same-named file exists on disk.
- `paths` (array, required): Files to re-ingest, relative to the project root (created, modified, or deleted).

### `resolve` (~230 tokens)

Resolve a name or a location to qualified names in the graph. `target` is a qualified name, a bare name like `helper` or `Store.get`, or `path:line` (the file's path relative to the repository root or absolute inside it, a 1-based line, optionally `:col`) for the definitions spanning that line, innermost first; a file the project does not hold is refused with an error. Exact matches come first, then dotted-suffix matches, then same-name matches. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `target` (string, required): A qualified name, a bare name (`helper`, `Store.get`), or `path:line` (the path relative to the repository root, or absolute inside it; a trailing `:col` is ignored).

### `definition` (~161 tokens)

File, line span, decorators, docstring and source of one definition by qualified name (`found` is false when the graph has no such node). `start_line` and `source` open at the first decorator; `name_line` is the line of its name (the `def`/`class` line). Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `qualified_name` (string, required): Fully qualified name (e.g., 'app.services.UserService.create_user')

### `callers` (~180 tokens)

Call sites that invoke a qualified name, one row per site with the caller, file, line, column, argument count and keyword names taken from the CALLS edges; `depth` > 1 follows the callers' callers (`through` names the callee each site invokes, `callee_path` its file). Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `depth` (integer): How many hops to follow (1 to 5; default 1).
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `qualified_name` (string, required): Fully qualified name (e.g., 'app.services.UserService.create_user')

### `callees` (~192 tokens)

Call sites inside a qualified name, one row per site with the callee and the location of the call: `path` is the file holding the site's `line` and `col` (the caller's, named by `through`) and `callee_path` the file defining the callee; `depth` > 1 follows the callees' callees. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `depth` (integer): How many hops to follow (1 to 5; default 1).
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `qualified_name` (string, required): Fully qualified name (e.g., 'app.services.UserService.create_user')

### `implementors` (~186 tokens)

Types that inherit from or implement a class, interface or trait (INHERITS / IMPLEMENTS edges). Direct subtypes only by default; `depth` > 1 also follows their own subtypes (every class implementing an interface through an abstract base), each row then carrying its `depth` and the type it was reached `through`. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `depth` (integer): How many hops to follow (1 to 5; default 1).
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `qualified_name` (string, required): Fully qualified name (e.g., 'app.services.UserService.create_user')

### `overrides` (~187 tokens)

Methods overriding a method, and the method it overrides (OVERRIDES edges in both directions). Direct only by default; `depth` > 1 follows each direction on its own (the overriders' overriders, and what the overridden method overrides in turn), each row then carrying its `depth` and the method it was reached `through`. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `depth` (integer): How many hops to follow (1 to 5; default 1).
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `qualified_name` (string, required): Fully qualified name (e.g., 'app.services.UserService.create_user')

### `annotate` (~373 tokens)

Attach a durable note (a Gloss) to one definition in the graph, never to the source file. `target` names the definition the way `resolve` does, optionally with `#getter`, `#setter` or `#deleter` after it to name one member of a property (a `#` opening a name, as in a JS private member, is part of the name); a name matching several definitions is refused with the candidates, so pass a qualified name to disambiguate. `kind` types the claim (invariant, mirrors, platform-conditional, safety-precondition); `mentions` lists other definitions the note refers to, each becoming a MENTIONS edge. Write the WHY that is not in the code ("safe because validate() runs first"), not a restatement of what the code does. Returns the stored gloss, or an error and nothing written.

Input parameters:

- `author` (string): Optional. Who is writing the note (an agent or session name); default `agent`.
- `body` (string, required): The note itself: the reasoning a reader cannot recover from the code.
- `kind` (string, required): One of `invariant`, `mirrors`, `platform-conditional`, `safety-precondition`.
- `mentions` (string): Optional. Comma-separated definitions the note refers to, each a name `resolve` accepts; every one must resolve to exactly one definition.
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `target` (string, required): A qualified name, a bare name (`helper`, `Store.get`), or `path:line` (the path relative to the repository root, or absolute inside it; a trailing `:col` is ignored).

### `glosses` (~528 tokens)

Notes (Glosses) about one definition: `annotating` are filed on it, `mentioning` are filed on other definitions and refer to it. `target` is resolved as `annotate` resolves it. Each note's `anchor_state` is graded after each sync of its project: EXACT when its definition's content hash still equals the one recorded at writing, STALE when it differs (EXACT again on revert), MOVED when the name is gone and exactly one definition in the project carries the recorded hash (the note follows it; `moved_from` keeps the old name), AMBIGUOUS when several do (`candidate_qns` lists them). When no definition carries the hash (a rename changes it), the note's text-quote anchor is tried: a digest of the definition's own text with its name masked, so exactly one definition in the project whose body still matches is followed as MOVED (then graded STALE, since the signature changed), several with the same body are told apart by the lines around them or listed as AMBIGUOUS, and none is LOST. The quote is recorded only when the note was written against this server's own checkout. A note on a module, or one written before hashes were recorded, is not graded while attached (there is no hash to compare) and is LOST if its name disappears (a module has no span to quote); a class, interface, enum, type or union carries a hash like a function and is graded and repaired the same way. A note's `mentions` are anchored the same way: a mentioned definition that is renamed or moved is followed by its hash or quote, one that cannot be placed is listed in `mentions_lost` with no edge (still, once another mention has taken its name), and a new definition that reuses its name does not inherit it. A target that no longer resolves returns the error plus `orphaned`: the unattached notes written against that name. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `target` (string, required): A qualified name, a bare name (`helper`, `Store.get`), or `path:line` (the path relative to the repository root, or absolute inside it; a trailing `:col` is ignored).

### `importers` (~213 tokens)

Modules that import a module, with each import statement's line, column, bound alias and imported symbol. Direct importers only, unless `through_reexports` is true: then also the modules that reach it through a re-export (a package `__init__.py`, a Rust `pub use`, an `index.ts` barrel), each row with `via`, the import statements it came through, consumer side first (empty for a direct importer). Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `module_qualified_name` (string, required): The module's qualified name (for example `myproj.pkg.util`).
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `through_reexports` (boolean): Also list the modules that reach it through re-exports (default false).

### `tests_reaching` (~139 tokens)

Test functions and methods from which a qualified name is reachable through CALLS / REFERENCES / INSTANTIATES, with the distance and the symbol each test reaches it through: what to run after editing it. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `qualified_name` (string, required): Fully qualified name (e.g., 'app.services.UserService.create_user')

### `endpoints` (~162 tokens)

The endpoints a project exposes (routes, RPC methods, dispatch keys), one row per endpoint with its identity (`GET /users/{id}`), kind, handler, file and how many call sites in the whole graph reach it through RESOLVES_TO or a direct access. Zero callers on a graph holding only this project means none are indexed, not that the endpoint is dead; index the calling services with `--capture io` first. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.

### `endpoint_callers` (~281 tokens)

Call sites, in any indexed project, that reach one endpoint: `target` is the handler's qualified name or the endpoint identity (`GET /users/{id}`), whichever parameter syntax the route declares (`:id`, `<id>`); a concrete request (`GET /users/42`) matches the routes it is served by. A target that names no endpoint the project exposes is refused with the close identities and handlers, so an empty list means nothing reaches it. Each row names the caller, its file, the URL it accesses and the direction (READS_FROM or WRITES_TO); an RPC or dispatch caller reaches the endpoint directly, so its `url` is the endpoint identity. Literal URLs resolve; dynamic ones do not and are absent here. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `target` (string, required): The handler's qualified name, or the endpoint identity (`GET /users/{id}`) in any path-parameter syntax (`{id}`, `:id`, `<id>`), or a concrete request (`GET /users/42`).

### `remote_dependencies` (~128 tokens)

Every network access a project makes, one row per call site and URL, with the endpoint, handler and project it resolves to when one is indexed; a row with no endpoint is a dependency the graph cannot place (a dynamic URL, or a service not indexed). Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.

Input parameters:

- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.

### `rename` (~328 tokens)

Rename a function, method, class or other definition everywhere the graph knows it is referenced: the definition, every call, reference and instantiation site, import statements (aliases kept), overrides in both directions, and Python `__all__` entries. Refuses when any site was resolved heuristically, by overload fan-out, or only by a trace, unless `allow_heuristic` is true. It also refuses when the source names the symbol where the graph has no site (a call the index missed), listing those occurrences as `unplanned`; `allow_heuristic` rewrites them as guessed sites. A class referenced by an inheritance or type annotation edge that carries no rewrite location refuses regardless of `allow_heuristic`. Every rewritten file must still parse; otherwise nothing is written. Set `dry_run` to see the plan and diff without touching the tree. Applied edits are recorded for `cgr edits undo`, and Markdown mentions of the old name are listed for a human to review.

Input parameters:

- `allow_heuristic` (boolean): Rewrite through heuristic, overload and trace-only sites, and the unplanned occurrences the graph has no site for, too (default false).
- `dry_run` (boolean): Plan only: report the sites and diff, write nothing.
- `new_name` (string, required): The new identifier.
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `qualified_name` (string, required): Fully qualified name (e.g., 'app.services.UserService.create_user')

### `change_signature` (~417 tokens)

Change a Python or JavaScript function's or method's parameter list and rewrite every call site the graph knows, on the definition and on every override in both directions. `new_params` lists the new parameters in order (`n: int`, `limit: int = 10`, or a bare old name to carry it over unchanged). `mapping` says where each new parameter's value comes from at a call site: an old parameter's name, its 0-based index, or `=literal` to insert that text at every site; a new parameter absent from the mapping takes the old parameter of the same name. A site the mapping cannot complete (a missing required value, a splat, a surplus argument, an undeclared keyword) or that the graph resolved heuristically is left as written and listed as `unmapped`; pass `allow_heuristic` to rewrite guessed sites too. Every rewritten file must still parse, and with an indexed project the change is undone when its postcondition fails. Set `dry_run` to see the plan and diff without touching the tree. Applied edits are recorded for `cgr edits undo`.

Input parameters:

- `allow_heuristic` (boolean): Rewrite through heuristic, overload and trace-only sites, and the unplanned occurrences the graph has no site for, too (default false).
- `dry_run` (boolean): Plan only: report the sites and diff, write nothing.
- `mapping` (object): Optional. New parameter name to its source: an old parameter name, a 0-based old index, or `=literal`.
- `new_params` (array, required): The new parameter list in order, one entry per parameter (`name`, `name: type`, `name = default`, `name: type = default`).
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `qualified_name` (string, required): Fully qualified name (e.g., 'app.services.UserService.create_user')

### `context` (~216 tokens)

A graph-ranked minimal context slice for a task, within a token budget. `target` is a qualified name, a bare name, `path:line`, or free text (matched by embedding similarity when the semantic extra is installed). Returns the target's source, its direct callers' call lines, its direct callees' signatures, the types it accepts and returns, the tests that reach it, and the documentation sections whose file links to it, ranked by graph distance (trace hotness and similarity break ties) and trimmed to `budget_tokens`. Every piece says why it is included. Use this before reading whole files.

Input parameters:

- `budget_tokens` (integer): Token budget for the slice (default 4000).
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `target` (string, required): A qualified name, a bare name (`helper`, `Store.get`), `path:line`, or a free-text description of the task.

### `query_code_graph` (~204 tokens)

Prefer the deterministic tools (resolve, definition, callers, callees, implementors, overrides, importers, tests_reaching) when you know the exact name or location: they run fixed queries with no LLM. Use this for open-ended questions. Query the codebase knowledge graph using natural language. Ask questions like 'What functions call UserService.create_user?' or 'Show me all classes that implement the Repository interface'. Pass `project` to restrict results to one indexed project; use list_projects for the available names. Omit it to search them all. The scope is enforced on the results before they are capped, so it holds regardless of the query generated and the result limit is spent on rows from the requested project.

Input parameters:

- `natural_language_query` (string, required): Your question in plain English about the codebase
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.

### `get_code_snippet` (~63 tokens)

Retrieve source code for a function, class, or method by its qualified name. Returns the source code, file path, line numbers, and docstring.

Input parameters:

- `qualified_name` (string, required): Fully qualified name (e.g., 'app.services.UserService.create_user')

### `surgical_replace_code` (~182 tokens)

Surgically replace an exact code block in a file using diff-match-patch. Only modifies the exact target block, leaving the rest unchanged. After a successful write on an indexed project, the touched files are re-ingested and a structural delta is appended to the result as JSON: symbols added, removed and renamed, callers left dangling, call sites passing too many arguments, signature changes with a verdict per call site, new duplicates of existing functions, new import cycles, and the tests reaching the edited symbols. A project that is not indexed appends nothing, and a failed analysis appends an error note instead of a delta. Read it before the next edit.

Input parameters:

- `file_path` (string, required): Relative path to the file from project root
- `replacement_code` (string, required): New code to insert
- `target_code` (string, required): Exact code block to replace

### `read_file` (~73 tokens)

Read the contents of a file from the project. Supports pagination for large files.

Input parameters:

- `file_path` (string, required): Relative path to the file from project root
- `limit` (integer): Maximum number of lines to read (optional)
- `offset` (integer): Line number to start reading from (0-based, optional)

### `write_file` (~154 tokens)

Write content to a file, creating it if it doesn't exist. After a successful write on an indexed project, the touched files are re-ingested and a structural delta is appended to the result as JSON: symbols added, removed and renamed, callers left dangling, call sites passing too many arguments, signature changes with a verdict per call site, new duplicates of existing functions, new import cycles, and the tests reaching the edited symbols. A project that is not indexed appends nothing, and a failed analysis appends an error note instead of a delta. Read it before the next edit.

Input parameters:

- `content` (string, required): Content to write to the file
- `file_path` (string, required): Relative path to the file from project root

### `list_directory` (~36 tokens)

List contents of a directory in the project.

Input parameters:

- `directory_path` (string): Relative path to directory from project root (default: '.')

### `find_duplicate_code` (~234 tokens)

Finds structurally duplicated functions and methods (copy-pastes, including renamed and lightly edited copies) by comparing AST fingerprints stored in the graph. Returns clone groups with file:line locations, largest first: 'exact' groups are certain copies, 'similar' pairs carry a branch-overlap score. Use it to answer DRY questions ('where is this logic repeated?') and before writing a new helper to check whether an implementation already exists. Tune with 'threshold' (0-1 similarity, default 0.8) and 'min_size' (skeleton nodes, filters trivial getters).

Input parameters:

- `limit` (integer): Max number of duplicate groups to report (default: 20)
- `min_size` (integer): Minimum skeleton nodes a function must have to be considered, which filters trivial getters (default: 15)
- `project` (string): Optional. Restrict results to one indexed project; use list_projects for the available names. Omit to search every project.
- `threshold` (number): Similarity threshold between 0 and 1 for 'similar' groups (default: 0.8)

### `get_function_source` (~57 tokens)

Retrieves the source code for a specific function or method using its internal node ID, typically obtained from a semantic search result.

Input parameters:

- `node_id` (integer, required): Internal graph node id of the function or method, as returned by semantic_search results

### `ask_agent` (~74 tokens)

Ask the Code Graph RAG agent a question about the codebase. Uses the full RAG pipeline to analyse the code graph and provide a detailed answer. Use this for general questions about architecture, functionality, and code relationships.

Input parameters:

- `question` (string, required): A question about the codebase, architecture, functionality, or code relationships

### `flow_verdict` (~261 tokens)

Answer a source-to-sink data-flow reachability question with one of three verdicts: FOUND (a FLOWS_TO path exists, returned as qualified names), NO_FLOW (no path, and every module of the project was inside flow-analysis coverage), or UNKNOWN (no path found, but part of the project sits outside coverage; the uncovered files are named). An absent path must never be read as a verified absence when coverage gaps exist. The path may cross a service boundary: a NETWORK resource that resolves to another project's endpoint continues into that handler, `remote_hops` lists the (from, to) pairs where it does, and the coverage of every project entered counts towards the verdict. A source or sink that is not in the graph, or a source of another project, is refused with an error rather than answered. FLOWS_TO coverage requires indexing with the `io` capture group. For an MCP server, set `CGR_CAPTURE=io` in the server environment before running index_repository or update_repository, then reindex after changing it.

Input parameters:

- `sink_qualified_name` (string, required): Qualified name of the flow sink (function/method)
- `source_qualified_name` (string, required): Qualified name of the flow source (function/method)

### `explain_traceback` (~358 tokens)

Correlate a Python traceback with the code graph: each frame is resolved to its Function/Method/Module node and returned with its graph neighbourhood (callers, callees, and FLOWS_TO sources feeding it). FLOWS_TO sources require indexing with the `io` capture group. For an MCP server, set `CGR_CAPTURE=io` in the server environment before running index_repository or update_repository, then reindex after changing it. Frames outside the repository or unknown to the graph carry an unresolved reason instead. A traceback from another checkout (a CI runner, a container, a teammate's machine, Windows) is matched by the checkout root its frames share, reported as inferred_checkout_root; pass path_prefix_map when that root cannot be inferred. When nothing resolves, note says why. For an ExceptionGroup, frames is the stack that raised the group, and members holds each sub-exception (nested groups included) with its own frames; omitted_members counts those the traceback itself left out. Use this to ground a failure report in the indexed code before deciding where to look.

Input parameters:

- `path_prefix_map` (object): Optional. Maps the checkout root the traceback was recorded under to a directory of the indexed repository, e.g. {"/app": "."} or {"/usr/lib/python3.12/site-packages": "src"}. Needed only when the ro…
- `traceback_text` (string, required): The traceback text exactly as Python printed it (the 'Traceback (most recent call last):' block; chained tracebacks are fine, the final propagated section is used, and an ExceptionGroup's sub-excepti…

### `rank_root_causes` (~413 tokens)

Rank the sites that can explain a Python traceback's failure, best first. The anchor (failing) is the innermost frame the graph resolves; anchor_is_crash_site is false when the actual crash line sits deeper (a library frame, or a frame the graph cannot match), so the ranking reads as relative to the deepest resolvable frame. Candidates score by three additive signals: being a FLOWS_TO source into the failing frame (a possible producer of the failing value), sitting on the crashing stack itself, and reaching the failing frame through CALLS edges (closer callers score higher). Each candidate carries its file, definition line, reasons, and the call path to the failure. When the project has no FLOWS_TO edges the ranking degrades to a CALLS-only walk and flow_used is false; flow_gaps always names the files outside flow-analysis coverage. FLOWS_TO coverage requires indexing with the `io` capture group. For an MCP server, set `CGR_CAPTURE=io` in the server environment before running index_repository or update_repository, then reindex after changing it. Frames from another checkout resolve as in explain_traceback, and resolution plus note say why a ranking is empty. For an ExceptionGroup, the ranking anchors where the group was raised, and members ranks each sub-exception against its own failing frame.

Input parameters:

- `path_prefix_map` (object): Optional. Maps the checkout root the traceback was recorded under to a directory of the indexed repository, e.g. {"/app": "."} or {"/usr/lib/python3.12/site-packages": "src"}. Needed only when the ro…
- `traceback_text` (string, required): The traceback text exactly as Python printed it (the 'Traceback (most recent call last):' block; chained tracebacks are fine, the final propagated section is used, and an ExceptionGroup's sub-excepti…

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/vitali87-code-graph-rag/code-graph-rag#diagnostics

## Score history

- 2026-11-05: 79
- 2026-11-04: 64
- 2026-11-03: 78
- 2026-11-02: 63

## Common questions

### What is the Code-Graph-RAG MCP server?

Code-Graph-RAG is an MCP server listed in the public MCP registry as io.github.vitali87/code-graph-rag. Knowledge-graph RAG for multi-language codebases: index, query and edit code in natural language. This page covers its PyPI package (code-graph-rag).

### Is the Code-Graph-RAG MCP server safe to use?

Code-Graph-RAG scores 79 out of 100 on VerifyMCP. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Code-Graph-RAG MCP server expose?

Code-Graph-RAG exposes 34 tools: list_projects, delete_project, wipe_database, index_repository, update_repository, and 29 more. Their descriptions and schemas cost roughly 6,508 tokens of context every time the server is loaded.

### Is the Code-Graph-RAG MCP server still maintained?

Code-Graph-RAG is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Code-Graph-RAG MCP server under?

Code-Graph-RAG declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/code-graph-rag/
- Socket report: https://socket.dev/pypi/package/code-graph-rag
- Repository: https://github.com/vitali87/code-graph-rag
- Website: https://code-graph-rag.com/
- Changelog RSS feed: https://verifymcp.io/servers/vitali87-code-graph-rag/code-graph-rag.xml
- Changelog JSON feed: https://verifymcp.io/servers/vitali87-code-graph-rag/code-graph-rag.json
- HTML version of this page: https://verifymcp.io/servers/vitali87-code-graph-rag/code-graph-rag