Add ModelContextProtocol.Core package

[halter73]

I started this change trying to keep the IMcpServerBuilder in the ModelContextProtocol.Core package even after removing these dependencies, and while this is technically possible, it comes with too many downsides. Some of these we already knew, like the fact that anyone using AddMcpServer would still have to manually run the server (possibly via their own hosted service) after they built the ServiceProvider/Host.

However, the biggest issue, and the one that made me step back and reevaluate the approach was that the IMcpServer that gets registered by methods like WithStdioServerTransport via AddSingleSessionServerDependencies would not get any options configured using the options pattern unless someone knows to manually set up a new IMcpServer registration to read from IOptions<McpServerOptions>.

I considered keeping AddMcpServer(this IServiceCollection services, Action<McpServerOptions>? configureOptions = null) in the ModelContextProtocol package and just removing the configureOptions parameter. It'd then be possible to just add an overload in the AspNetCore package that does take configureOptions, but that would make things worse in my opinion. This would mean that builder.Services.Configure<McpServerOptions>(options => { }) would only work if you called the overload in the AspNetCore package which I think would be extremely confusing.

As ModelContextProtocol.TestServer demonstrates, you can still write a stdio server with just the ModelContextProtocol.Core package, so I do like this change over removing the server completely from the core package. However, I do realize that it's far less convenient to configure a stdio server without the IMcpServerBuilder, and people writing stdio-only servers likely won't want the AspNetCore framework reference.

The current iteration of this PR introduces a ModelContextProtocol.Core package that trims out the hosting and options dependencies from the existing ModelContextProtocol package. The new ModelContextProtocol depends on the Core package and exposes the same IMcpServerBuilder builder APIs as before. is basically the same as what ModelContextProtocol was previously and depends on the ModelContextProtocol package as it is in this PR. So we'd have three packages:

• ModelContextProtocol.Core
  • Depends on Microsoft.Extensions.AI.Abstractions
  • Depends on Microsoft.Extensions.Logging.Abstractions (and thereby M.E.DI)
  • Depends on System.Net.ServerSentEvents
• ModelContextProtocol
  • Depends on ModelContextProtocol.Core
  • Depends on Microsoft.Extensions.Hosting.Abstractions (and thereby Options, Diagnostic.Abstractions, etc...)
• ModelContextProtocol.AspNetCore
  • Depends on ModelContextProtocol.Hosting
  • Depends on Microsoft.AspNetCore.App FrameworkReference

This possibly helps address some concerns about dependency bloat for clients raised in #369 @KrzysztofCwalina.

[eiriktsarpalis]

I think the best solution would be to introduce a ModelContextProtocol.Hosting package that is basically the same as what ModelContextProtocol was previously and depends on the ModelContextProtocol package as it is in this PR.

It sounds like that this might make it easier for a particular server to switch from stdio to http and vice versa, while also ensuring that the core protocol is contained in a leaner package.

[halter73]

Alright. I updated this PR to add a ModelContextProtocol.Hosting package for the code that was previously moved directly up to the ModelContextProtocol.AspNetCore package. ModelContextProtocol.Hosting includes everything that used to be in the core ModelContextProtocol package.

The markdown link failure is because the new README points to https://www.nuget.org/packages/ModelContextProtocol.Hosting which doesn't exist yet.

[eiriktsarpalis]

You might also want to update the root README.md so that the new structure is documented.

[halter73]

You might also want to update the root README.md so that the new structure is documented.

Done.

[eiriktsarpalis]

[stephentoub]

This seems reasonable. I keep waffling about either moving more stuff from MCP.Core up into MCP, but based on the previous experiments in #369, doing so saves very little size, and the real win is just in removing the extra dependencies, which then means the goal is to put into MCP only the minimum amount that requires the dependencies, and I think that's what you have, yes?

[halter73]

which then means the goal is to put into MCP only the minimum amount that requires the dependencies, and I think that's what you have, yes?

Exactly. The goal here was not to reduce the assembly size of the Core package but to remove the extra dependencies.

[eiriktsarpalis]

Love the way diffs work in slnx