Feature Request: Support for .NET Server Execution

[foxminchan]

Is your feature request related to a problem? Please describe.
Currently, mcpb does not support launching MCP servers implemented in .NET. Many .NET MCP servers rely on the standard dotnet run workflow, which requires specifying a project file or a C# entrypoint. Without explicit support, .NET developers cannot register or execute their servers using the expected .NET CLI patterns.

Describe the solution you'd like
Add first-class support for .NET server execution, enabling:

1. Project-based execution

   dotnet run --project "Mcp.csproj"

   Here, dotnet is the entrypoint and --project "Mcp.csproj" is the argument.

2. Single-file execution (simplified)

   dotnet run app.cs

   Allowing a .cs file to act as the server entrypoint, with dotnet as the runtime command.

The goal is to let .NET servers fit naturally into the existing MCPB manifest and runtime model without extra wrappers or shell scripts.

Describe alternatives you've considered
A wrapper script (e.g., bash, PowerShell, or shell shim) could be used to invoke dotnet run, but this becomes platform-dependent and breaks the portability goals of MCP. Another alternative is pre-compiling the server, but that removes the dynamic/iterative development workflow that .NET developers typically use.

Additional context
The .NET ecosystem is increasingly adopting MCP. Having native support for .NET launch patterns would streamline development workflows, improve portability across OSes, and align MCPB with other runtimes already supported.

[joelverhagen]

My personal opinion (having worked on NuGet support in the MCP Registry), is that dotnet run --project and dotnet run app.cs should not be supported by MCPB. This would require the consumer to have the .NET SDK (compiler, NuGet, dev toolchain, etc). That is a heavy weight thing. Instead, it might make more sense to include compiled .exe/.dll (assemblies) thus only requiring the .NET runtime.

Alternatively, .NET can be compiled to native assemblies with AOT but this would bring in the platform-specific binary problem alluded to in (#63).

[bryan-anthropic]

Hi @foxminchan — thanks for the proposal. @joelverhagen makes a good point in the comment above: dotnet run requires the full .NET SDK, which is a heavy runtime dependency for end users.

The current workaround is to use AOT-compiled binaries with server.type: "binary" — this produces self-contained executables that don't require the SDK or even the .NET runtime. The tradeoff is that AOT binaries are platform-specific, which ties into the architecture support gap in #10.

For development workflows, dotnet run works today if you set "command": "dotnet" and "args": ["run", "--project", "${__dirname}/Mcp.csproj"] in mcp_config — the manifest doesn't restrict which commands you can specify. The gap is that there's no server.type: "dotnet" that would handle the SDK requirement the way server.type: "uv" handles Python.

Keeping open as a genuine gap for .NET distribution.

[foxminchan]

Thanks for the context @joelverhagen and @bryan-anthropic. I think packaging .NET MCP servers as OCI containers would be a better approach than adding native MCPB support — it avoids the SDK dependency issue and the platform-specific binary problem at the same time.