MCP Inspector

[aaronpowell]

.NET Aspire issue link

No response

Overview

MCP Inspector is a debugging tool for working with MCP servers, and it'd be a useful one to combine with Aspire for building MCP Servers with Aspire.

Usage example

builder.AddMcpInspector("inspector")
    .WithMcpServer(api);

This assumes you have a MCP Server at api, and that it's running with SSE mode

Additional context

There are a few issues that make it a little clunky:

• Make inspector available as a Docker image modelcontextprotocol/inspector#237
• Specify transport type on startup modelcontextprotocol/inspector#255
• Setting SERVER_PORT doesn't cascade through to launching the client endpoint modelcontextprotocol/inspector#256

Help us help you

Yes, I'd like to be assigned to work on this item

[NikiforovAll]

Alternatively, you can use https://www.nuget.org/packages/Nall.ModelContextProtocol.Inspector.Aspire.Hosting

AppHost:

var builder = DistributedApplication.CreateBuilder(args);

var sse = builder.AddProject<Projects.MCPServerHybrid>("server");
builder.AddMCPInspector("mcp-sse", serverPort: 9000, clientPort: 8080).WithSSE(sse);

builder
    .AddMCPInspector("mcp-stdio")
    .WithStdio<Projects.MCPServerHybrid>();

builder.Build().Run();

Source code: https://github.com/NikiforovAll/mcp-template-dotnet

[aaronpowell]

Nice - want to combine efforts?

[NikiforovAll]

@aaronpowell

Sure, I'd be happy to contribute!

The idea behind my package is that the MCP Inspector is embedded as an NPM app inside the NuGet package. I'm not sure if that's something you'd want to do since it’s a bit of a "hacky" solution. A more standard approach would probably be to use containers instead.

That said, containers come with their own set of challenges, so I decided to explore a different approach.

[aaronpowell]

Bundling the node packing in the NuGet package would be tricky, as you'd still need to have the node runtime installed when using it.

Containers do pose a problem for stdio in particular since you need to get the executable (or .NET project) into the container and you need the runtime there so it can do dotnet run.

But I feel like from an Aspire perspective, stdio transport isn't the most logical approach you'd take.