mcp-dotnet-diagnostics

"Why does my API have high memory usage? PID is 12345."

Claude callsget_process_infoto confirm connectivity, thenget_memory_stats, thenget_gc_events— and responds:

"Every GC event in the last 5 seconds was a Gen2 collection triggered byAllocLarge. Something is continuously allocating objects above the 85KB LOH threshold at ~10.5 MB/s. LOH is never compacted by default — fragmentation is at 55% and growing. The fix isArrayPool<byte>.Shared. Rent a buffer, use it, return it."

You don't tell Claude which tools to call. It figures that out from your question.

dotnet tool install -g mcp-dotnet-diagnostics

Open~/Library/Application Support/Claude/claude_desktop_config.jsonwhile Claude Desktop isfully quit(Cmd+Q — not just the window closed), then add:

{ "mcpServers": { "dotnet-diagnostics": { "command": "mcp-dotnet-diagnostics", "env": { "TMPDIR": "/var/folders/xx/your-tmpdir/T/" } } } }

Thedotnet-diagnosticsconnector appears in the tools menu. Ask it about any .NET process.

The .NET diagnostics protocol finds processes through a Unix socket. On macOS, that socket lives under$TMPDIR— not/tmp/where the library looks by default. Without this, every tool call returns "process not found."

Then ask Claude naturally: "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?"

The server usesMicrosoft.Diagnostics.NETCore.Clientto attach to any running .NET process by PID — the same library that powersdotnet-counters,dotnet-trace, anddotnet-dump. It streams telemetry directly from the CLR over EventPipe, which means you get the same data as the official .NET CLI tools, available to Claude as structured tool responses.

The tool descriptions are written to guide Claude's investigation sequence. When you report high memory, Claude callsget_process_infofirst (connectivity), thenget_memory_stats(heap overview), thenget_gc_events(collection details) — because the descriptions say to. The chaining is implicit, not hardcoded.

- .NET 8 SDK or later to build; .NET 10 recommended
- Claude Desktop or any MCP-compatible client
- A running .NET process to inspect (your app, an API, anything)

dotnet test src/McpDotnetDiagnostics.Tests

34 tests across all 7 tools — unit tests against invalid PIDs, integration tests against the live test runner process (Environment.ProcessId). Runs in ~17 seconds.

Three decisions shaped this project in ways that aren't obvious from the outside:

This is a web browser that enables your coding agent, such as Claude Code, to visit websites on your behalf and assist you in identifying bugs or creating UI test cases.

AI-powered live runtime debugging with Lightrun production context.

Analyze your MCP setup: measure token cost per tool, find bloated schemas, detect duplicates, and get optimization tips to reclaim your context window.

MCP server for .NET runtime diagnostics — memory, GC, threads, and more.

JVM diagnostics MCP server for thread dump and GC log analysis. Detects deadlocks, lock contention, and GC pressure. Runs via npx on Node.js — no JVM or Docker required.

Reticle intercepts, visualizes, and profiles JSON-RPC traffic between your LLM and MCP servers in real-time, with zero latency overhead. Stop debugging blind. Start seeing everything.

Turn natural language into powerful Perfetto trace analysis. Quickly explain jank, diagnose ANRs, spot CPU hot threads, uncover lock contention, and find memory leaks.

Diagnoses token waste in Claude Code sessions with 6 anomaly types and severity scoring. Fully local.

Probe LLM API endpoints and report health metrics including time to first token, latency, and throughput. Check single models or run full config-based health checks.

A server for detecting critical performance issues in code, providing concise analysis and output.