DEV Community: Prashant Patil

Six Problems. Six Decisions. How sharp-mcp Actually Works Under the Hood.

Prashant Patil — Sun, 21 Jun 2026 13:00:30 +0000

Two months ago I published my first article about sharp-mcp — a local MCP server that gives Claude real Roslyn-powered access to your C# codebase. That article introduced the what. This one is the why behind every decision.

I want to be direct about something first: I've been using sharp-mcp as my primary coding workflow for two months on real production work. Not demos, not toy projects — actual backend .NET development at my job. It has changed how I work completely. Every architectural decision I'm about to describe came from either hitting a real wall or refusing to accept a tradeoff I knew was wrong.

GitHub: https://github.com/patilprashant6792-official/sharp-mcp

💬 Follow the build and share feedback in GitHub Discussions

The starting point: focus

Claude Code, GitHub Copilot, Cursor — they're all built for every language, every ecosystem. That generality has a cost. When you're doing C# backend work, you're paying token overhead for abstractions built for Python, JavaScript, Ruby. I wanted something that only knows C#, only knows .NET, and uses that focus to do the job better than anything general-purpose ever could.

That decision — narrow focus over broad compatibility — is what every other decision flows from.

Problem 1: Direct file reading was the obvious first move — and it was broken

I started where everyone starts: read the file, pass it to the model. It worked. It was also impractically slow for any real codebase. Search latency was high, large files burned context fast, and it touched the real filesystem on every single request.

A 500-line service class costs ~2,000 tokens raw. Load ten files across a microservices solution and you've burned your entire context budget before writing a single line. That's not a tool, that's a handicap.

Direct file reading wasn't viable at scale — and that failure made the solution obvious: parse the structure once, cache it, and serve from memory.

Problem 2: Roslyn was the right answer, but it needed a home

Roslyn gives you a full AST — classes, methods, line spans, dependencies, everything structured. Instead of handing Claude a 500-line file, you hand it the API surface: class name, constructor dependencies, method signatures with exact line numbers. The model gets exactly what it needs to reason and nothing it doesn't.

But parsing on every request defeats the purpose entirely. The data needed to live somewhere fast.

Redis was the obvious choice. If you're a .NET backend developer, you already have Redis. It's not an exotic dependency — it's infrastructure you trust in production. The decision was: parse once with Roslyn on startup, serialize the AST metadata into Redis, serve every subsequent call in milliseconds with zero disk I/O.

Second call for any file: a Redis read. That's it.

Problem 3: NuGet hallucinations — the one nobody else is solving

This was the most painful problem to hit and the most interesting one to solve.

AI models generate correct-looking C# that doesn't compile because they don't know what's actually inside the NuGet packages you're using. System.Text.Json changed nullable handling between 6.0 and 8.0. EF Core changed DbContext configuration between 7.0 and 8.0. IgnoreNullValues was deprecated mid-lifecycle. The model confidently generates code against APIs that no longer exist in your version.

Documentation is incomplete. Training data is stale. The model guesses — and guesses wrong.

The fix: stop guessing entirely. Decode the binary.

MetadataLoadContext downloads the real .nupkg, resolves transitive dependencies, loads the DLL into an isolated context, reads the actual IL, and returns real signatures — real method names, real parameter types, real generics. No docs. No training data. The model gets the same ground truth the compiler uses.

Frontier LLMs can web search documentation for behavioral context whenever they need it. What they cannot do is know the exact method signatures in your specific package version. That's the gap. That's what this closes.

Token cost difference in practice:

What you're doing	Raw docs dump	sharp-mcp
Explore a namespace	~6,000 tokens	~250 tokens
Explore a class	~2,000 tokens	~400 tokens
Fetch one method	~2,000 tokens	~120 tokens

Over a full implementation session this compounds into hours of additional useful context.

Problem 4: The cache needs to stay warm

A cached Roslyn analysis is only useful if it reflects the current state of the file. This is the consistency problem that kills most caching approaches — you get speed, but you trade accuracy.

The solution: a FileSystemWatcher architecture that listens for file changes and automatically invalidates or updates the relevant cache entries. Every .cs file edit you make in Visual Studio propagates to the cache within 300ms — a debounce window that handles the burst of events VS fires on a single save.

Delete events evict the key. Rename events evict the old key and index the new path. A background indexer runs on startup and every 60 minutes to catch anything the watcher missed.

The result: global code search runs against warm cache data within seconds, without touching the real codebase. Claude always sees your code as it exists on disk right now — never stale. This is what makes long feature implementation sessions practical.

