trace-mcp

npm install -g trace-mcp   # MCP server, no app
trace init                 # wire it into your agent, once per machine
trace add                  # index the repo you are in

72.7% fewer input tokens to review a pull request — median over 60 merged PRs in six repos that are not ours, 13,595 → 3,291 per pull request. Method and reproduction →

Measured at trace-mcp 3.23.2 (cb8ab30c) on 7 September 2026 — a result from that build, not a claim about the current one. What it set out to measure, the bar it had to clear and the verdict: preregistration.

Cheaper is not the same as better, so the same 60 pull requests were reviewed twice and scored blind. The trace-mcp arm understood the change in 67% of them against 65% for naive file loading, at 0.80 false positives per PR against 0.58. Quality half of the benchmark →

---

The problem

AI agents pay repeatedly for work they have already done. Every turn, the agent re-reads the same files, re-traverses the same dependencies, and re-inflates the context window with structure it discovered five steps ago. That repeated work is most of what a long session costs in tokens and latency.

trace-mcp builds a framework-aware graph of your codebase once, then serves it through MCP so the agent reasons from a precomputed structure instead of brute-reading the repo. Ask "what breaks if I change this model?" — instead of 80 Grep calls and 190 file reads, the agent calls get_change_impact once and gets the blast radius across PHP, Vue, migrations, and DI. 88 framework integrations across 81 languages, 182 tools.

The binding constraint is recomputation, not model capability: token bills, latency, and hallucinations all grow with project size instead of with task complexity. trace-mcp closes the recomputation leak. The graph is built once, kept incrementally fresh, and served to every agent that asks — so the same work isn't paid for over and over.

• Lower cost — fewer tokens per successful answer, on average and at peak
• Lower latency — fewer sequential tool calls, fewer round-trips to the model
• Higher accuracy — less noise in context means fewer hallucinations and stronger first-response correctness
• Production stability — context growth tracks task complexity rather than repository size

We started with code intelligence, where the repetition is most expensive, and the same engine now indexes markdown knowledge vaults (Obsidian, Logseq, plain MD) as a peer domain. Wikilinks, tags, frontmatter, and embeds become graph edges and symbol metadata; search, find_usages, get_change_impact, and apply_rename work identically over both.

---

What trace-mcp does for you

You ask	trace-mcp answers	How
"What breaks if I change this model?"	Blast radius across languages + risk score + linked architectural decisions	get_change_impact — reverse dependency graph + decision memory
"Why was auth implemented this way?"	The actual decision record with reasoning and tradeoffs	query_decisions — searches the decision knowledge graph linked to code
"I'm starting a new task"	Optimal code subgraph + relevant past decisions + dead-end warnings	plan_turn — opening-move router with decision enrichment
"What did we discuss about GraphQL last month?"	Verbatim conversation fragments with file references	search_sessions — FTS5 search across all past session content
"Show me the request flow from URL to rendered page"	Route → Middleware → Controller → Service → View with prop mapping	get_request_flow — framework-aware edge traversal
"Find all untested code in this module"	Symbols classified as "unreached" or "imported but never called in tests"	get_untested_symbols — test-to-source mapping
"What's the impact of this API change on other services?"	Cross-subproject client calls with confidence scores	get_subproject_impact — topology graph traversal
"What notes link to this concept?"	Backlinks across the vault, with section + alias context	find_usages on a note:<basename> symbol
"What breaks if I rename this note?"	Every [[wikilink]] and [text](path.md) that references it	get_change_impact — wikilink-aware reverse graph

Four capabilities that are rare among adjacent tools:

1. Framework-aware edges — trace-mcp understands that Inertia::render('Users/Show') connects PHP to Vue, that @Injectable() creates a DI dependency, that $user->posts() means a posts table from migrations. 88 framework integrations.

2. Code-linked decision memory — when you record "chose PostgreSQL for JSONB support", it's linked to src/db/connection.ts::Pool#class. When someone runs get_change_impact on that symbol, they see the decision. MemPalace stores decisions as text; trace-mcp ties them to the dependency graph.