Which React screens break if you change this C# handler? Claude Code doesn't know. Fix that.

Three levels of understanding code:

• text (grep/embeddings) finds what looks similar
• syntax (tree-sitter) sees structure but can't resolve which method a call actually hits
• semantics (Roslyn) resolves calls through interfaces, DI, and generics

Slnmap is the third level — the only one where "what breaks if I change this?" has a correct answer. And unlike your IDE's internal understanding, it's exposed as tools your AI agent can query before it edits.

Yes — the CLI and MCP server are MIT-licensed, and they'll stay that way. Future hosted or team-oriented features may be commercial. Star or contribute on GitHub.

Fifteen read-only MCP tools your agent can call — two of them cross-stack:

• find_orphan_calls — frontend call sites with no matching endpoint, grouped by exact reason (no-match, verb-mismatch, verb-unknown).
• list_frontend_callsites — every React/TS HTTP call site with its live linking status.
• find_symbol — locate a type or member by name anywhere in the solution.
• get_dependencies — see what a given symbol depends on.
• impact_analysis — what breaks if you change a symbol: every caller and implementation, across projects — and, once slnmap link has run, every React call site downstream of the C# handler it hits.
• list_endpoints — every HTTP endpoint your solution registers (Minimal APIs and attribute-routed controllers), grouped by project, filterable by verb or route prefix.
• find_endpoint — the endpoint that handles a route or a concrete request path, like /api/vendors/42 — plus which frontend call sites hit it.
• get_architecture_overview — the projects and how they depend on each other.
• find_usages — everywhere a symbol is used.
• find_implementations — who implements an interface or overrides a member.
• get_type_hierarchy — the base and derived type tree.
• find_tests_for_symbol — which tests exercise a symbol.
• get_project_dependencies — the project reference map, with the most-coupled hotspot.
• find_circular_dependencies — dependency cycles between projects or namespaces.
• get_symbol_source — the actual source of a symbol, straight from the graph's stored location.

Run slnmap watch (new in v0.10) — it analyzes once, keeps the compiler workspace warm, and re-analyzes on every file save. On eShopOnWeb (10 projects), a one-file change lands in the graph in about a second: re-analyzed in 0.93s, saved in 0.17s — versus paying a full workspace reload for each run-and-exit slnmap analyze. Run slnmap serve beside it and your agent's answers stay fresh while you type. Structural changes (csproj/sln) trigger an announced full reload — membership is never guessed. Prefer one-shot? slnmap analyze still re-walks only changed files without dropping edges owned by files it didn't touch, and upgrading the tool triggers a one-time full rebuild automatically. Either way your queries stay instant — the graph is already on disk.

No — every tool response is token-budgeted by design. Summaries first, drill-down on demand. The point is to give your agent structure instead of flooding it with source.

No. Analysis runs locally and the graph lives on your machine. No cloud, no telemetry on your code. Ever.

The tool itself runs on the .NET SDK 9.0+, and analyzes C# solutions targeting .NET 8 and 9 (earlier targets are untested — feedback welcome). analyze-ts additionally requires Node 18+ and analyzes React/TypeScript frontends. More languages and frameworks based on user feedback.

HTTP endpoints are extracted from ASP.NET Core Minimal APIs (including MapGroup prefixes and the CleanArchitecture-template MapGroup(this) convention) and attribute-routed controllers (including [controller]/[action] tokens and inherited [Route] from base controllers).

This audience trusts disclosed limits more than feature lists, so here they are:

• Blazor & Razor Pages — conventional routing and Razor Pages are detected and disclosed, not modeled; .razor markup is counted (file totals only) but not analyzed (#30).
• MediatR-style dispatch — runtime request/handler dispatch isn't traced; impact_analysis/find_usages stop at the request record, correctly not claiming a link they can't see — walk through the record to reach the handler.
• Angular & Vue HTTP clients — call sites on clients besides axios and fetch (Angular's HttpClient included) are honestly disclosed as unresolved, never silently dropped or guessed at.
• Monorepos — single, flat tsconfig.json frontends are field-verified; project-references/monorepo tsconfigs aren't yet — point analyze-ts at each package individually in the meantime.

Any MCP client can connect — it's a standard MCP server over stdio. Claude Code is first-class and what it's tested with; Cursor and other MCP clients use the same server.

Right now — it's v0.12.2, free and open source (MIT). Install from NuGet today and connect it to Claude Code in a few minutes. No signup, no waitlist.