内容
[](https://glama.ai/mcp/servers/aayushmdesai/mcp-dotnet-diagnostics)
# .NET 诊断工具
为您的 AI 助手提供 .NET 应用程序运行时健康状况的实时可见性。
将此 [模型上下文协议](https://modelcontextprotocol.io) 服务器连接到 Claude Desktop，询问有关任何正在运行的 .NET 进程的常规问题 — 内存泄漏、GC 压力、线程饥饿、分配热点。Claude 调用正确的工具，读取运行时数据，并告诉您实际存在的问题。
---
## 实践中的样子
您询问：
> *"为什么我的 API 内存使用率这么高？进程 ID 是 12345。"*
Claude 调用 `get_process_info` 以确认连接，然后调用 `get_memory_stats`，接着调用 `get_gc_events` — 并回答：
> *"过去 5 秒内的每个 GC 事件都是由 `AllocLarge` 触发的 Gen2 集合。某些东西在 85KB LOH 阈值以上连续分配对象，速度约为 10.5 MB/s。LOH 默认情况下从不压缩 — 碎片化率为 55% 且不断增加。解决方法是使用 `ArrayPool<byte>.Shared`。租用缓冲区，使用它，然后返回。"*
您不必告诉 Claude 调用哪些工具。它会根据您的提问自行决定。
---
## 工具
| 工具 | 返回内容 | 使用场景 |
|------|----------------|----------------------|
| `get_process_info` | 名称、进程 ID、运行时间、.NET 版本、操作系统 | 开始任何调查 — 确认进程可达 |
| `get_memory_stats` | GC 堆、LOH 大小、分配率、Gen0/1/2 计数、碎片化 | 内存高或增长时 |
| `get_gc_events` | 每个集合的时间线 — 代数、原因、时间戳 | GC 暂停影响延迟时 |
| `get_thread_stats` | 线程池计数、队列深度、已完成项目、锁争用 | 请求缓慢或积压时 |
| `get_event_counters` | 所有 27 个 `System.Runtime` 指标的快照 | 想要全面的健康状况概述时 |
| `get_environment_info` | 运行时配置、筛选的环境变量（无机密） | 调试配置问题时 |
| `list_counters` | 原始 EventCounter 名称和当前值 | 发现不熟悉的进程上可用的内容时 |
---
## 安装
**1. 安装工具**
```bash
dotnet tool install -g mcp-dotnet-diagnostics
```
需要 .NET 8 SDK 或更高版本。如果需要，请[在此处获取](https://dotnet.microsoft.com/download)。
**2. 添加到 Claude Desktop**
在 Claude Desktop **完全退出** 时（Cmd+Q — 而不是仅关闭窗口），打开 `~/Library/Application Support/Claude/claude_desktop_config.json`，然后添加：
```json
{
"mcpServers": {
"dotnet-diagnostics": {
"command": "mcp-dotnet-diagnostics",
"env": {
"TMPDIR": "/var/folders/xx/your-tmpdir/T/"
}
}
}
}
```
**3. 重新打开 Claude Desktop**
`dotnet-diagnostics` 连接器出现在工具菜单中。询问它关于任何 .NET 进程。
---
> **macOS：`TMPDIR` 步骤是必需的。**
>
> .NET 诊断协议通过 Unix 套接字查找进程。在 macOS 上，该套接字位于 `$TMPDIR` 下 — 而不是 `/tmp/`，这是库默认查找的位置。如果没有这个，每次调用工具都会返回“进程未找到”。
>
> 使用 `echo $TMPDIR` 查找您的临时目录。
---
> **想要贡献或从源代码构建？**
> 请参阅 [CONTRIBUTING.md](CONTRIBUTING.md)，了解如何克隆、构建和添加新工具。
## 用法
查找目标进程的进程 ID：
```bash
dotnet-counters ps
```
然后自然地询问 Claude：
"对进程 ID 12345 进行全面健康检查。"
"为什么进程 ID 12345 的内存不断增加？"
"进程 ID 12345 中有线程饥饿吗？"
"进程 ID 12345 的 GC 情况如何？"
---
## 工作原理
服务器使用 `Microsoft.Diagnostics.NETCore.Client` 通过进程 ID 附加到任何正在运行的 .NET 进程 — 与 `dotnet-counters`、`dotnet-trace` 和 `dotnet-dump` 使用的同一个库。它直接从 CLR 流式传输 EventPipe 指标，这意味着您获得与官方 .NET CLI 工具相同的数据，以结构化的工具响应形式提供给 Claude。
工具描述用于指导 Claude 的调查顺序。当您报告高内存时，Claude 首先调用 `get_process_info`（连接性），然后调用 `get_memory_stats`（堆概述），然后调用 `get_gc_events`（集合详细信息）— 因为描述中说要这样做。链接是隐式的，而不是硬编码的。
---
## 要求
- .NET 8 SDK 或更高版本用于构建；推荐 .NET 10
- Claude Desktop 或任何 MCP 兼容的客户端
- 要检查的正在运行的 .NET 进程（您的应用程序、API 或任何应用程序）
---
## 测试
```bash
dotnet test src/McpDotnetDiagnostics.Tests
```
所有 7 个工具中有 34 个测试 — 针对无效进程 ID 的单元测试，针对实时测试运行器进程（`Environment.ProcessId`）的集成测试。运行时间约为 17 秒。
---
## 设计决策
三个决策以不明显的方式影响了该项目：
- [ADR-001：C# 而非 TypeScript](docs/adr-001-csharp-over-typescript.md) — 诊断库是 .NET 原生的；TypeScript 包装器意味着需要额外的开销
- [ADR-002：按进程 ID 而非自身定位目标进程](docs/adr-002-target-process-diagnostics.md) — MCP 服务器本身不感兴趣；您的 API 是真正的数据来源
- [ADR-003：.NET 10 EventPipe 有效载荷提取](docs/adr-003-dotnet10-payload-extraction.md) — .NET 10 中未文档化的有效载荷结构更改，通过运行时检查发现
---
## 许可证
MIT
