get_process_infoLABSCO SUMMARY
The same data as the .NET CLI tools, asked in a sentence.
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.
What it is
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.
What you get
- 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
Requirements
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.
Setup effort
One command — dotnet tool install -g mcp-dotnet-diagnostics
USE CASES
01
Working out why a service keeps growing
Confirm the process, read the heap and allocation rate, then look at what each collection was triggered by.
02
Explaining latency that has no slow query behind it
Read the GC timeline for pauses and the thread pool for queue depth and contention.
03
Finding out why requests are backing up
Check thread pool count, queue depth and completed items rather than adding logging.
04
Taking a quick reading on an unfamiliar service
Pull the whole runtime metric set in one snapshot before deciding what to chase.
05
Ruling out configuration
Read the runtime config and the non-secret environment the process actually started with.
7 tools
Listed in project docs. Your client may show a different list.
get_memory_statsget_gc_eventsget_thread_statsget_event_countersget_environment_infolist_countersBEFORE YOU INSTALL
What to know first
Tools you get
7 tools named in the project's documentation.
Requires
- mcp-dotnet-diagnostics on PATH
- .NET 8
Where it runs
The documented client runs the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
dotnet tool install -g mcp-dotnet-diagnosticsMCP Clients
Claude Desktop
CLAUDE DESKTOP · JSON
{
"mcpServers": {
"dotnet-diagnostics": {
"command": "mcp-dotnet-diagnostics",
"env": {
"TMPDIR": "/var/folders/xx/<YOUR_TMPDIR>/T/"
}
}
}
}
