Customizing Tool Invocation in IChatClient to Include ProgressToken

[LuisM000]

Is your feature request related to a problem? Please describe.

Currently, when manually invoking a tool using the Model Context Protocol C# SDK, it's straightforward to include a ProgressToken. For instance:

var result = await client.SendRequestAsync<CallToolResponse>(new JsonRpcRequest()
{
    Method = RequestMethods.ToolsCall,
    Params = new CallToolRequestParams()
    {
        Name = progressTool.ProtocolTool.Name,
        Meta = new() { ProgressToken = new("abc123") },
    },
}, TestContext.Current.CancellationToken);

However, when utilizing the IChatClient and passing tools obtained from mcpClient.ListToolsAsync(), as demonstrated in the ChatWithTools sample

csharp-sdk/samples/ChatWithTools/Program.cs

Line 43 in 674cb15

await foreach (var update in chatClient.GetStreamingResponseAsync(messages, new() { Tools = [.. tools] }))

There doesn't appear to be a method to customize the tool invocation to include a ProgressToken.

Describe the solution you'd like

Introduce a mechanism within the McpClientTool or related classes that allows developers to customize tool invocations, enabling the inclusion of parameters like ProgressToken. This could involve enhancing the McpClientTool class to be more flexible or providing hooks/callbacks to modify tool call parameters before execution.

Describe alternatives you've considered

One alternative could be modifying the McpClientTool class to be non-sealed, allowing developers to inherit from it and create customized implementations that can include the ProgressToken or other parameters as needed.​

[PederHP]

Would it be useful to have something like this: #165 , but adding a WithMeta() that is then used in the invocation?

[LuisM000]

Would it be useful to have something like this: #165 , but adding a WithMeta() that is then used in the invocation?

Yes, something like that could work. We would also need changes in InvokeCoreAsync to support the Metadata. However, it might not be a problem, but it seems that if we continue like this, it would grow endlessly by creating With... methods, which may not be a problem, but should be taken into account. Thank you!

[PederHP]

Yes, something like that could work. We would also need changes in InvokeCoreAsync to support the Metadata. However, it might not be a problem, but it seems that if we continue like this, it would grow endlessly by creating With... methods, which may not be a problem, but should be taken into account. Thank you!

The reason that Name and Description have With style semantics is because C# doesn't allow adding a getter when overriding an abstract class property which only has a setter, so it's not actually possible to make those mutable.

So a Meta property is another option. This does make the class an odd mix of immutable and mutable semantics, but as you said it might grow over time as the need for other injections and overrides appear.

[stephentoub]

We're on a path of creating a large feature out of something that was supposed to be simple. An equivalent of McpClientTool can be written by anyone. If I want an AIFunction that has a custom name, description, and invocation logic, I just derive from AIFunction and override the relevant members.

I'm not saying we shouldn't do more here, but we should keep it in perspective. At some point of trying to make McpClientTool be everything to everyone, it'll fall over under its own weight.

[PederHP]

We're on a path of creating a large feature out of something that was supposed to be simple. An equivalent of McpClientTool can be written by anyone. If I want an AIFunction that has a custom name, description, and invocation logic, I just derive from AIFunction and override the relevant members.
I'm not saying we shouldn't do more here, but we should keep it in perspective. At some point of trying to make McpClientTool be everything to everyone, it'll fall over under its own weight.

That's a good point, and I must admit I missed that Meta isn't actually part of the Tool schema. It's part of the CallToolRequest schema. So it would actually be wrong to add it here. My bad for missing that.

I think if Meta had been on Tool (in the spec) it wouldn't be a problem to add that part of the spec - but it isn't. So if someone wants to use the class to carry the request Meta property, that's on them to provide.

I guess the solution is to instead find general way to provide access to the Meta properties of various protocol types in a way which doesn't add cumbersome abstractions. In this it's probably easiest to do as you describe and create a derived class.

[LuisM000]

@stephentoub @PederHP I understand the point, and it makes sense not to keep expanding the class without carefully considering its evolution. However, I do miss having a bit more flexibility to customize certain aspects without needing to replicate code from ListToolsAsync and McpClientTool.

That said, it’s not a dealbreaker. As you mentioned @stephentoub, inheriting from AIFunction and creating a ListToolsAsync that generates instances of that type is a viable solution.

For now, I’ll close the issue since my main question was whether I was missing something or if I actually needed to create a custom implementation outside the SDK.

Thanks, everyone!

[stephentoub]

Thanks, @LuisM000. Let's actually keep it open. We can use it to explore ways to make this better.

[DavidParks8]

We need a solution to this problem. Preferably one which makes the existing semantic kernel samples "just work". I think there’s a path forward that would let us support progress tokens (or other per-invocation metadata) in tool calls.

What if we let the SDK offer a hook for customizing how tools are created in ListToolsAsync()? For example, we could add a ToolFactory property (or delegate) on IMcpClient that gets called for each ProtocolTool. If you don’t set it, everything works as before and existing samples remain untouched. But if you do set it, you could return a custom/wrapped tool that, say, adds a ProgressToken to outgoing calls.

This keeps things clean:

All sample code or SK demos that use ListToolsAsync just work.
If we want progress reporting (or any similar feature), we can set one factory and all the tools get the needed customization automatically.
And it avoids the need for a bunch of specialized “WithMeta”/“WithWhatever” methods.

[stephentoub]

Preferably one which makes the existing semantic kernel samples "just work"

What is it you actually want it to do? Can you show me the code you want to write, including how you'd know in those samples which progress notifications correspond to which invocation, and how you'd ideally be consuming those notifications?

[stephentoub]

Preferably one which makes the existing semantic kernel samples "just work"

What is it you actually want it to do? Can you show me the code you want to write, including how you'd know in those samples which progress notifications correspond to which invocation, and how you'd ideally be consuming those notifications?

e.g. does #312 address your needs?