Problem 5: Claude.ai needs a bridge to localhost

An LLM running over the web can't reach your local machine directly. ngrok provides the SSE tunnel — one command, one URL, paste it into Claude.ai Settings → Connectors, and Claude discovers all 23 tools automatically.

It's a real dependency and I won't dress it up. A VS Code extension is on the roadmap to eliminate it. But for now it's one command and the rest of the setup is dotnet run.

Problem 6: The UI that removes the last friction point

One thing I refused to build was a tool that required editing JSON config files or restarting a server every time you added a project.

There's a built-in project management UI at /config.html. You point it at a solution folder. That's it. sharp-mcp indexes everything — classes, methods, dependencies, file sizes — and the LLM immediately has full structural awareness of that codebase.

You point it at a solution folder. That's it. sharp-mcp indexes everything — classes, methods, dependencies, file sizes — and the LLM immediately has full structural awareness of that codebase. Each project is independently enabled, re-indexable on demand, and deletable without touching any config file. And yes — sharp-mcp manages its own source code through the same UI. The tool is its own first user.

The three principles everything was built around

Looking back at all six decisions, they all trace back to three things:

Speed — Redis cache + file watcher keeping it warm. No cold starts after the first indexing pass.
Token efficiency — every tool description tells the model when not to call it. Batch modes, size hints, "last resort" labels — that's not documentation, it's prompt engineering baked into the architecture. The LLM should get exactly what it needs to know. Nothing more.
Correctness — MetadataLoadContext means the model works with real signatures, not approximations. There is no training cutoff for your NuGet packages.

The system prompt — two months of refinement

Here's the part that doesn't get talked about enough: tools alone don't make an agent. Judgment does.

After two months of daily use on real production code, I've published the exact system prompt I use at prompts/CODING_SYSTEM_PROMPT.md in the repo.

It's split into two halves:

Part A — Engineering philosophy. Eleven principles: clarity before action, solve the unstated problem, atomic decomposition, multi-perspective validation. These aren't LLM-specific instructions. They're the principles any senior engineer applies before touching a keyboard. The prompt makes them explicit so the model doesn't skip them under time pressure.

Part B — Common sense production rules. Thirteen domains: error handling, validation, resource management, logging, concurrency, API design, database patterns. One rule from the third-party libraries section is worth quoting:

Always web search for latest official documentation before using any library. Verify the exact installed version. Validate method signatures and APIs for that specific version. Never assume behavior based on outdated knowledge.

That rule exists because of exactly the NuGet hallucination problem sharp-mcp was built to solve. Even with real signatures from MetadataLoadContext, a model that doesn't verify assumptions before writing code will still find ways to be wrong. The prompt and the tools reinforce each other.

The third section maps the 23 tools to a strict decision tree — which tool to call first, when never to call read_file_content on a large C# file, why you always run execute_dotnet_command before marking anything complete, why you batch all edit_lines patches in a single call.

This prompt is why the experience feels like pair programming with a senior .NET engineer rather than autocomplete. And it works with any MCP-capable LLM — not just Claude.

What this does not replace

This is not inline autocomplete. It doesn't suggest the next line as you type.

What it replaces is the reasoning session — when you open a chat to understand a codebase, plan a refactor, check what breaks if you change a method signature, look up how a dependency actually works, or implement a feature that spans multiple files. Those sessions are where context limits, hallucinated APIs, and cloud data exposure all cause real damage.

That's the scope this was built for. And after two months of using it daily on production .NET backend work, I can say with confidence: it's the most productive I've ever been writing C#.

If you read the first article and thought "sounds interesting but I want to understand how it actually works" — this was written for you. Questions welcome in the comments.

— Prashant

MCP server for C# development with real NuGet reflection

Prashant Patil — Mon, 13 Apr 2026 15:08:51 +0000

sharp-mcp:

Roslyn-Powered C# Analysis, Real NuGet DLL Reflection, and Safe Live File Editing for Claude, On Your Machine via MCP

If you've ever watched an AI confidently call a NuGet method removed two versions ago — and only found out when your build broke — this is for you.

Or if you've pasted five service classes into a chat, watched the context fill up, and still got a half-baked answer.

Or if you work in finance or healthcare and the phrase "your code is sent to our servers" is a non-starter.

GitHub: https://github.com/patilprashant6792-official/sharp-mcp

The problem nobody talks about

Every AI coding tool in 2025 has the same three silent killers for .NET developers specifically.

