Sending additional data to MCP server tool calls

[fthbrmnby]

I have a case where I need to send some additional data (e.g. context data) along with tool arguments to MCP servers' tool calls using dotnet. The data I want to send is not static, it might change per request so I cannot send as HTTP headers because there isn't a way to set HTTP headers per tool call request as far as I know. Is there a way to handle this?

I saw #2290 and tried to write a custom middleware where I intercept tool calls to modify the request, but could not found a way to pass the additional data I want to send to middleware or a property in the request object to set the values to MCP tool call.

[fthbrmnby]

For anybody wondering, I have found a solution by writing an McpClientTool wrapper that implements the AIFunction class and setting the values I want to send to ModelContextProtocol.RequestOptions' Meta object. During agent initialization wrap your existing MCP tools with this class.

class CustomTool(McpClientTool tool) : AIFunction
{
    private readonly McpClientTool _internalTool = internalTool;

    protected override async ValueTask<object?> InvokeCoreAsync(AIFunctionArguments arguments, CancellationToken cancellationToken)
    {
        var meta = new JsonObject();
        meta.Add("key1", JsonValue.Create("value1"));
        var requestOptions = new ModelContextProtocol.RequestOptions { Meta = meta };
        return await _internalTool.CallAsync(arguments, options: requestOptions, cancellationToken: cancellationToken);
    }
}

[stephentoub]

Why does that impact your ability to use WithMeta? It shouldn't be any different from your custom tool example. You can call WithMeta to produce a different tool instance from the original each time you want one with different values baked into it.

[fthbrmnby]

I don't think that is a good design to create a new tool instance when you can use the same tool with different meta properties. Then there is the issue of registering duplicate tools with different meta values to agents, how the agent should know which tool to invoke when there is multiple tools with the same name? I only register the tools to agents during agent creation, the tool to invoke and the tool parameters are controlled by the AIAgent implicitly.

[stephentoub]

How is this different from your CustomTool solution? And why is it problematic having a separate .NET object for each set of meta values? I'm not understanding the objection or alternative.

[fthbrmnby]

The solution you suggested requires creating new tool instance for each new set of meta properties, the solution I suggested creates only one tool instance but changes the meta property that is sent to the MCP server during tool call.

Let's say we have a tool called GetWeather(string location) and we want to send a userID property to the tool server along with the location parameter. For each new userID we need to create a new tool instance if we go with your solution:

McpClientTool getWeatherTool = ...;

// for userID = 1
var getWeatherTool1 = getWeatherTool.WithMeta(new()
{
    ["userID"] = 1,
});

// for userID = 2
var getWeatherTool2 = getWeatherTool.WithMeta(new()
{
    ["userID"] = 2,
});

But I think this is reduntant and bad code. Instead you could do something like:

McpClientTool getWeatherTool = ...;

// use this instance for all GetWeather tool calls, don't need to create a new instance for each new userID
CustomTool getWeatherCustom = new CustomTool(getWeatherTool);

Inside the CustomTool class' InvokeCoreAsync method, get the userID and send it

protected override async ValueTask<object?> InvokeCoreAsync(AIFunctionArguments arguments, CancellationToken cancellationToken)
    {
        var requestContext = GetContext();
        var meta = new JsonObject();
        meta.Add("userID", JsonValue.Create(requestContext.UserID));
        var requestOptions = new ModelContextProtocol.RequestOptions { Meta = meta };

        // the _internalTool is an instance of the GetWeather tool
        return await _internalTool.CallAsync(arguments, options: requestOptions, cancellationToken: cancellationToken);
    }

I think this is a better solution because you only have one instance of the same tool instead of creating a new tool instance for the same method with different meta parameters.

Then there is the usage issue, this is how I create an AIAgent in my code. This code runs only once, during startup:

var config = // Get agent config
var tools = // Get available tools from MCP servers
var chatClient = // Get chat client to use

var agent = chatClient.CreateAIAgent(new ChatClientAgentOptions
{
    Name = config.AgentName,
    ChatOptions = new()
    {
        Instructions = config.Instructions,
        Tools = tools.Select(t => new CustomTool(t)).ToArray() // This is where my custom tool is used
    });

return agent;

Later on when the service gets a request:

public async IAsyncEnumerable<string> StreamChatResponseAsync(
    string agentName,
    string message,
    [EnumeratorCancellation] CancellationToken cancellationToken = default)
{
    AIAgent agent = _agentRegistry.GetAgent(agentName); // Get the agent instance created during service startup.
    await foreach (var update in agent.RunStreamingAsync(message, cancellationToken: cancellationToken))
    {
        yield return textContent.Text;
    }
}

As you can see I don't manage the tool calls, the agent does; I only call the agent's RunStreamingAsync method. I don't see how your suggested solution fit into this? Do I create a new tool instance, register it to agent and then run the agent's RunStreamingAsync method in StreamChatResponseAsync method for each request?

[stephentoub]

Your example was using constants:

meta.Add("key1", JsonValue.Create("value1"));

That's what WithMeta is for, when the tool instance you need to use has fixed meta values. If you have to use a single AITool instance and have the meta values change dynamically on every invocation, then yeah, you'd want a custom AIFunction like you wrote.

[wimvanhouts]

Hi, I had a similar request and discussion here: modelcontextprotocol/modelcontextprotocol#1701. There seems to be no valid solution yet, and I'm "happy" to see that I'm not the only one experiencing this requirement. Though this workaround with CustomTool and meta works, I was/am hoping for an official and better solution that more tools can support as it is part of the protocol. Willing to discuss and follow up on this ....