Expose server info for McpClientTool's returned by Tools.GetFromMcpServers

[comradealpha]

Hi, first of all - thanks for the great library!

I'm using the Tools.GetFromMcpServers() method to generate tools from a config file. The resulting array of McpClientTool instances works well for function invocation.

However, I found no way to determine which server a given tool was generated from. While the associated server name exists in the EndpointName property of the tool's client, it can't be accessed due to client encapsulation.

For my use case (and potentially for others), it would be helpful to know which server a given McpClientTool came from.

Would you consider exposing the server metadata (ServerInfo and/or EndpointName) in the public contract of McpClientTool, or perhaps providing another way to associate a tool with its originating server?

Thanks again!

[gigadani]

Hi @comradealpha .

While the associated server name exists in the EndpointName property of the tool's client, it can't be accessed due to client encapsulation.

Yeah, seems to be true!

But instead of just calling that method once, providing the whole bunch of your server objects and then getting the tools returned in a bunch that one can't figure out which tool is from which server, could you just encapsulate the call, or rather the burst of multiple calls like in my ugly example method below?

private static async IAsyncEnumerable<(string ServerName, Server.McpClientTool[])> FondleThatGetterIdkPlzRenameThisMethodAsync(params McpServerConfiguration[] mcpServers)
{
	foreach (var mcpServer in mcpServers)
	{
		yield return (mcpServer.Name ?? throw new InvalidOperationException("The getter fondler method requires all provided servers to have a name"), await Tools.GetFromMcpServers(mcpServer));
	}
}

(ngl, idk if the McpServerConfiguration.Name? or any other property of that class is the one that you want, but maybe something that's equivalent to ServerInfo could be snatched either straight from that class, or with some other, existing helper method)

[comradealpha]

Thanks, I think splitting the calls to Tools.GetFromMcpServers() per server will do the trick. That would require reading the mcp config in the client code (which is totally fine), but it also means using System.Text.Json for config deserialization() - which might be a slight inconvenience in projects that rely on a different json library, like Json.NET. Still, it's a reasonable workaround.

As an addition, would you consider exposing a separate helper method that reads and parses the mcp server config?

Something like Task<McpServerConfiguration[]> ReadMcpServers(string configurationFilePath)

That way, deserialization could remain encapsulated in the client code, and consumers wouldn't have to deal with config parse directly.

[gigadani]

What say @awaescher, @mili-tan or others?

I can start working on this if the bigger kids in the playground show a green light 😄

[awaescher]

Ha, the bigger kids. I did not look into this but if I understood correctly, you'd add another member to deserialize, right?
I cannot promise to merge anything that comes up but I'd be happy to review any changes.

[gigadani]

Allright. I'll investigate this a bit in the weekend