CodeGraph MCP alternative: trace-mcp vs codegraph

TL;DR. codegraph is the largest project in this field by stars, and it made one design decision that is worth understanding before you compare anything else: it defines eight MCP tools and advertises exactly one of them. Everything an agent can ask it goes through codegraph_explore. The reasoning, stated in its own source, is that the other seven are narrower slices of explore and that the mere presence of a tool steers agents into mis-picking it.

trace-mcp bets the other way. It advertises 28 tools on its default preset — navigation, impact analysis, refactoring, security scanning, code-linked memory — because those are genuinely different operations, not slices of one.

Pick codegraph if the job is orient an agent in a repository it has never seen, and you want that to cost almost nothing in advertised schema. Pick trace-mcp if the job continues after orientation.

Head-to-head

Capability	trace-mcp	codegraph
GitHub stars	175	70.5K
License	MIT	MIT
Languages	81 (tree-sitter)	34 (tree-sitter, Rust kernel + WASM fallback)
Framework integrations	✓ 88	✓ 17 (route → handler)
Framework edges beyond routing	✓ controller → template, model → table, component → component	partial — route → handler, plus React Native component/property nodes
Cross-language edges	✓	✓ Swift ↔ ObjC, RN bridge / TurboModules / Expo / Fabric
MCP tools defined	182	8
MCP tools advertised by default	28 (~11.6K tok)	1 (codegraph_explore)
Rest of the surface reachable	✓ load_tools, one call	✓ CODEGRAPH_MCP_TOOLS env allowlist, restart
Persistent graph across restarts	✓ SQLite + FTS5	✓ SQLite
Runs fully local, no API key	✓	✓
Incremental re-index on save	✓	✓ debounced file watcher
Impact analysis	✓ reverse traversal + decorator filter	✓ codegraph_impact (behind the allowlist)
Refactoring tools	✓ rename, move, signature, AST codemod, extract	✗
Security scanning	✓ OWASP Top-10, type-aware taint	✗
Control-flow / data-flow	✓ CFG with basic blocks and loop back-edges	✗
SARIF / CI output	✓ 2.1.0, schema-validated	✗
Session memory	✓ code-linked decision graph	✗
Multi-repo	✓ cross-repo API linking into one graph	partial — queries other separately-indexed projects by path
Graph visualization	✓ desktop app	✗
Published A/B token benchmark	✗ per-repo get_real_savings instead	✓ 7 repos, methodology disclosed
Written in	TypeScript	TypeScript + Rust kernel

Verified on August 29, 2026 against codegraph’s source and README at commit 6a056ec — the main head, shipped after the v1.6.0 tag. Tool-surface claims come from the source; language, framework and bridging counts come from the README’s own tables, which the source directory layout corroborates.

When to pick codegraph

• Your agent’s expensive problem is orientation, not editing. codegraph’s own benchmark shows its largest wins exactly where an agent would otherwise burn a big slice of budget on find/grep/read before touching the right file — 2 tool calls against 28 on VS Code, 2 against 43 on Excalidraw, zero file reads in both. If most of your sessions are “understand this unfamiliar codebase”, that is the shape of win you are buying.
• You want the cheapest possible advertised surface. One tool. Nothing else is listed to the model at all. Our 28-tool default is real money next to that, paid on every session by every client that does not defer tool loading.
• You want a published benchmark you can argue with. codegraph reports 88% fewer tool calls, 62% fewer tokens, 44% lower cost and 53% faster across seven repositories, and it discloses the model, the queries, four runs per arm, and a correction to an earlier version of its own harness that had let the control arm reach CodeGraph through the shell. It is self-run, not independently reproduced — but it is the most transparent self-benchmark in this field, and it is more than we publish.
• Indexing speed on very large trees matters. A native Rust extraction kernel with per-language tree-sitter grammars, a WASM fallback for unbuilt platforms, and cgroup-aware resource scaling for small VPS boxes is a different engineering investment than a TypeScript-only parser, and their reported numbers on the Swift compiler and the Linux kernel reflect it.
• Popularity. codegraph is roughly 670× larger by stars, with the community answers and integrations that follow from that.

When to pick trace-mcp

