Why use Fuse

Coding agents can inspect a .NET solution through file reads, grep, regex, and language tools. That works, but repeated discovery can reopen the same files and reconstruct the same symbol and project relationships across turns. Fuse persists that structure and returns a reduced payload for the selected scope.

Install and connect from a .NET project directory:

dotnet tool install -g Fuse
fuse mcp install

Then reload the agent and ask:

Use fuse_check on the proposed OrderService.cs content before writing it.

Fuse adds a warm local index, graph-backed wiring lookup, reduced task-scoped source, and compiler checks to the editor and agent workflow you already use. Exact text search, normal builds, and the coding client's own index remain useful alongside it.

Persistent Discovery Across Turns

When the MCP server starts, the shared daemon begins warming .fuse/fuse.db before the first tool call. On the recorded NodaTime run (semantic tier, 14,760 symbols), exact symbol lookup took 1.8 ms at the median, task localization 15.7 ms, and review planning 106.3 ms (performance.json). Timings depend on the repository and machine.

Syntax mode provides file and symbol retrieval. Semantic mode adds DI, handler, route, options, and call edges when the project loads through MSBuild and Roslyn. Fuse reports the mode with the answer.

Reduced Task-Scoped Source

fuse_context emits selected source under a token budget and records why each file was included. Sessions can skip unchanged context on later turns. Across four recorded repositories, skeleton reduction removed 38 to 44 percent of tokens while retaining every measured public and protected type name and 96.3 to 99.4 percent of measured method names (reduce.json). This measures declaration-name retention, not the complete public API.

Proposed-File Compiler Checks

dotnet build checks the files currently on disk. fuse_check checks one proposed file before the agent writes it. It returns compiler diagnostics and, for supported API-shape errors, a suggested repair. The working tree remains unchanged.

The result also states which compiler path answered. Fuse calls this the verification grade:

• Oracle grade uses the compilation captured from the real build.
• Build grade runs a scoped dotnet build for the owning project.
• Abstained means neither compiler path could answer and names what is missing.

Faster repeated checks are available behind FUSE_RESIDENT=1. That mode is opt-in. The benchmarks record its measured latency and environment.

Typed .NET Wiring

Text search can find IBasketService. It cannot establish which implementation a particular dependency injection registration supplies. Fuse uses Roslyn and framework-aware analysis to follow:

• service interfaces to registered implementations,
• requests and commands to handlers,
• routes to actions or endpoints,
• configuration sections to options types.

fuse_find(path="C:/Projects/MyApp/src", kind="service", query="IBasketService")

Reflection, runtime dispatch, and projects that cannot load through the compiler can hide connections. Fuse reports the workspace's analysis mode so a syntax-only lookup is not presented as a compiler-backed result.

Git-Seeded Branch Review

Git already knows which files changed. fuse_review keeps those files and adds focused context from callers, implementations, handlers, configuration consumers, and tests. Each included file states why it was selected.

fuse review ./src --changed-since origin/main --max-tokens 25000

max-tokens limits the focused context returned. It does not make the review a complete substitute for reading the pull request.

Related Code-Intelligence Tools

Repository indexes, code graphs, and language-server tools are an existing category. CodeGraphContext provides a local multi-language graph, Serena exposes language-server-backed symbol operations, and Sourcegraph covers multi-repository search and code intelligence. Fuse concentrates on local .NET work through MSBuild and Roslyn: framework wiring, reduced scoped context, compiler-backed proposed-file checks, change impact, and covering-test selection. It can run alongside a coding client's built-in index.

The peer comparison is a bounded, dated experiment with unequal sample sizes for the model-driven arms. It is not a general ranking of code-intelligence tools.

Local and Offline Analysis

Fuse runs as a local .NET process. Indexing, retrieval, reduction, and captured-compiler checks can work offline and require no model. Source and the derived .fuse/fuse.db index remain on the machine. Your coding agent still applies its own data policy to tool results.

The optional daily update check can contact NuGet. A build-grade operation can use the package feeds already configured for the repository.

Checks, reads, indexing, and review do not write source files. The explicit write path is fuse_workspace with action=apply, and it remains a dry run unless the caller requests a write.

Measurement Limits

The recorded checks cover 1,000 compiler-labeled edits in the OrderingApp test app, not every possible .NET edit. The wiring result covers 24 expected links in that app. The branch-review result covers 69 real pull requests and keeps their Git-changed files by construction.

The agent-loop run found similar build and test command counts for Fuse and native tools; it does not support a claim that Fuse halves build calls. Read the exact figures, confidence intervals, methods, and weaker modes on the benchmarks page.

Next

Follow the Quickstart for the first checked edit. Use Connect to your AI for project, user, and manual setup.