Purpose
This tool is a Model Context Protocol (MCP) server for .NET runtime diagnostics, providing AI assistants with real-time visibility into the runtime health of .NET applications. After connecting it to Claude Desktop, you can ask in natural language about memory leaks, GC pressure, thread starvation, allocation hotspots, and other issues in any running .NET process, and Claude will decide on its own which tools to call, read real runtime data, and provide diagnostic conclusions.
Main capabilities
- Attach to any running .NET process by PID, using the Microsoft.Diagnostics.NETCore.Client library (the same as dotnet-counters, dotnet-trace, dotnet-dump).
- Stream telemetry directly from the CLR via EventPipe, obtaining the same data as the official .NET CLI tools and providing it to Claude in the form of structured tool responses.
- Provides 7 tools, covering process information, memory statistics, GC events, threads, and other aspects; the specific tool names and full coverage are not listed one by one in the material.
- Tool descriptions are designed to guide Claude's troubleshooting order: for example, when reporting high memory, Claude will first call get_process_info to confirm connectivity, then call get_memory_stats to view the heap overview, and then call get_gc_events to obtain collection details. This chained invocation is implicit, not hardcoded.
How to use
- Install the tool: requires .NET 8 SDK or later (recommended .NET 10).
- Add to Claude Desktop: fully quit Claude Desktop (on macOS use Cmd+Q, not just closing the window), open
~/Library/Application Support/Claude/claude_desktop_config.json, add the configuration (the specific configuration content is not given in the material). - Reopen Claude Desktop, and the dotnet-diagnostics connector will appear in the tools menu.
- Find the PID of the target process, then ask questions in natural language, for example: "Do a full health check on PID 12345." "Why is memory climbing on PID 12345?" "Any thread starvation in PID 12345?" "What's the GC situation on PID 12345?"
macOS note: the TMPDIR step cannot be omitted. The .NET diagnostic protocol locates processes through a Unix socket, and on macOS that socket is located under $TMPDIR, rather than /tmp/, which is where the library searches by default. If it is not set, every tool call will return "process not found". You can use echo $TMPDIR to find your own TMPDIR.
Applicable scenarios
- Troubleshoot continuous memory growth in a .NET API or application.
- Analyze GC pressure, such as frequent Gen2 collections and allocations above the Large Object Heap (LOH) threshold.
- Detect LOH fragmentation (not compacted by default).
- Discover thread starvation issues.
- Any scenario that requires runtime diagnostics of a running .NET process without modifying the target code.
Limitations
- Building requires .NET 8 SDK or later, with .NET 10 recommended.
- Requires Claude Desktop or any MCP-compatible client.
- Requires a running .NET process as the inspection target.
- On macOS, TMPDIR must be set, otherwise the process cannot be found.
- The material mentions that .NET 10 EventPipe payload extraction has an undocumented structural change (ADR-003), which may affect compatibility.
- The project contains 34 tests, covering all 7 tools (unit tests for invalid PIDs, integration tests for live test running processes), and runs in about 17 seconds.
- The material does not provide more information such as fees, pricing, or platform support scope.
