roz-mcp

# roz-mcp

<!-- mcp-name: io.github.andypgray/roz-mcp -->

[![CI](https://github.com/andypgray/roz-mcp/actions/workflows/ci.yml/badge.svg)](https://github.com/andypgray/roz-mcp/actions/workflows/ci.yml) [![OpenSSF Scorecard](https://img.shields.io/ossf-scorecard/github.com/andypgray/roz-mcp?label=openssf+scorecard)](https://scorecard.dev/viewer/?uri=github.com/andypgray/roz-mcp) [![NuGet](https://img.shields.io/nuget/v/Zphil.Roz?logo=nuget&label=nuget)](https://www.nuget.org/packages/Zphil.Roz) [![NuGet downloads](https://img.shields.io/nuget/dt/Zphil.Roz?label=downloads)](https://www.nuget.org/packages/Zphil.Roz)

roz is an MCP server that gives C# coding agents the compiler's view of a solution. It finds every real reference to a symbol, including the edges text search misses: overrides, interface dispatch, DI registrations. It renames a symbol across the whole solution in one call, previews the blast radius of a proposed change, and makes edits that verify themselves against the compiler in the same round trip. roz runs as a .NET global tool over stdio; one `roz-mcp setup` command configures Claude Code, Cursor, VS Code Copilot Chat, or Codex CLI.

roz was developed for and dogfooded on large legacy financial codebases, and it is for that sort of work that it shines. It is most probably *not* worth the (inherent to the MCP protocol) token overhead for clean greenfield work; [When it helps (and when it doesn't)](#when-it-helps-and-when-it-doesnt) has the measurements.

## Quickstart

roz requires the .NET 10 SDK.

```bash
dotnet tool install -g Zphil.Roz
cd path/to/your/solution
roz-mcp setup
```

Restart the AI client, then ask it something that needs the compiler:

> *"Find all implementations of `IRepository` in this solution and show me each class's `Save` method."*

`setup` auto-detects which AI clients the project uses (via the `.claude/`, `.cursor/`, `.vscode/`, and `.codex/` marker directories), writes the matching MCP config file(s), and appends a short usage snippet to the corresponding project rules file. If several markers are present, choose explicitly with `--client=claude,cursor`. Setup is idempotent: re-running it updates roz's entries without disturbing sibling MCP servers or user-added environment variables, and it refreshes the `# roz-mcp` rules section in place without touching the rest of the file.

| Client | Config file(s) written | Rules file |
|---|---|---|
| Claude Code | `.mcp.json`, `.claude/settings.local.json` | `CLAUDE.md` |
| Cursor | `.cursor/mcp.json` | `AGENTS.md` |
| VS Code Copilot Chat | `.vscode/mcp.json` | `AGENTS.md` |
| Codex CLI | `.codex/config.toml` | `AGENTS.md` |

VS Code and Cursor users can also add the server in one click, once the tool is installed:

[![Install in VS Code](https://img.shields.io/badge/VS_Code-Install_Server-0098FF?style=flat-square&logo=visualstudiocode&logoColor=white)](https://insiders.vscode.dev/redirect/mcp/install?name=roz&config=%7B%22type%22%3A%22stdio%22%2C%22command%22%3A%22roz-mcp%22%7D) [![Add to Cursor](https://cursor.com/deeplink/mcp-install-dark.svg)](https://cursor.com/en/install-mcp?name=roz&config=eyJjb21tYW5kIjoicm96LW1jcCJ9)

The badges wire the server into the client config only. `roz-mcp setup` is the fuller path: it also writes the project rules snippet and, for Claude Code, the permission defaults that route write tools through a confirmation prompt.

Two defaults are worth knowing before your first session:

- **Solution discovery** walks up from the working directory; pin a specific `.sln`/`.slnx` with `ROZ_SOLUTION_PATH` in the MCP config's `env` block.
- **Tool surface**: the default set is 12 of the 19 tools; most write tools are opt-in. Seed a different surface at onboarding with `roz-mcp setup --tools=all` (everything) or `--tools=read` (read-only), and see [Configuration](#configuration) for finer control.

### From source

```bash
git clone https://github.com/andypgray/roz-mcp
cd roz-mcp
dotnet pack src/Zphil.Roz/Zphil.Roz.csproj -c Release
dotnet tool install -g --add-source src/Zphil.Roz/bin/Release Zphil.Roz
```

roz installs as `roz-mcp` on your `PATH`.

## Install as a Claude Code plugin

Claude Code users can skip the global tool install: this repository doubles as a single-plugin marketplace, and one install delivers the server with its [tools](#tools), [prompts](#prompts), and [guide resources](#resources), plus a skill carrying the usage rules that `roz-mcp setup` would otherwise write into `CLAUDE.md`:

```
/plugin marketplace add andypgray/roz-mcp
/plugin install roz-mcp@roz-mcp
```

The plugin starts the server with `dotnet dnx`, which fetches `Zphil.Roz` from nuget.org on first use. You still need the .NET 10 SDK. The plugin's launch command is global, so per-project settings go in a `.roz.json` file (see [Configuration](#configuration)); the bundled skill includes a recommended permission block that keeps the write tools behind a confirmation prompt ([SKILL.md](https://github.com/andypgray/roz-mcp/blob/main/skills/roz-csharp-editing/SKILL.md)).

Enable the plugin per project rather than globally: roz is measured overhead on work that never needs the compiler's view (see [When it helps](#when-it-helps-and-when-it-doesnt)). A team can check the marketplace and plugin enablement into the project's `.claude/settings.json`, which prompts teammates to install on their next session:

```json
{
  "extraKnownMarketplaces": {
    "roz-mcp": { "source": { "source": "github", "repo": "andypgray/roz-mcp" } }
  },
  "enabledPlugins": { "roz-mcp@roz-mcp": true }
}
```

The server should be registered once per project. With the plugin enabled, `roz-mcp setup` detects it and configures around it: permission rules under the plugin's tool-name prefix, `--tools` written to `.roz.json`, no `.mcp.json` entry, and a warning if a leftover classic entry would register the server twice. `--plugin` and `--no-plugin` force either mode.

## Tools

roz ships 19 tools across 7 categories. Read tools are forgiving: a cursor near a declaration snaps to the nearest enclosing symbol, and the worst case is information about the wrong symbol. Write tools are conservative: symbol names are authoritative, and an ambiguous target fails with a disambiguation error.

Read tools accept `includeDocs=true` and (where applicable) `includeBody=true`; locations are either cursors (`path:line:col`, or `path:line` for member-on-line snap) or symbol names (with optional FQN, `containingType`, `kind`, or `project` substring filter).

| Tool | Category | Description |
|---|---|---|
| `find_symbol` | navigation | Find a symbol by name, FQN, or arity-disambiguated name (e.g. `Processor<,>`). |
| `get_symbols_overview` | navigation | List a type's members. |
| `go_to_definition` | navigation | Resolve a cursor to its definition. |
| `find_overloads` | navigation | List all overloads of a method (batchable by name or location). |
| `analyze_method` | navigation | Method signature plus inbound callers and outbound in-solution callees grouped by target. |
| `find_references` | references | Find usages with `referenceKinds=all\|invocations\|reads\|writes`, plus `contextLines`, base-call filtering, and a DI-registration fallback for constructors. |
| `find_implementations` | references | Interface/abstract members → overrides; classes/interfaces → derived/implementing types. |
| `analyze_change_impact` | references | Blast radius of a proposed change (`TypeChange`/`RemoveSymbol`/`AccessibilityNarrow`/`SignatureChange`); each site tagged compatible/requires-update/unsafe; `newSignature` upgrades `SignatureChange` to per-argument classification via overload resolution. |
| `get_type_hierarchy` | types | Base types, derived types, implemented interfaces (batchable). |
| `get_diagnostics` | diagnostics | Compiler + analyzer diagnostics with code-fix hints. `incremental=true` surfaces only new issues vs a captured baseline. |
| `get_workspace_info` | workspace | Solution and project metadata; `reload=true` refreshes from disk. |
| `get_unused_references` | workspace | Detect unused `ProjectReference` (confident) or `PackageReference` (weak signal). |
| `rename_symbol` | editing | Solution-wide semantic rename that keeps overrides and references coherent. |
| `edit_symbol` | editing | Batched insert/replace/remove of members; targets resolved by location or name. |
| `replace_content` | editing | Batched literal or regex text replacement; multi-line literal mode supported. |
| `apply_code_fix` | editing | Apply a registered analyzer-pack code fix (FixAll) for one diagnostic ID across a scope (held out of the default set). |
| `change_signature` | editing | Add-optional / remove-unused / reorder a method's parameters across its declaration family and all call sites; analysis-gated (held out of the default set). |
| `add_usings` | usings | Add `using` directives, sorted and deduplicated. |
| `remove_unused_usings` | usings | Remove unused `using` directives. |

The default set is 12 tools. The write tools (`edit_symbol`, `replace_content`, `apply_code_fix`, `change_signature`, `add_usings`, `remove_unused_usings`) and `get_unused_references` are opt-in via `ROZ_TOOLS` (see [Configuration](#configuration)).

The five `editing` tools accept a `verify` mode that collapses the edit → build → re-read loop into one round trip: `verify=DryRun` applies the batch to an in-memory fork and reports the new-and-resolved compiler-error delta without writing anything, and `verify=Delta` commits first, then reports. Verified writes exist because an agent's own success report is not evidence: silently asserting completion while the state says otherwise is a pattern reported across the agent literature ([Advani 2026](https://arxiv.org/abs/2606.09863), agentic benchmarks rather than code audits specifically).

Batched read tools (`find_references`, `analyze_change_impact`, `find_implementations`, `find_overloads`, `get_type_hierarchy`) accept many items per call; one round trip wit