SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场diagnostics-mcp

diagnostics-mcp

测试与质量

查看项目

更新于 10-28 01:57

技能介绍

用途

dotnet-diagnostics-mcp 是一个面向 .NET 的诊断类 MCP 服务器，用于在 MCP 驱动的流程中开展 .NET 性能调查。它适用于以下场景：

  • 用户要求安装或使用 dotnet-diagnostics-mcp 进行 .NET 性能调查。
  • 用户提出“对所有单元测试进行性能剖析，并找出被测代码中的瓶颈”。
  • 已连接 MCP 的智能体需要为 .NET 应用的 CPU 热点、分配压力、GC 暂停或等待问题获取运行时证据。

该技能用于此 MCP 服务器的工作流。断言与测试编写应遵循测试框架自身的指引；当问题需要精确的逐操作计时时，应使用基准测试工作流。

安装与连接

通过 dotnet 全局工具安装：

dotnet tool install -g dotnet-diagnostics-mcp

如果已安装：

dotnet tool update -g dotnet-diagnostics-mcp dotnet tool list -g

在客户端原生 MCP 设置中注册 dotnet-diagnostics-mcp，参数为 ["--stdio"]，然后重新加载其 MCP 连接。客户端会启动并拥有该服务器子进程；本地 stdio 不需要 HTTP 守护进程或 bearer token。需确保客户端能在 PATH 上解析该全局工具命令。

Claude Desktop / Cursor 风格配置示例：

{ "mcpServers": { "dotnet-diagnostics": { "command": "dotnet-diagnostics-mcp", "args": ["--stdio"] } } }

检查 tools/list 中的 inspect_process、collect_batch、collect_sample、collect_events 和 query_snapshot。仅安装工具并不会将其连接到当前 AI 会话。如果启动时拒绝符号链接/重解析点路径，请将服务器的 MCP_ARTIFACT_ROOT 环境变量设置为一个已存在、可写且完整路径中不含符号链接的目录；参见工具模式。

工作流

  1. 明确所请求的工作负载、运行时、测试运行器和单元测试项目。在测量运行前构建 Release 二进制及匹配的 PDB。将构建/还原时间与测试执行分开。
  2. 对于全量单元测试请求，遵循测试剖析流程：清点项目，保留正常测试并行度，启动测试套件，并通过命令行发现实际的测试宿主或应用进程。记录每个相关 PID 及其采集窗口。
  3. 使用 inspect_process(view="list", commandLineContains=...) 解析出明确的 processId。使用 view="info" 验证其身份。对于长期运行的应用，view="triage" 可帮助选择下一个采集器；避免把短生命周期测试宿主的存活时间花在预备采集上。
  4. 使用 collect_batch 同时采集 CPU 与托管分配，可选加入 GC 和计数器，最多四项。使用 depth="compact"，并在查询句柄前阅读返回的摘要和各项错误。
  5. 沿热点路径进入被测代码。将产品方法与运行器、fixture、mock、断言、JIT 和分析器开销区分开。使用工具模式进行采集器选择与证据限制。
  6. 使用运行器原生测试过滤器复现疑似热点，同时保留无关的并行执行。比较相同工作负载、运行时、配置、并发度和采集时长。仅在用户请求范围内修改代码，然后重新运行正确性检查与相同的剖析。

流程概览：

flowchart LR A["Release 构建与单元测试清点"] --> B["以正常并行度运行测试"] B --> C["inspect_process：实际测试宿主 PID"] C --> D["collect_batch：CPU + 分配"] D --> E["query_snapshot：产品热点路径"] E --> F["聚焦复现与等负载比较"] F --> G["对瓶颈排序并披露采集缺口"]

实用 MCP 调用

以下为 MCP 工具参数，而非 shell 命令。请将示例 PID 和句柄替换为服务器返回的值。

使用 collect_batch 对运行中的测试宿主进行有界剖析：

{ "processId": 4242, "durationSeconds": 10, "depth": "compact", "requests": [ { "tool": "collect_sample", "kind": "cpu" }, { "tool": "collect_sample", "kind": "allocation" } ] }

使用 query_snapshot 读取 CPU 或分配句柄的调用树：

{ "handle": "<returned-handle>", "view": "call-tree", "topN": 10, "maxDepth": 8, "maxNodes": 40, "depth": "compact" }

交付

  • 记录工具/运行时版本、测试命令、配置、正常并发度、项目与测试数量、PID 身份、采集窗口和测试退出状态。
  • 按测量证据对瓶颈排序：产品方法及可用时的源码位置、样本占比或分配字节信号、受影响的测试组、解读，以及具体的下一步修改或测量。
  • 单独报告测试框架开销。说明缺失的宿主、错过的执行区间、失败的采集器、未解析符号和采样限制。测试套件通过且只捕获到一个 PID，并不能证明每个测试都被剖析过。
  • 保留有用的有界产物或导出的跟踪及其路径。句柄会过期，通常属于当前 MCP 服务器会话。

验证

  • 确认 MCP 连接与所声明的工具 schema；使用当前工具名称和受支持的参数值。
  • 确认样本来自被测测试宿主或应用，而非构建进程或 SDK 包装器。
  • 检查每个批次条目是否有错误，并验证测量窗口与真实测试执行重叠。空剖析结果不具结论性。
  • 将 EventPipe CPU 结果归因为栈频率证据，将分配结果归因为采样证据。使用计数器、争用事件或受支持的阻塞采集器来验证疑似等待。
  • 保留原生测试进度与 ANSI。显示 Warning/Error 诊断以及一条简洁结果；每个诊断响应限制在 80 行 / 8 KiB，保留运行器退出码，并将必要产物保持在模型上下文之外且有大小限制。

来源：dotnet-diagnostics。测试套件覆盖请阅读 test profiling，设置、下钻、配置和源码链接请阅读 tool patterns。