I built an interactive HTML export for .NET dependency graphs, because my AI agent kept guessing wrong

Mahmoud Nabil — Mon, 27 Jul 2026 16:10:29 +0000

Every time I asked Claude Code or Copilot something like "what breaks if I rename this method" on a mid-sized .NET solution, it would grep through files, miss call sites that go through interfaces, and burn a lot of tokens getting a partial answer. On a solution with a few dozen projects, that's slow and often just wrong: the agent doesn't see the whole picture, so it can't reason about it correctly.

That's the problem Slnmap is built to solve. It uses Roslyn (the actual C# compiler) to build a semantic graph of your solution, stores it locally in SQLite, and exposes it over MCP so any compatible agent can query it directly instead of guessing from whatever files happen to be open.

The part I actually use the most: `slnmap viz`

Tool calls are great for agents. They're not great for me, sitting there wondering what an unfamiliar codebase actually looks like before I start asking an agent to change it.

So Slnmap also ships a viz command that exports the whole graph as a single self-contained HTML file. No server, no account, no CDN calls. Open it in a browser, pan and zoom, click a symbol, and see everything connected to it collapse into view.

slnmap viz --project MyProject.csproj

The reason this matters more than it sounds: it's the one artifact in this whole workflow that isn't just for the agent. You can drop the HTML file in a PR description, or send it to a teammate who doesn't have the repo checked out, and they get the same interactive view you do. Every other Roslyn-based MCP server I looked at while building this outputs data for an agent to consume. None of them give you something to look at.

A concrete example

Say you're about to touch IBasketService. Instead of grepping five files and hoping you found every caller, you ask the agent (or run the query yourself):

"What breaks if I change IBasketService?"

Slnmap follows both the interface's callers and its concrete implementations, across every project in the solution, in one query. On eShopOnWeb (10 projects), querying an interface with 18 dependents comes back in about 270ms end-to-end over MCP (median of 3 runs — full methodology is in BENCHMARKS.md if you want to check the setup yourself).

Why the tool surface is small on purpose

If you go looking, there are a few other Roslyn-based MCP servers out there, some with a much larger surface of tools than Slnmap's. I went the other way on purpose. Every tool Slnmap exposes is read-only and narrow — find a symbol, trace its callers, check impact, list implementations — on the bet that an agent (or a person) gets more value from a small set of tools that answer a specific question well than from a large API surface that tries to do everything.

I'll be honest: I don't know yet whether that bet holds up as codebases and usage scale. It's a real open question, not a marketing line.

What it doesn't do

It doesn't call out anywhere. Slnmap reads your source with Roslyn and writes one local SQLite file — nothing else. It's open source now, so that's not just a claim: you can read the code or watch the process yourself and confirm nothing leaves the machine.

It also doesn't guess. Every answer comes from the compiler's own understanding of your code, not from string matching or heuristics on the source text — which is the same reason it catches call sites that go through an interface instead of missing them like grep does.

Try it

dotnet tool install --global Slnmap
slnmap analyze path/to/YourSolution.sln

Then point any MCP-compatible client at it (Claude Code, Cursor, etc.) — setup instructions are in the README.

Repo: https://github.com/EMahmoudNabil/slnmap
NuGet: https://www.nuget.org/packages/Slnmap
Site: https://slnmap.dev

It's MIT licensed. If you've hit the "grep vs. semantic index" tradeoff yourself, or tried the narrow-tools-vs-many-tools design in a different direction, I'd genuinely like to hear how you approached it.