VuDZ/RoslynMcpServer

🇷🇺 Читать на русском (Russian Version)
RoslynMcpServer gives an AI coding agent compiler-aware tools for C# solutions: semantic navigation, diagnostics and code fixes, refactoring, dependency inspection, and bounded dotnet build/test/run output.
Unlike a filesystem MCP, it loads .sln, .slnx, or .csproj through Roslyn/MSBuild. The agent can resolve symbols and project context instead of inferring them from text alone.
## MCP and agent: the 60-second model
MCP client — Cursor, OpenCode, or another compatible host. It starts the server and exposes its tools to the model.
AI agent — the model plus the client's orchestration. It decides which tool to call; it is not part of this repository.
RoslynMcpServer — a local stdio process. It exposes tools but has no chat UI and does not act autonomously.
AGENTS.md — repository policy for the agent. MCP configuration makes tools available; this file tells the agent when to use them.
Typical flow:
developer request → agent → MCP tool call → Roslyn/MSBuild/ILSpy/dotnet → compact result → agent
The server is C#-focused. It can read non-C# files and execute selected CLI operations, but it does not provide Python semantic analysis. See Architecture and constraints for component boundaries, state, synchronization, and extension rules. Docs index: docs/README.md. Planned (not shipped) large-solution load cache: docs/backlog/workspace-load-cache/.
Plugin development and setup: authoring guide.
## What it provides
Compiler-aware declaration, usage, implementation, and call-graph navigation.
Roslyn diagnostics, code actions, AST edits, and semantic rename.
ILSpy inspection of referenced or explicitly addressed assemblies.
Build, test, run, format, and NuGet workflows with SDK alignment, timeouts, parsed diagnostics, and context-safe output.
full and context-saving lite tool catalogs, plus in-session tool-group discovery.
## Saved edits and the semantic snapshot
After loadworkspace, semantic tools trust the file watcher until the next confirmation. A confirmation is another loadworkspace, or a flush of a save the watcher actually reported. The tools do not hash the tree on every call, and they do not mark the snapshot freshness=unknown.
A saved .cs that is already a document is read once and applied to every project document of that path.
A saved additional file or analyzer config that is already a document, and is not also an evaluation input, is applied on the published snapshot. XAML, resx, and Razor are recorded by role and are not text-synced.
A new or deleted file does not add or remove a document. The project graph is marked stale; call loadworkspace again. A project file, a solution, or Directory.Build. marks the graph stale the same way.
Watcher overflow, a watcher error, or a directory rename asks the next semantic call to re-read known documents and can mark the graph stale.
An edit the watcher never reported — a file outside the watch set, or a dropped notification with no error — stays invisible until the next loadworkspace. Standing coverage gaps (imports, restore inputs, custom tasks) do not by themselves block a read.
The other freshness policies that were considered and not chosen are recorded in epoch 3.