mcp-dotnet-diagnostics

Give your AI assistant real-time visibility into your .NET application's runtime health.

Connect this Model Context Protocol server to Claude Desktop

and ask plain questions about any running .NET process — memory leaks, GC pressure, thread

starvation, allocation hotspots. Claude calls the right tools, reads real runtime data, and

tells you what's actually wrong.

What this looks like in practice

You ask:

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

Claude calls `get_process_info` to confirm connectivity, then `get_memory_stats`, then

`get_gc_events` — and responds:

> *"Every GC event in the last 5 seconds was a Gen2 collection triggered by `AllocLarge`.

> 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 is

> `ArrayPool.Shared`. Rent a buffer, use it, return it."*

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

Tools

Installation

1. Install the tool

dotnet tool install -g mcp-dotnet-diagnostics

Requires .NET 8 SDK or later. Get it here if needed.

2. Add to Claude Desktop

Open `~/Library/Application Support/Claude/claude_desktop_config.json` while Claude Desktop

is fully 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/"
      }
    }
  }
}

3. Reopen Claude Desktop

The `dotnet-diagnostics` connector appears in the tools menu. Ask it about any .NET process.

> macOS: the `TMPDIR` step is not optional.

>

> 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."

>

> Find yours with: `echo $TMPDIR`

> Want to contribute or build from source?

> See CONTRIBUTING.md for how to clone, build, and add new tools.

Usage

Find the PID of your target process:

dotnet-counters ps

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?"

How it works

The server uses `Microsoft.Diagnostics.NETCore.Client` to attach to any running .NET process

by PID — the same library that powers `dotnet-counters`, `dotnet-trace`, and `dotnet-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 calls `get_process_info` first (connectivity), then `get_memory_stats`

(heap overview), then `get_gc_events` (collection details) — because the descriptions say to.

The chaining is implicit, not hardcoded.

Requirements

• .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)

Tests

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.

Design decisions

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

• ADR-001: C# over TypeScript — the diagnostics library is .NET-native; a TypeScript wrapper would mean shelling out
• ADR-002: Target process by PID, not self — the MCP server itself is uninteresting; your API is where the real data lives
• ADR-003: .NET 10 EventPipe payload extraction — undocumented payload structure change in .NET 10, discovered through runtime inspection

License

MIT