recon_changes
Git diff → affected symbols → risk assessment → affected tests.
WHEN: Before commit, or reviewing a PR. NOT: No changes have been made yet. THEN: Fix issues, then commit.
LABSCO SUMMARY
It answers the questions grep structurally cannot: who calls this symbol, what breaks if it changes, which tests cover it, and where the cross-language edges run.
The tools are laid out as a sequence rather than a menu — recon_map to orient, recon_find to locate, recon_explain for context, recon_impact before the edit, recon_changes after it — and each one names the call that follows, which makes the server navigable without reading documentation first. recon_rename writes to files and is meant to be run with dry_run before it is run for real; the difference between it and a find-and-replace is precisely that recon_rename works from the reference graph. recon_rules earns its place separately, since dead code, circular dependencies and unused exports are findings a graph produces cheaply and a reader of the source produces slowly.
What it is
A code-intelligence server that builds a symbol graph over a repository and answers architecture, impact, rename and code-quality questions from that graph rather than from a text match.
What you get
- An orientation pass over an unfamiliar repository: recon_map returns the tech stack, packages, entry points and health for the repo you point it at.
- Lookup that takes whatever you actually remember: recon_find accepts an exact name, a wildcard such as *Handler, or a natural-language query, narrowed by language, package and type and capped by limit.
- The full surround of one symbol: recon_explain returns callers, callees, flows and cross-language links, resolved by name and file, walked to depth, with include_source pulling in the source itself.
- Change safety before the edit and after it: recon_impact reports what breaks if you change a target symbol and which tests are affected, walked in direction to maxDepth; recon_changes takes the git diff against base within scope and maps it to affected symbols, a risk assessment and affected tests, with include_diagram attaching a diagram.
- Renames that follow references rather than text: recon_rename rewrites a symbol across all files, with dry_run producing the plan before anything is written.
- Something to paste into the review: recon_export generates a Mermaid diagram of package, symbol and file relationships around a target, scoped by scope and direction, walked to depth and capped by limit.
- Codebase hygiene from the same graph: recon_rules flags dead code, circular dependencies and unused exports, selected by rule and narrowed by language and package.
Requirements
Nothing — no account, no key.
Setup effort
One command — npx recon-mcp serve
USE CASES
01
Getting oriented in a codebase you have never opened
Take the architecture overview first, locate the pieces you were told about, then read the context around whichever one matters.
02
Deciding whether a change is safe to make
Read what depends on the symbol before you touch it, and find out which tests are going to be the ones that catch a mistake.
03
Reviewing a pull request you did not write
Turn the diff into the set of symbols it actually moves, with a risk read and the affected tests, then generate a diagram to reason about it.
04
Renaming something referenced in places you cannot remember
Produce the plan first, check what the rename would touch and what it would break, then run it for real.
05
Clearing out what nothing calls any more
Ask the graph for dead code, circular dependencies and unused exports, then confirm each finding before deleting anything.
8 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
recon_explain
Full 360-degree context of a symbol: callers, callees, flows, cross-language links.
WHEN: You need to understand a function/class before modifying it. NOT: You just need to read the source code (use Read tool). THEN: recon_impact if you plan to change it.
recon_export
Generate Mermaid diagram of package/symbol/file relationships.
WHEN: Need visual representation for documentation or understanding. NOT: Just need a list of packages (use recon_map). THEN: Paste diagram in PR or docs.
recon_find
Smart search: exact name, wildcard (*Handler), or natural language.
WHEN: Looking for a symbol, function, class, or pattern. NOT: You already know the symbol name and need full context (use recon_explain). THEN: recon_explain for details on a result.
recon_impact
Blast radius: what breaks if you change this symbol, including affected tests.
WHEN: Before modifying any exported function or shared type. NOT: Just exploring (use recon_explain first). THEN: Make the change, then recon_changes to verify.
recon_map
Architecture overview: tech stack, packages, entry points, health.
WHEN: First time in a codebase, or need to recall architecture. NOT: You need details about a specific symbol (use recon_explain). THEN: recon_find to locate specific symbols.
recon_rename
Graph-aware safe rename across all files. Always dry_run first.
WHEN: Renaming a symbol and want to catch all references. NOT: Simple text replacement in one file (use Edit tool). THEN: Review plan, then run with dry_run: false.
recon_rules
Code quality analysis via knowledge graph: dead code, circular deps, unused exports.
WHEN: Reviewing code quality, cleaning up, or auditing architecture. NOT: Looking for a specific symbol (use recon_find). THEN: recon_explain on flagged items for context.
BEFORE YOU INSTALL
What to know first
Tools you get
8 tools when we connected.
Requires
Node.js ≥ 20
Where it runs
Both documented clients run the server on your machine.
CONTEXT COST
Light Standing cost
Rated by the size of the 8 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Server setup
TERMINAL
npx recon-mcp serveMCP Clients
Claude Code, Cursor
JSON
{
"mcpServers": {
"recon": {
"command": "npx",
"args": [
"recon-mcp",
"serve"
],
"cwd": "<YOUR_PATH_TO_PROJECT>"
}
}
}