• The job goes past navigation. Rename across a repo, move a symbol with its imports, an AST codemod, a taint scan with type-aware pruning, quality gates, SARIF for CI, dead-code removal. codegraph has none of these, by design and by its own README’s scope.
• The edges you care about are framework edges beyond routing. codegraph links URL patterns to their handlers across 17 frameworks, and does it well; its React Native work also emits component and property nodes. It does not model controller → template or model → table. trace-mcp’s 88 integrations do, and traverses them.
• Your stack is polyglot. 81 grammars against 34.
• You want memory that outlives the session and is tied to code. trace-mcp’s decisions link to symbol IDs, are verified as non-stale before recall, and surface inside get_change_impact. codegraph has no session memory at all.
• You want the other tools without an env var and a restart. codegraph’s seven unlisted tools are fully implemented and re-enablable through CODEGRAPH_MCP_TOOLS; that is a config change, not something the agent can decide mid-task. trace-mcp’s deferred surface is one load_tools call away inside the session.

Where we are not being smug

Four honest points.

Their default surface is cheaper than ours and it is not close. One advertised tool against our 28 and ~11.6K tokens. Our number is down from ~50K after the preset bypass on the daemon path was fixed and the default preset moved to minimal, and everything outside it is one call away — but “much better than we were” is not “as cheap as theirs.”

Their benchmark covers more of the job than ours does. Both projects now publish an A/B across named repositories with a disclosed harness — theirs across seven repos and a broad slice of session work, ours the PR review context benchmark: a median 72.7% input-token reduction over 60 merged pull requests in 6 repositories nobody here maintains, with the losing cases and the re-run command shipped in the repo. Theirs covers the wider workload; ours publishes the revisions it ran on and the five cases where it lost. Both run on repositories their authors do not maintain — that is not a point of difference, and this page said otherwise until September 5, 2026. One task type measured well is not the same as a general claim. For everything else we now publish 67.4%, measured on 18329 real tool calls from one machine against a baseline that is still an estimate — it replaced an aggregate that turned out to be arithmetic on a constant, and why it moved is published too.

They publish their own downside, so we will repeat it rather than quietly use it. codegraph’s README states that its responses leave roughly 80% more retrieval context resident at the end of a multi-turn session than a file-reading agent’s do — 67K tokens against 18K on VS Code. That is a genuine cost of returning rich graph answers, it is a cost trace-mcp pays in its own form, and the fact that they printed it is a point in their favour.

Our security scanning has a ceiling, and it is stated on the comparisons page rather than only here. The control-flow graph is line-based, not AST-based, and taint analysis is lexical/regex, not a real dataflow engine. Type-aware pruning cuts false positives; it does not turn this into a dataflow analyser. A full AST/dataflow rewrite is out of scope for now.

If you maintain codegraph and something here is wrong, open an issue and we will fix it.

FAQ

What is the core difference between codegraph and trace-mcp? codegraph defines eight tools and advertises one, on the reasoning that the rest are narrower slices of explore and that presence itself steers mis-picks. trace-mcp advertises 28 and keeps ~140 more one load_tools call away, because refactoring, security scanning and memory are not slices of navigation.

Does codegraph have a smaller tool surface than trace-mcp? Yes, substantially — one advertised tool against 28 and ~11.6K tokens. That is a cost we pay every session and they do not. What it buys is a much wider set of operations addressable without an env-var opt-in and a restart.

Can codegraph do refactoring or security scanning? No. Reading its source on August 29, 2026 found no rename/move/codemod, no taint analysis, no control-flow graph, no SARIF and no cross-session memory. It is a navigation and discovery tool, and scopes itself that way.

Whose token-savings numbers are better supported? Both publish one. Theirs: seven repositories, model and queries named, four runs per arm, a documented fix to a flaw in their own earlier harness — 62% fewer tokens, 44% lower cost. Ours: the PR review context benchmark, a median 72.7% input-token reduction across 60 merged pull requests in 6 repositories we do not maintain, with base and head SHAs, the five cases where it lost, and one command to re-run it. Theirs covers more of a session; ours is the more auditable. Both run on code their authors do not maintain, and neither is third-party reproduced.

Do either of them send code to a cloud service? No. Both index locally into SQLite, need no API key, and survive restarts.

Next steps

• Learn how a persistent code graph reduces token costs on every turn: Code graph MCP server.
• Full field: how trace-mcp compares against 20+ code-graph and memory MCP servers.
• The other head-to-heads: vs Repomix · vs Serena · vs codebase-memory-mcp · vs CodeGraphContext · vs SocratiCode · vs jCodeMunch · vs TokenSave · vs GitNexus · vs Context Mode · vs code-review-graph · vs Narsil-MCP
• Comparing codegraph against something other than us: Repomix vs codegraph — indexing against packing, on their own terms.
• Architecture — how the indexing pipeline, storage and LSP enrichment fit together.
• Get started — no configuration required.

Last updated: September 16, 2026