Can McpTools be instance methods?

[jtschuster]

Is there a technical reason that the tools have to be static? I had some instance methods as McpTools in order to use a logger in them, but they were broken by https://github.com/PederHP/mcpdotnet/pull/94/files#diff-1e87fd46aea8e66c8ee4a1e0a60ba98600a6f48c1cff86ee4cd6a87088b0cba7R57

If they need to be static for a particular reason, is there a good workaround to use logging from an ApplicationBuilder inside the tools?

[stephentoub]

The next release of Microsoft.Extensions.AI will make it so that tools can resolve from an IServiceProvider; it's just not there in current bits. That will then let your tools get an ILogger from DI, just not as the receiver of an instance method. I assume that'll address your needs? We're looking at a few different approaches, if you want to weigh in:
dotnet/extensions#6141
dotnet/extensions#6144
dotnet/extensions#6145
dotnet/extensions#6146
(I don't think "Alternate 2" addresses the concern, though, so I don't think we'd just do that one, but possibly in conjunction with one of the others)

[jtschuster]

I think any of those will work for our purpose, but I personally prefer Alternate 1 / dotnet/extensions#6144 just because CancellationToken seems very baked into everything in .NET and makes sense as a first class parameter type, but IServiceProvider seems less so in my (limited) experience.

[jtschuster]

To make sure I understand this, Alternate 1 would allow methods with [AiTool] or [McpTool] to have an IServiceProvider, though, right?

[stephentoub]

To make sure I understand this, Alternate 1 would allow methods with [AiTool] or [McpTool] to have an IServiceProvider, though, right?

Yes.