Why not something else?
Several MCP servers now turn a repository into a queryable graph. They overlap, but they are not solving the same problem. This page says what each one is better at, including the ones that are better than Code-Crawler at the thing you may care about most.
The short answer
If you need many languages, pick one of the tree-sitter projects below: they index well over a hundred file formats and Code-Crawler indexes four. If you want the graph pushed into context automatically rather than queried, that is also not what this is. Code-Crawler is aimed at a narrower claim: inside JVM and framework-heavy code, the edges should describe what actually runs, and every edge should admit how sure it is.
| Tool | Choose it when | Choose Code-Crawler when |
|---|---|---|
| codebase-memory-mcp | You need breadth: its README states 162 languages and formats, a pure-C native backend, hybrid LSP type resolution for a dozen languages, a 3D explorer, and channel detection for Socket.IO, EventEmitter and generic pub-sub across eight languages. It is a far larger project than this one. | You are tracing Spring or CDI wiring specifically and want the result reported per edge with a confidence value and a benchmark of where that confidence is justified. |
| code-cortex-mcp | You want the graph delivered as context by a hook instead of as tools the agent decides to call. Its README states 155 languages on tree-sitter and reports wall-clock savings over shell tools. | You want the agent to ask a question and get structured JSON back, including the confidence level and, when resolution fails, ranked candidates. |
| CodeGraphContext | You want a CLI as well as an MCP server, and you are willing to point it at an external graph database. Its database options are a feature we deliberately do not have. | You want a single SQLite file, no services, and no connection string in your agent's configuration. |
| mcp-code-graph | You want graph analysis and visualisation over a broad set of languages, with the visual surface as part of the product. | You want runtime wiring — dispatch, injection, advice, routes — as queryable edges rather than as a rendered picture. |
| grep, ripgrep, or plain file reading | The question is about text, not structure: a message key, a template string, a config value, a comment, a regex. Our own measurement shows the graph losing these cases, and the agent skill says to use search for them. | The question crosses files and hops: who calls this, what runs on this endpoint, what breaks if I change this. |
Where they are the better choice
Stated plainly, because pretending otherwise would be dishonest.
Not close
Code-Crawler indexes Java, Python, TypeScript and JavaScript. If you work in Go, Rust, C#, Kotlin, PHP or C++, a tree-sitter project indexes your code and this one does not. Four languages is a deliberate scope, not a roadmap promise.
Theirs
codebase-memory-mcp and CodeGraphContext have orders of magnitude more users, contributors and platform coverage. If you need something load-bearing today with an installer for every editor, start there.
Model difference
An agent that forgets to call a tool gets no value from it. A hook-based server that injects the graph on every search avoids that failure mode. Code-Crawler requires the agent, or its skill, to choose the graph.
Theirs
Dozens of client integrations, native installers and visual explorers are real work that this repository has not done.
Where Code-Crawler is different
Four claims, each one checkable with a command rather than with an adjective.
Every edge carries its confidence
A call resolved through a concrete receiver is not the same claim as a call resolved through an interface with one implementation. Both are returned, labelled differently, and the reason for the lower number is documented. Read the conventions.
Ambiguity returns candidates, not a guess
When an overload cannot be resolved, the edge is emitted with
resolved: false and the ranked alternatives attached. A named method
with no body — a Spring Data derived query, an interface method — stays
in the graph as what it is.
Accuracy is measured, and it is published with the misses
A pinned-commit benchmark suite runs in CI and fails the build when precision or recall regresses. The page reports the weak spots next to the strong ones. See the numbers.
Runtime wiring, not just syntax
Injection, advice, dispatch, routes and event channels are first-class edge kinds, derived in one place and rebuilt correctly on incremental crawls — with a test proving the invalidation.
What we don't claim
The limits of the evidence, so you can discount it correctly.
| Claim we avoid | Why |
|---|---|
| “More accurate than tool X.” | No head-to-head benchmark was run against any other tool on the same projects, so any such comparison would be invented. |
| “Precision and recall of 1.000 for real.” | Those figures are for 83 hand-labelled cases on four pinned repositories. They are a ratchet that catches regressions, not an estimate for your codebase. |
| “Framework X is supported.” | A framework or annotation is only claimed where a fixture exercises it and a test asserts the resulting edge. |
| “Exact runtime behaviour.” | The Java dispatch fixture is checked against a real recorded call log, but reflection, proxies and messaging are modelled from static evidence with confidence, not observed at run time on arbitrary projects. |
Check it yourself
Reproduce every number on this page, and compare against a competitor on the same repository rather than trusting either README.
npm ci
npm run bench:accuracy # precision / recall per edge kind
npm run bench:runtime # dispatch checked against a recorded call log
npm run bench:ergonomics # agent cost: graph vs grep-and-read
npm run docs:check # the counts on this site match the tool registry
The benchmark projects are pinned by commit in benchmarks/manifest.json.
Point another tool at the same commits and compare; that is the only comparison worth
reading.