dotnet-tools

The DotNet Tools MCP Server enables Cursor to build and test .NET projects by hosting a dedicated MCP server that runs dotnet build and dotnet test commands behind the scenes. It also provides a CLI mode for managing a local library documentation configuration. When used as an MCP server, Cursor can delegate project building and testing to this server, avoiding terminal compatibility issues and providing a stable integration point for .NET workflows. The server exposes a set of tools for building projects, building solutions, running tests, and accessing or listing documentation resources for libraries configured by the user.

To use it, configure Cursor to point at the server executable and then interact with the built-in MCP tools through the server’s CLI, or rely on the server’s built-in build and test commands during typical Cursor workflows. The CLI mode offers commands to manage a local libraries.md configuration file which teams may use to curate documentation references for NuGet packages or libraries used in the project.

Prerequisites:

• A supported operating system: Windows, macOS, or Linux.
• The .NET SDK installed if you intend to build from source (dotnet publish) or to verify tooling locally.
• Access to download the prebuilt DotNetToolsMcpServer executable or the ability to build it from source.

Option A: Use a prebuilt executable

1. Download the DotNetToolsMcpServer.exe for your platform from the release page.
2. Place the executable somewhere on your system, e.g. C:\path\to\DotNetToolsMcpServer.exe or /usr/local/bin/DotNetToolsMcpServer.
3. Configure Cursor with the path to the executable: { "mcpServers": { "dotnet-tools": { "name": "DotNet Tools Server", "stdio": true, "command": "C:\path\to\your\DotNetToolsMcpServer.exe" } } }
4. Run the server by invoking the executable directly or letting Cursor manage the lifecycle depending on your setup.

Option B: Build from source

1. Ensure the .NET SDK is installed (dotnet --version).
2. Clone the repository and open a terminal in the project root.
3. Build a single-file, AOT-compiled executable (adjust RuntimeIdentifiers as needed): dotnet publish -c Release -r win-x64 -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true (Replace win-x64 with linux-x64 or osx-x64 for other platforms.)
4. The output single executable will be located under bin/Release/netX.X/publish/YourExecutableName.exe (Windows) or the corresponding path for other platforms. Use that path in your Cursor configuration as shown in Option A.

Note: The project is designed to run as a standalone executable, so once you have the binary, no additional dependencies are required at runtime.

Tips and considerations:

• If you upgrade the .NET tooling or libraries in your project, ensure the DotNet Tools MCP Server has compatibility with the dotnet CLI version you are using.
• The CLI mode can be handy for maintaining a local libraries.md file that documents libraries you rely on; ensure the configuration file path matches the locations described in the README.
• If Cursor cannot connect to the MCP server, verify that the command path is correct and that the server executable has execute permissions on your OS.
• For Windows, ensure path strings in JSON are properly escaped (double backslashes). For Unix-like systems, you can use a simple path or adjust to the environment conventions.
• When running the server as an MCP server, the server should expose the required tools (build, build_solution, run_tests, etc.) to Cursor or to the CLI interface depending on how Cursor sessions are configured.