MSBuildMcpServer
MSBuildMcpServer is an MCP server for building Visual Studio/MSBuild-based projects from agent workflows
Ask AI about MSBuildMcpServer
Powered by Claude · Grounded in docs
I know everything about MSBuildMcpServer. Ask me about installation, configuration, usage, or troubleshooting.
0/500
Reviews
Documentation
VSBuildMcp
VSBuildMcp is an MCP server for building Visual Studio/MSBuild-based projects from agent workflows.
It provides a unified build interface for:
.csproj.vcxproj.wixproj.sln
The server supports both .NET and C++ build scenarios and normalizes build behavior for Linux-hosted agents targeting Windows-style project paths.
Purpose
This project is meant to make build automation reliable when AI agents or remote tools need to compile Visual Studio projects.
Use it when you want to:
- Build Windows-first solutions (
.sln,.vcxproj,.wixproj,.csproj) from MCP-compatible clients - Hide toolchain complexity behind a stable, intent-based API (
build_project,rebuild_project, etc.) - Avoid manual command differences between .NET and C++ projects
- Standardize build responses so calling agents can react programmatically to failures
- Run in mixed environments where caller paths are Linux-style but build tools require Windows-style paths
In short, VSBuildMcp is a bridge between agent workflows and real-world MSBuild ecosystems, so builds can be requested in a simple, consistent way.
Project Structure
MSBuildMcpServer/- ASP.NET Core MCP server implementationMSBuildMcpServer/Program.cs- tool definitions and build execution logicMSBuildMcpServer/appsettings.json- path mapping configuration
Key MCP Tools
build_project- main entrypoint for Build/Rebuild/Clean style actionsrestore_project- dependency restore where relevantclean_project- clean outputsrebuild_project- clean + build workflowpublish_project- publish flow for.csprojresolve_project_path- resolve Linux/Windows project pathsget_build_capabilities- discover supported types/modes/mappingsrun_ms_build- backward-compatible alias
Build Features
- Unified request shape (
projectPath,configuration,platform,target, etc.) - Smart restore modes (
auto,always,never) - Build modes (
standard,smart) - Path mapping between Linux and Windows roots
- Structured build result with:
- success/failure + exit code
- stdout/stderr
- normalized error code (for common failure classes)
- discovered output artifacts (
exe,dll,lib,pdb)
Configuration
Path mapping and optional MSBuild executable override are configured in MSBuildMcpServer/appsettings.json:
{
"PathMappings": [
{
"WindowsRoot": "D:\\work\\projects",
"LinuxRoot": "/hostdata"
}
],
"BuildTools": {
"MSBuildPath": "C:\\Program Files\\Microsoft Visual Studio\\2022\\BuildTools\\MSBuild\\Current\\Bin\\MSBuild.exe"
}
}
This allows MCP calls to pass Linux paths while the server executes builds with Windows MSBuild-compatible paths.
BuildTools.MSBuildPath is optional. If omitted or invalid, the server falls back to automatic Visual Studio MSBuild path discovery.
Sample files are included in MSBuildMcpServer/:
appsettings.json.sample- starter path-mapping and build-tool configrun.cmd.sample- starter command for running the built server executable
These are templates. Copy and adjust them for your environment, then rename:
appsettings.json.sample->appsettings.jsonrun.cmd.sample->run.cmd
You can customize values (paths, interface, port, etc.) as needed.
Running Locally
From MSBuildMcpServer/:
dotnet restore
dotnet build -c Release
dotnet run
Notes
- C++ and installer builds (
.vcxproj,.wixproj,.sln) prefer Visual StudioMSBuild.exewhen available. - .NET builds use
dotnet msbuild(anddotnet publishfor publish). - If build outputs are locked by a running process, stop that process and rebuild.
