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 implementation
• MSBuildMcpServer/Program.cs - tool definitions and build execution logic
• MSBuildMcpServer/appsettings.json - path mapping configuration

Key MCP Tools

• build_project - main entrypoint for Build/Rebuild/Clean style actions
• restore_project - dependency restore where relevant
• clean_project - clean outputs
• rebuild_project - clean + build workflow
• publish_project - publish flow for .csproj
• resolve_project_path - resolve Linux/Windows project paths
• get_build_capabilities - discover supported types/modes/mappings
• run_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 config
• run.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.json
• run.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 Studio MSBuild.exe when available.
• .NET builds use dotnet msbuild (and dotnet publish for publish).
• If build outputs are locked by a running process, stop that process and rebuild.