[McpServerToolType] class does not support dependency injection for constructors with parameters

[JeffreySu]

Describe the bug
When [McpServerToolType] class has an constructors with arguments need to be dependency injected, it will throw "Cannot resolve scoped service 'xxx' from root provider." when the function was been called by MCP.

To Reproduce
Steps to reproduce the behavior:
I forked this project and built a branch for the Test: https://github.com/JeffreySu/mcp-csharp-sdk/tree/DI-Error-Test/samples/AspNetCoreSseServer

You can run this project and add the Server to a host(like Cursor), then launch "Echo" function, then you can see the error

Expected behavior
Constructors with arguments should be well supported.

Logs

Additional context
For this test project, I added a new class named MyData, and added it to DI register progress:

Then add MyData as a parameter to ctor. of EchoTool class:

[JeffreySu]

I also created a simple project to reproduce this problem, but there was no reply yet: #114 (comment)

[stephentoub]

I assume it's only for scoped services that you're having troubles? If so, that's likely #198.

[JeffreySu]

I assume it's only for scoped services that you're having troubles? If so, that's likely #198.

I cannot sure if it's the sample problem. But I found the point:

https://github.com/JeffreySu/mcp-csharp-sdk/blob/343f0e0107e766eeaaad74a5bf0de0fc129d1325/src/ModelContextProtocol/Configuration/McpServerBuilderExtensions.cs#L44-L44

Here just support for AddSingleton, so when the class needs to be scoped as AddScoped, it wouldn't be found.

And when I cry to change the AddSingleton in source code, an other error raised when the console launch:

So here is the problem: how could AddTools<> and WithToolsFromAssembly() and other functions support for AddScoped?

PS: I re-read the reply of #198, maybe the source of the problem is the same, but the scenarios are different and complicated. In many scenarios, we want to share this class, and hope that this class can work in the system as AddScroped. As a base library, I think it needs to take into account various usage scenarios.

[JeffreySu]

@stephentoub Are there any current plans to support it?

BTW: at present, the Nuget package and the main-branch code seem to be out of sync, causing a lot of debugging trouble, can we consider synchronization processing, like using CI/CD ?

[JeffreySu]

@stephentoub Thank you, I tested with source code is successes, but when I use nuget package is faild with another error:

Does Nuget package out of sync with the source code?

[stephentoub]

We don't publish a nuget package for every commit. As such, the nuget package invariably lags. The package doesn't yet include #276.

[JeffreySu]

@stephentoub Okay, that makes sense, but it's important that master or some distribution branch and Nuget package are synchronized, otherwise the debugger will get very messy, and we've already wasted 2 days on this.

[stephentoub]

otherwise the debugger will get very messy

Can you elaborate on this? Why is the debugger impacted by the current state of the repo? The source you step into when using the nuget should be the source it was built from, not whatever is current in main.