There is no new telemetry here — it is EventPipe, the same source dotnet-counters reads. What changes is that a question like 'why is memory climbing on this PID' turns into the right three calls in the right order, because the tool descriptions were written to lead the model through them. Investigating a process on another machine is not what this is for; it attaches locally by PID.
A diagnostics server that attaches to any running .NET process using the same library behind dotnet-counters and dotnet-trace, streaming telemetry from the runtime over EventPipe and returning it as structured tool responses.
- get_process_info — name, PID, uptime, .NET version and OS; the call that confirms the process is reachable
- get_memory_stats — GC heap, large-object-heap size, allocation rate, per-generation counts and fragmentation
- get_gc_events — a per-collection timeline with the generation and the reason each one fired
- get_thread_stats — thread pool count, queue depth, completed items and lock contention
- get_event_counters — the System.Runtime metrics in one snapshot for a broad health check
- get_environment_info — runtime configuration and environment variables with secrets filtered out
- list_counters — raw counter names and current values, for a process you do not know
- Tool descriptions written so the model chains them itself: connectivity, then heap, then collections
A running .NET process and its PID — dotnet-counters ps will find it. Installed as a global .NET tool, needing the .NET 8 SDK or later. On macOS you must set TMPDIR in the client config to the value echo $TMPDIR gives you: the diagnostics socket lives there rather than where the library looks by default, and without it every call reports the process as not found.
One command — dotnet tool install -g mcp-dotnet-diagnostics