Hallucinated APIs. LLMs are frozen at their training cutoff. NuGet ships breaking changes constantly. System.Text.Json changed nullable handling between 6.0 and 8.0. EF Core changed DbContext configuration between 7.0 and 8.0. IgnoreNullValues was deprecated mid-lifecycle. The model doesn't know. It generates code that looks right and doesn't compile.

Context bloat. A 500-line service class costs ~2,000 tokens raw. Load ten files and you've burned your entire context budget before writing a single line. Copilot's #codebase search is widely documented as unreliable — developers end up manually attaching files and hitting the limit anyway.

Your code leaves your machine. Copilot, Cursor, Windsurf — every cloud AI tool sends your source to an external server with every request. For finance, healthcare, or any regulated industry, that's not a theoretical concern. It's a compliance issue.

sharp-mcp fixes all three. It runs entirely on your machine, exposes your codebase as structured MCP tools, and — the part no other tool does — reflects your actual installed NuGet DLLs via MetadataLoadContext.

The novel piece: real NuGet DLL reflection

When you ask sharp-mcp how to use a method from a NuGet package, it doesn't consult training data. Here's what actually happens:

Resolves the exact version pinned in your .csproj via NuGet.Protocol — no guessing
Downloads the .nupkg and picks the right net*/ target framework folder with automatic fallback chain
Downloads transitive dependencies — MetadataLoadContext needs them to resolve cross-assembly types correctly; without this, reflection on generics and inherited types silently fails
Loads the DLL into an isolated MetadataLoadContext — binary inspection only, never executed, zero risk of static constructors or process pollution
Returns valid, copy-paste-ready C# signatures from your exact binary
Parses the XML documentation file shipped alongside the DLL — before the temporary directory is deleted — and stores the full doc map in Redis keyed by member ID
Disposes the context immediately — no assembly leaks, no AppDomain side effects
Caches the result in Redis for 7 days, keyed on packageId:version:targetFramework — second call is a Redis read, not a download

No training cutoff. No hallucinated overloads. No deprecated methods that "still work" in the model's memory. Your DLL. Your truth.

Token cost comparison for NuGet exploration:

What you're doing	Raw dump	sharp-mcp
Explore a namespace	~6,000 tokens	~250 tokens
Explore a class	~2,000 tokens	~400 tokens
Fetch one method	~2,000 tokens	~120 tokens

But NuGet reflection alone isn't a dev assistant

Here's the honest part: NuGet reflection solves one problem. What makes sharp-mcp actually useful for day-to-day .NET development is that all 23 tools form a closed loop. Each one makes the others more powerful.

┌──────────────────────────────────────────────────────────┐
│                     sharp-mcp loop                       │
│                                                          │
│  understand        explore         edit         verify   │
│  codebase  ──►  NuGet APIs  ──►  files   ──►   build    │
│     ▲                                              │     │
│     └──────────────────────────────────────────────┘     │
└──────────────────────────────────────────────────────────┘

You explore a NuGet API with real signatures → write code against those signatures → edit the right file using Roslyn-derived line numbers → build immediately to catch errors. Break any link in that chain and the whole thing degrades. This is the ecosystem.

Understand: Roslyn analysis, not grep

analyze_c_sharp_file uses a full Roslyn syntax tree walker — not text search — to extract structured metadata from every .cs file: DI constructor graphs, method signatures with exact start/end line numbers, attributes, XML doc comments, public/private toggle. Batch mode lets you pass Services/A.cs,Services/B.cs,Controllers/C.cs in one call.

fetch_method_implementation returns a complete method body with every line numbered. Those line numbers are what Claude uses directly in edit_lines patch operations — no guessing, no off-by-one errors.

analyze_method_call_graph walks every .cs file in your project before you touch a signature and returns every caller — file, class, exact line number. The difference between a safe refactor and a CI failure at 11pm.

get_project_skeleton gives you an ASCII folder tree with file sizes and NuGet package list. Pass "*" and it shows every registered project at once. search_code_globally finds classes, interfaces, methods, and properties by name across all projects simultaneously.

All of this is Redis-backed. Roslyn parses each file once on startup, serializes the AST metadata to Redis, and serves every subsequent call in milliseconds. A FileSystemWatcher with a 300ms debounce evicts and rewrites only the changed file on every save. Claude always sees your code as it exists on disk right now — never stale. This is what makes long feature implementation sessions practical — you never burn tokens re-reading files Claude already knows.

Explore: NuGet IntelliSense from your actual binary

The NuGet tools follow exactly the sequence a developer uses in an IDE — not a bulk dump of everything at once:

