Convert EverythingServer to use Streamable HTTP

[mikekistler]

Here's a start at converting the EverythingServer to Streamable HTTP.

There are some things still to fix, but I want to get this posted so folks can have a look.

And we still want to consider how we could make this functional for either STDIO or HTTP.

[mikekistler]

Well this may not be ideal because you can't comment on unchanged lines, and that's exactly where we probably need comments. So I'll just note here:

• The subscribe/unsubscribe handlers need to be fixed. I'm working on that.
• I think the SetLogLevel handler is also broken for HTTP because I think it sets a single _minimumLoggingLevel for all clients. And that's not even necessary because the SDK already saves the LoggingLevel.

[PederHP]

And we still want to consider how we could make this functional for either STDIO or HTTP.

Maybe put all the server logic in an assembly of its own and then reference it from each a STDIO project and an HTTP project with the requisite (quite slim) boilerplate for each? Makes it much more useful as a sample than more complex ways of keeping it in one project, I think. Also helps it be a reference for porting a server from one transport to another.

On the other hand if there is a better and more idiomatic pattern for multi-transport server projects, it should follow that I suppose.

[halter73]

I like that idea @PederHP. One of the primary goals of this PR is just to show in the sample how advanced features can work with the Streamable HTTP transport. There are some key differences from the STDIO transport, even if you don't rely on any HTTP-specific concepts, primarily because the IMcpServer is a singleton service in STDIO mode, but not in Streamable HTTP mode where there are multiple IMcpServer instances which are not 1:1 with the ASP.NET Core request scope. Splitting this sample so the handlers are all implemented in a class library with slim STDIO and HTTP projects that contain basically just Program.cs seems like the most straightforward way to achieve this.

We've also discussed trying to improve the local development experience by adding a command line switch to go between stdio and HTTP transports. This would be nice because while stdio is preferred for most local MCP servers, it's harder to debug during development. We figure that you probably wouldn't need much customization of your ASP.NET Core app in this development-focused mode, and just adding a command line switch would be easier than managing three separate projects.

The downside is that it's more complex and requires the ASP.NET Core runtime even if you decide to use just STDIO. For any scenario where you're considering having both a stdio MCP server and an HTTP MCP server for real remote usage rather than just development, I'd definitely go for a multi-project architecture like you suggest, so it's probably worth having at least one sample demonstrates that project structure.

[mikekistler]

I think I have addressed all of @halter73 's comments. I am still testing to make sure things work as expected but would appreciate feedback on the SubscriptionManager implementation.