Replies: 1 comment
-
|
If you want an MCP server that can use either transport, this only requires a little bit of extra code in the Program.cs. Here's an example from a project I recently built: if (args.Contains("--stdio"))
{
var builder = Host.CreateApplicationBuilder(args);
builder.Logging.AddConsole(options =>
{
options.LogToStandardErrorThreshold = LogLevel.Trace;
});
RegisterHttpClient(builder.Services);
ConfigureMcp(builder.Services.AddMcpServer(ConfigureOptions).WithStdioServerTransport());
await builder.Build().RunAsync();
}
else
{
var builder = WebApplication.CreateBuilder(args);
RegisterHttpClient(builder.Services);
ConfigureMcp(builder.Services.AddMcpServer(ConfigureOptions).WithHttpTransport());
var app = builder.Build();
app.MapMcp();
app.Run();
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Discussion Topic
The stdio and HTTP transport are well abstracted in the library, but the local mcp servers are treated as a special case.
In the old times we had COM and Remoting which provided the "transparency" concept as opposed to the SOA architecture.
What I am asking is the ability to activate an MCP server regardless it is in-process or over stdio/HTTP. The protocol decision should be just a matter of configuration settings.
I already implemented the required code on my own, which consists on:
Pipesneeded to communicate with the inproc MCP serverBeyond the choices I made for my own scenarios, I believe that supporting the transparency concept could be really helpful for application developers.
Any thoughts?
Beta Was this translation helpful? Give feedback.
All reactions