Fuse 4.2 is an open source .NET global tool that runs as an MCP server or from the command line.
I built Fuse after watching coding agents repeatedly read and search the same .NET files. Across several turns, they would reconstruct symbols, references, dependency injection registrations, and project structure they had already encountered.
On the write side, proposed C# changes often went through a longer edit and dotnet build loop just to find an invalid member, missing argument, or incompatible type.
Fuse addresses these two parts of the workflow: code discovery and earlier compiler feedback.
Reusing .NET discovery
Fuse loads the solution through MSBuild, analyzes C# with Roslyn, and stores the derived index locally in .fuse/fuse.db. Changed files are updated incrementally, so later requests can reuse the existing index.
The index supplies exact symbol lookup, .NET framework wiring, reduced task-scoped source, change impact, and Git-seeded branch review.
For example, text search can find every occurrence of IOrderService. Fuse can follow the dependency injection registration to the implementation used by the application. It can also resolve a MediatR request to its handler, an ASP.NET route to its action, or a configuration section to its options class.
When Claude Code needs source, Fuse selects files from indexed anchors and reduces their content under a token budget. The response includes the reason each file was selected, and later calls in the same session can skip unchanged context already returned.
Checking proposed C# edits
fuse_check accepts the proposed content of one C# file without changing the working tree.
When compiler state captured from the real build is available, Fuse checks the proposal against that compilation. Otherwise, it falls back to a scoped build for the project that owns the file. If neither compiler path can run, Fuse abstains and reports what is missing.
This check does not replace the final build or test run. It gives the coding agent compiler feedback earlier, before committing a proposed file to disk and starting the normal verification loop.
Fuse also provides change-impact queries, covering-test selection, compiler-executed refactoring, and review context based on the current Git diff. These operations use the same local index.
Scope and related tools
Repository indexes and code graphs already exist. CodeGraphContext provides a local multi-language graph, Serena exposes language-server-backed symbol operations, Sourcegraph covers code search across repositories, and coding clients maintain their own indexes.
The C# LSP also handles definitions, references, type information, live diagnostics, and editor refactoring. Fuse can run alongside it.
Fuse has a narrower scope: local .NET analysis through MSBuild and Roslyn, including framework-specific wiring, reduced source for the current task, and checks against compiler state captured from the repository's real build.
Recorded results
On the recorded NodaTime semantic index with 14,760 symbols, exact symbol lookup took 1.8 ms at the median. Task localization took 15.7 ms at the median.
In a separate compiler-labeled suite over the OrderingApp test families, Fuse recorded 0 false green and 0 false red across 1,000 generated single-file edits plus 8 curated cases.
Both results are bounded to the recorded machines, repositories, and test samples. The benchmark pages include the weaker results as well, including cases where open-ended localization has limited signal and the agent loop did not reduce the number of normal build and test calls.
Install
Install Fuse as a .NET global tool and connect it to Claude Code:
dotnet tool install -g Fuse
fuse mcp install --client claude --rules
Reload Claude Code after installation. MCP read tools build the index on first use, or you can build it explicitly:
fuse index
Analysis runs locally and can work offline. Fuse does not require a hosted service or its own model. The optional update check and builds using configured package feeds are the network-dependent cases.
- Repository: github.com/Litenova-Solutions/Fuse
- Documentation: fuse.codes
- Methods and limits: fuse.codes/docs/project/benchmarks
- Reproduction: fuse.codes/docs/project/reproduce
Top comments (2)
The abstain behavior is the part I like most. For agent tools, “I cannot check this against a real compilation state” is much safer than returning a confident green from incomplete context.
The other useful bit is explaining why each file was selected under the token budget. That makes the MCP layer auditable instead of just another hidden retrieval step.
I would be curious how you handle index invalidation across target frameworks and conditional compilation symbols. C# projects can look like one codebase until the build configuration quietly changes the surface area.
Hey, good question!
Build configuration is indeed part of compilation state, not just repository state.
Sorry, the explanation is going to be a bit technical 😅
In tier-1 mode, Fuse runs the repository's actual dotnet build and rehydrates each C# compiler invocation it records. Roslyn has already applied that invocation's target framework and active preprocessor symbols, so #if branches are indexed as the compiler saw them.
For multi-target projects, Fuse captures each TFM, chooses a deterministic primary representation, and unions symbols and graph facts across all captures. Shared facts are stored once, while tfm_availability records every TFM where each fact exists. A declaration present only under netstandard, for example, is retained rather than overwritten by the primary TFM.
The current limitation is configuration identity. The store models target-framework availability, but not every Debug, Release, RID, or custom DefineConstants combination as separate indexes. Active symbols are applied by Roslyn during capture, but the symbol set is not yet a first-class retrieval key.
Source and project-file edits are detected by the inventory and content-hash pass. A change to externally supplied MSBuild properties or build configuration needs a full fuse_workspace action=index or fuse index to recapture the semantic graph. Until that exact state is captured, compiler-backed tools report their verification grade or abstain rather than treating a different configuration as equivalent.