Getting started
One local process, registered in your client, and a solution folder: that is the whole setup. This page covers the install, the optional routing guard and a first session that touches the main tool families.
Requirements
| Requirement | Why |
|---|---|
| .NET 10 SDK | The server targets net10.0 and uses MSBuild and Roslyn to load solutions. |
| Windows 10/11, Linux or macOS | One installer per platform: install.ps1 on Windows, install.sh on Linux and macOS. The server adapts shell, debugger and profiler to the platform. |
| An MCP client | ZCode, Claude Code, or any client that can start a stdio MCP server. |
Visual Studio is not required. Optional integrations light
up only when their tool is present: Docker for the docker_*
tools, the GitHub CLI for gh_*, and coverlet.collector
in your test projects for code coverage.
Install
From a checkout of the repository:
# Windows: ZCode + Claude Code (default)
powershell -ExecutionPolicy Bypass -File scripts\install.ps1
# Linux / macOS: the same scopes, with the POSIX installer
./scripts/install.sh
The installer builds a Release binary, publishes it under your user profile and registers the server in your client's configuration. Then it installs the routing guard (below). It does not restart the client — MCP configuration is read at session start, so restart it yourself.
Choose a scope
| Scope | Availability | Use when |
|---|---|---|
all (default) | ZCode + Claude Code + the desktop app | You use more than one client |
zcode | Every ZCode session on the machine | You only use ZCode |
user | Every folder, global | Claude Code only, everywhere |
local | One project folder, private | One project, without affecting others |
project | One project, shared | You want teammates to get it through a committed .mcp.json |
The routing guard
Registering the server is not enough on its own: a model that has never
been told otherwise keeps doing C# work with grep -rn and
friends. The optional guard is a pre-tool-use hook that denies read-only
shell probes (grep, sed -n, cat,
ls, find…) in a folder with a visible
.sln/.slnx, and replies with the semantic tool
to use instead. Build, test and git commands are never touched, and the
run_command tool remains the escape hatch for genuine shell
cases. Skip it at install time with -NoHooks.
Verify the connection
Restart the client, check that a VisualMCP server appears
with a large tool list, then open a folder that contains a solution and
ask the client to call:
check_solution
The answer reports whether a solution is loaded, its path, the project
count, the C# / Visual Basic breakdown and the workspace root in use.
Solutions are discovered automatically on first use — you normally do
not need to call load_solution yourself.
A first session
A five-minute tour across the main families:
| Step | Tool | What to look for |
|---|---|---|
| 1 | read_project_docs | The solution's README and Markdown, indexed when the solution opened. |
| 2 | solution_audit | Whole-solution health: inspections, diagnostics, complexity hotspots, project graph, first moves. |
| 3 | find_symbol then read_symbol | Locate a type by name, then read its declaration source with line numbers. |
| 4 | get_diagnostics | Compiler errors and warnings — the IDE Error List. |
| 5 | simplify_code with dryRun=true | A preview: before/after pairs and a line diff per edit, nothing written. |
Then try a question in your own words:
Find every implementation of IOrderService, show me the one
with the most dependencies, and tell me whether the interface is used
from a background service.
The client should route to find_implementations,
get_type_members and find_callers rather than
grepping — that is the guard and the tool descriptions doing their job.
Upgrade and uninstall
check_for_update and self_update upgrade from
inside the client; or pull the repository and re-run the installer with
the same scope. Uninstalling removes the server registration but not the
solution's .visualMCP store — delete that folder if you
also want to remove the indexes, logs, board and edit history.