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.