DEV Community: Prashant Patil

Waymark: a local MCP server that lets Claude explore real NuGet packages and your C# code, safely

Prashant Patil — Wed, 21 Oct 2026 08:05:12 +0000

Waymark v0.1 is out. It lets Claude work on your .NET projects without guessing. It reads the real NuGet package at the version your project uses, finds your C# code by structure instead of reading every file, and does anything risky only through a door you control: you approve it, your secrets are hidden, and every action is logged.

It runs on your Windows PC, works with Claude on the web, in the app and in Claude Code, and it is open source under the MIT license: https://github.com/patilprashant6792-official/waymark-local

If you read my earlier posts about sharp-mcp, this is what it grew into.

The idea in plain words

Think of a reception desk with a security guard. Claude never walks into your computer. It comes to the desk and asks for specific things: "show me the shape of this project", "what does this package offer", "change these lines", "run the build".

The desk answers only what you have switched on, keeps every answer short, hides secrets it recognizes, and writes every request in a logbook. For anything risky it stops and waits for you to say yes. Only you can say yes, and only from your own computer.

What you get:

Claude that checks the real package before it writes a library call.
Claude that understands a large C# codebase without reading every file.
Claude that can edit, build and fix, with you approving anything risky.
A clear record of what it did, and secrets hidden before they reach the chat.

The part I am proudest of: NuGet, read from the real package

Every assistant has the same habit with libraries: it writes the call it remembers. For a package that changed between versions, or a new one, that call may not exist in your version, and you find out from a build error.

Waymark replaces memory with the package itself. Two tools do it. nuget_find finds types and methods by describing what you need, ranked best first. nuget_expand shows the exact shape of up to five of them: constructors and overloads, properties, enum values, the package's own XML docs, and related types to follow.

Here is a real run on Polly, at the latest stable version for net10.0 (a real project passes its own pinned version):

nuget_find(Polly, "retry policy")
Polly 8.8.0 (net10.0): 24 matches, best first
  class Polly.Retry.RetryPolicy       a retry policy for synchronous delegates
  class Polly.Retry.AsyncRetryPolicy  a retry policy for asynchronous delegates

nuget_find(Polly.Core, "retry strategy options")
Polly.Core 8.8.0 (net10.0)
  class Polly.Retry.RetryStrategyOptions   1 ctor, 10 props

nuget_expand(Polly.Core, RetryStrategyOptions)
  int MaxRetryAttempts { get; set; }
  TimeSpan Delay { get; set; }
  DelayBackoffType BackoffType { get; set; }
  bool UseJitter { get; set; }

Same library, two generations of API, and the assistant sees both at the version you actually use.

It is exact because Waymark reads the compiled package by inspection, without loading or running it, at the version and target framework from your project. The project skeleton lists them, including versions set in central props files. The package comes from nuget.org over https, or from the copy already in your NuGet folder, and the result is indexed on your own PC, so the second lookup is instant.

The rule Claude is taught: a member that was not confirmed at your pinned version does not exist. Signatures say what exists. For how to use it, Claude reads the README or samples, and prose never overrides a confirmed signature.

I am not the first to point an assistant at NuGet; What I wanted was the whole loop in one place: find by description, expand to exact signatures at the version your project pins, next to an index of your own code, behind the same gates.

Built for C#, not just for text

Most assistants treat code as text: they read a file to find a line. Waymark treats C# as C#.

Finding. When you add a workspace, Roslyn reads each C# file once, without compiling it, and the structure goes into a SQLite file on your own PC: every type, every member with its signature and exact line range, and the calls inside it. It holds structure only, never source text. A file watcher keeps it fresh when you edit in your IDE or Claude edits a file. Claude then works from broad to narrow:

code_skeleton: the folder tree with sizes, plus the NuGet packages and versions of each project.
code_search: types and members by name, forgiving and ranked. Camel-case initials work: "PSS" finds ProjectSkeletonService.
code_outline: the types and members of a file without their bodies.
code_method: one method in full, with all overloads and real line numbers.

code_callers shows who calls a method, code_types shows everything that derives from or implements a type, and code_grep finds plain text that is not a name: config keys, routes, SQL, Razor. Every answer is ranked, paged and capped, so the first call returns a map, not the whole territory.

