IMcpServerBuilder should support chaining of multiple WithTools calls

[eiriktsarpalis]

Originally posted by @eiriktsarpalis in PederHP/mcpdotnet#95.

This ties in to my previous comments to @halter73 about overhauling DI integration. The fact that calling WithToolXx multiple times right now leads to handlers being overwritten is problematic, and the design needs to accomodate that. That relates to your suggestion of chaining. Can you open an issue?

Originally posted by @stephentoub in PederHP/mcpdotnet#92 (comment)

[aaronpowell]

This also is a problem if you want to use a combination of WithTools and WithCallToolHandler/WithListToolsHandler (as well as expanded out to prompts, resources, etc.), since the callback used is configured as an assignment.

I've hit this as a problem when trying to work around #69 and #68, as I wanted to fallback to using custom implemented tool handlers but doing so breaks all the tools exposed via WithTools.

[stephentoub]

as I wanted to fallback to using custom implemented tool handlers

How would you expect this to work in combination with specifying tools via attributes?

Locally I have a change I'm testing that overhauls how these tools are registered, to address this issue, but it will still fail (throws) if you both set an explicit handler and specify tools via attributes.

[aaronpowell]

as I wanted to fallback to using custom implemented tool handlers

How would you expect this to work in combination with specifying tools via attributes?

I would imagine it working like how the routing ending in aspnet works because (at least in my mind) that's how I think about the incoming messages - something to be routed to a handler.

[stephentoub]

I would imagine it working like how the routing ending in aspnet works because (at least in my mind) that's how I think about the incoming messages - something to be routed to a handler.

For example, ListTools. Are you saying you'd expect to be able to add a handler for listing tools, have it list 5 tools, but then augment the result with an entry for every attributed tool? Or are you saying you'd only expect that custom handler to be invoked if there weren't any tools? Or to be able to see what the tools are and decide which of them should be included?

There are a ton of possible policies here. It's not clear to me any is more correct than another.

[aaronpowell]

You're right that there's not "correct" way to tackle this. I think the most obvious approach would be that if there wasn't a tool explicitly configured with the name of the incoming tool, then it'd fall through to the generic callback, assuming you registered one.

If you were to register a tool via WithTools (call it Echo) and then register a WithCallToolHandler with a if (request.Params?.Name == "Echo") the WithCallToolHandler would not get called since the "handler" from WithTools was treated as the priority implementation.

That would avoid a situation where you have to be very away of the order in which you add them to the pipeline.

This would result in an order of Tools from WithTools > WithCallToolHandler > Default handler (essentially raising an error of no matching tool).

[stephentoub]

In that world, what would ListTools do?

[aaronpowell]

It'd be a fair expectation that if you're providing a WithCallToolHandler you also have to provide a WithListToolsHandler so that the client is aware of the tools available, and then it's merged with the tools discovered via WithTools.

We could have an analyzer that looks for WithCallToolHandler calls and warns if there isn't any WithListToolsHandler calls as well.