Why use Fuse

Before your coding agent changes OrderService.cs, resolve the wiring it touches and have the compiler check the proposed file:

dotnet tool install -g Fuse
fuse mcp install --rules

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, and compiler checks to the editor and agent workflow you already use. It does not replace file editing, exact text search, or dotnet build.

Check the Proposal, Not Just the Saved Files

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.

Index Once, Query Warm

Fuse builds .fuse/fuse.db on first use and reuses it across calls. On the recorded NodaTime run, exact symbol lookup took 2.2 ms at the median and task localization 23.4 ms (performance.json). Syntax mode serves quickly; semantic mode adds DI, handler, route, and call edges when the project loads through the compiler.

Follow .NET Wiring, Not Just Matching Names

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.

Start Branch Review from Git

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.

Keep Source and Writes Local

Fuse runs as a local .NET process. It requires no hosted Fuse model and downloads no embedding 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.

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.

Read the Measurements in Scope

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.