Do exist any way to add a middleware to "count" all tool invokations ?

[eng-marani]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

My goal is to accumulate statistics about tools usage server side.
I know i can use mpcBuilder.AddCallToolFilter() but this is a fallback called only if requested tool is not found as an already registered tool. What i really want is to monitor all tools invokation, possibly with name and parameters as well.

Do exist any way to be triggered when a tool_call is pushed to the server ?

[ryux1]

For the current 2.x SDK, AddCallToolFilter is the middleware for every matched tools/call; it is not only an unknown-tool fallback. Register it through WithRequestFilters, wrap next, and record before/after execution:

builder.Services
    .AddMcpServer()
    .WithRequestFilters(filters =>
    {
        filters.AddCallToolFilter(next => async (context, cancellationToken) =>
        {
            var toolName = context.Params.Name;
            var started = Stopwatch.GetTimestamp();

            try
            {
                var result = await next(context, cancellationToken);
                ToolCalls.Record(
                    1,
                    new KeyValuePair<string, object?>("mcp.tool.name", toolName),
                    new KeyValuePair<string, object?>("mcp.tool.error", result.IsError is true));
                ToolDuration.Record(
                    Stopwatch.GetElapsedTime(started).TotalMilliseconds,
                    new KeyValuePair<string, object?>("mcp.tool.name", toolName));
                return result;
            }
            catch
            {
                ToolFailures.Add(1, new KeyValuePair<string, object?>("mcp.tool.name", toolName));
                throw;
            }
        });
    })
    .WithTools<MyTools>();

The ordinary call-tool filter runs exactly once before the registered tool. With the Tasks extension it still runs once, in the background after task creation. Configure Tasks before the ordinary filters so the documented ordering is preserved.

If you need to observe all JSON-RPC traffic rather than only tool invocations, use WithMessageFilters(...AddIncomingFilter(...)) and inspect context.JsonRpcMessage, but the typed call-tool filter is the better place for tool metrics and results.

Current filter documentation:
https://github.com/modelcontextprotocol/csharp-sdk/blob/main/docs/concepts/filters.md

One caution: tool arguments frequently contain credentials or user data. Count by bounded tool name and error state; avoid putting raw parameters, tenant IDs, or arbitrary error text into metric labels. If arguments are needed for an audit record, use explicit allowlisting/redaction and access-controlled logs rather than metrics.

[rodri-oliveira-dev]

Hi! I came across your question while looking into observability patterns for MCP servers in .NET.

The current C# SDK documentation describes two interception mechanisms that may help with your use case:

1. WithRequestFilters() + AddCallToolFilter() for instrumenting tool execution.
2. WithMessageFilters() + AddIncomingFilter() for observing incoming JSON-RPC messages before request routing.

For usage statistics, I would consider tracking a few metrics separately:

• Number of tool invocation attempts.
• Number of successful and failed executions.
• Execution duration.
• Tool name and error category.

One important distinction is whether you want to count only tool executions or every incoming tools/call request, including requests rejected before reaching the tool handler.

I would also avoid recording raw tool arguments by default, since they may contain sensitive information. Structured metrics with controlled labels would be a safer approach.

The current filters documentation is available here:
https://github.com/modelcontextprotocol/csharp-sdk/blob/main/docs/concepts/filters.md

Has anyone validated this approach with the latest SDK, particularly for rejected requests and task-backed tool calls?

I think a small end-to-end example combining tool invocation metrics, execution duration and OpenTelemetry would be a useful addition to the SDK documentation.