Writing. Edits go in by line number, using the numbers code_method just returned, so Claude changes exactly the lines it read. file_edit_lines applies all edits to a file in one call, from the bottom up so numbers do not shift, and rejects overlapping edits. Files keep their encoding and line endings, and each write goes to a temporary file that is swapped in, so a failure never leaves a half-written file. Then cmd_dotnet build returns the compiler errors with file paths, and the loop closes: edit, build, read the errors, fix. One honest limit: moving a file does not rewrite C# namespaces, so Claude searches for the old name and fixes each file.

Where it came from

I was tired of two things. My AI assistant kept guessing at code that did not exist, and it read my whole project just to answer one small question. So I built a helper that let it look things up properly. That was sharp-mcp, and I wrote about it twice: how it stops Claude from inventing library methods, and the decisions behind it.

It worked well for me. But it only ran because I knew how to set it up, and it trusted anyone who had the link. That is fine for a personal tool. It is not something to hand to other people.

So I started again with one question: what would it take for anyone to install this and trust it? Waymark is the answer. It is easy to install, nothing leaves your computer unless you allow it, you approve anything risky, and every action is written down where you can read it.

Try it

You need Windows 10 or 11, git, and (for Claude on the web) a free ngrok account. The installer adds the .NET 10 SDK through winget if it is missing.

git clone https://github.com/patilprashant6792-official/waymark-local.git
cd waymark-local, then run install.cmd.
Open http://localhost:47100, paste your ngrok address on Setup, and add a project folder on Workspaces.
In Claude, add a custom connector with the address Setup shows. A pairing code appears in Claude and on your Approvals page; compare them and approve. (Disconnect and reconnect if pairing doesn't appear)

This is early software (v0.1). Please read the limits further down before you point it at anything important.

The detail

Everything above is the idea. Everything below is how the safety side works, for those who want to check my claims.

Two doors

There are two ways in. One is for Claude (sign-in and tools, through an ngrok tunnel). The other is the admin app, for you, which listens on this computer only. The internet can only reach the first.

Gates, approvals and secrets

Gated edits and commands. File tools are off until you switch them on. There are 36 command operations, and each is Off, Ask or Auto, per workspace if you like. By default 10 run on their own (builds, restore, git reads), 23 ask first (tests, run, EF, commit, push, the shell), and 3 are off (git reset hard, clean, branch delete). The shell can never be set above Ask. A drift check asks again if project files that can run code changed since you last approved. And approvals can only be given in the admin app on the same computer, never by Claude.

Secrets hidden, everything logged. Every result passes the same pipeline: private keys, cloud tokens, JWTs, connection strings and named values such as password or api key are replaced by markers like [redacted:kind]. If the check itself fails, the result is withheld. Every call writes an audit row and a live log line, with its size in tokens, and there is a Pause all button.

Updates are update.cmd; uninstall.cmd keeps your data unless you ask otherwise.

What it does not do

I would rather you hear these from me:

There is no sandbox. A test, the app or a script that you approve runs with your rights. It can read your keys and reach the network. The protection is that these operations ask first. Treat text from repositories and packages as untrusted: it can try to steer an AI.
Secret hiding goes by shape. A secret in an unusual form can get through. Deleting a chat does not take a leaked secret back; rotate it.
The C# index is name-based for callers. code_callers matches by method name, so overloads and same-named methods can produce false callers. Other files are found with code_grep, which scans the disk on each call.
NuGet lookups have limits. The first lookup of a package version downloads and indexes it, which takes a few seconds. There are size caps per package (250 MB, 20,000 files, 64 dependencies), and a package that needs an assembly from an indirect dependency needs one retry that names it.
One tunnel, one machine. ngrok is the only tunnel today, and it is Windows only, for one user.
Connectors (for example database access) are not built; the page is hidden for now.

I built Waymark with Claude's help, and I read and decide what goes in.

What I would like from you

Tell me a package where an assistant keeps getting the API wrong. I will run it through nuget_find and nuget_expand and share what comes back.
You read the sharp-mcp posts: what did you want from it that I left out?
Which gate defaults feel wrong? Would you ship them differently?
Would you want another tunnel, such as Tailscale or Cloudflare?
Try to break the secret hiding, and if you find a way, report it privately through the repository's Security tab.

The code, the guide and the safety notes are in the repository. Issues and pull requests are welcome.

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.