get_package_namespaces      ← "I installed OpenAI — what namespaces does it expose?"
get_namespace_types         ← "What types exist in OpenAI.Chat?" (~10 tokens/type)
get_type_surface(type)      ← "What can I call on ChatClient?"
get_type_shape(type)        ← "What does ChatCompletion look like?"
get_method_overloads(...)   ← expand specific overload groups on demand
get_member_xml_doc(member)  ← "What does CompleteChat actually do? What are the params for?"

Each step returns only what the next decision requires. Nothing is dumped until asked for. The entire exploration of an unfamiliar package costs ~800 tokens total vs ~6,000 for a full namespace dump. Over a multi-hour implementation session this compounds significantly.

get_member_xml_doc is the final step in this chain. Once you've identified a type and method, it fetches the full XML documentation for that specific member — summary, parameters, return value, remarks, exceptions, and code examples — straight from the XML doc file that shipped with the package. It covers any member kind: types, methods, properties, fields, events, constructors. Zero extra network cost — the XML file is parsed during the initial package load, before the temporary directory is cleaned up, and stored as a separate Redis entry. Every subsequent call is a pure Redis lookup. For packages that don't ship XML docs, it degrades gracefully with a clear message rather than failing.

Edit: surgical file operations with real safety guarantees

Claude can create, edit, move, rename, and delete files — all guarded by per-file semaphore locking (concurrent writes serialized, never dropped), atomic batch-move validation (all destinations validated before any file moves; one failure aborts the entire batch), path sandboxing (traversal structurally impossible — resolved against project root), permanent blocked patterns (bin/, obj/, .git/, secrets, tokens — enforced at the service layer, not a config flag), and automatic Redis cache eviction on every write so the next analysis call sees the updated file immediately.

edit_lines applies multiple patch/insert/delete/append operations to a single file atomically. Patches are validated for overlaps then applied bottom-up — original line numbers stay correct for every patch in the batch. This is what lets Claude make multi-location changes in one shot without line drift.

Verify: build with structured Roslyn diagnostics

execute_dotnet_command runs dotnet clean + build and returns structured diagnostics — not raw stderr:

{ "severity": "error", "code": "CS0246", "file": "Services/OrderService.cs", "line": 42, "message": "..." }

Claude reads the file path and line number, jumps straight to the problem using the analysis tools, and fixes it. The loop — explore → edit → build → fix — runs entirely inside the conversation without copy-pasting error output.

Multi-project from day one

Register as many projects as you have. Every tool accepts projectName. Claude can read the skeleton of one microservice, fetch a method from another, edit a third, build a fourth — in one conversation, without context switching. Pass "*" to any tool to scope it across all registered projects simultaneously.

The privacy angle

Claude receives structured metadata — class names, method signatures, line ranges. Not your business logic. Not your proprietary algorithms. Not your customer data. Nothing leaves your machine.

For .NET developers in finance or healthcare this isn't a nice-to-have. With the EU AI Act in phased enforcement and data residency requirements tightening globally, a tool that processes source code locally is increasingly the only compliant option.

Stack

.NET 10 · Roslyn (Microsoft.CodeAnalysis.CSharp 5.0) · Redis (StackExchange.Redis + NRedisStack) · ModelContextProtocol 0.5 · NuGet.Protocol · System.Reflection.MetadataLoadContext · ngrok SSE transport

23 MCP tools across 8 tool classes: code analysis, project exploration, NuGet reflection, file operations, dotnet CLI, utility.

Get started

git clone https://github.com/patilprashant6792-official/sharp-mcp
cd sharp-mcp/LocalMcpServer
dotnet run

Start Redis:

docker run -d -p 6379:6379 redis:latest

Expose with ngrok:

ngrok http 5000

http://localhost:5000/config.html

Add the ngrok /sse URL to Claude.ai → Settings → Connectors. Claude discovers all 23 tools automatically. Full setup walkthrough in the README.

What this doesn't replace

This is not inline autocomplete. It doesn't suggest the next line as you type and doesn't integrate into your IDE as an extension.

What it replaces is the reasoning session — when you open a chat to understand a codebase, plan a refactor, check what breaks if you change a signature, look up how a dependency actually works, or implement a feature that spans multiple files. That's the scope it's built for. And that's where the closed loop — Roslyn analysis, real NuGet reflection, surgical editing, live build feedback — earns its keep.

Drop a comment if you've hit any of these walls. Genuinely curious what .NET packages and patterns people are trying to get Claude to reason about.