mcp-server-testing 是一个面向 MCP 服务器测试与评估的技能。它的核心观点是：MCP 服务器的质量指标是智能体任务成功率，而不是端点覆盖率。单元测试能发现代码缺陷，但无法说明一个零上下文的智能体能否选对工具并完成真实任务。该技能补齐了常被跳过的两层：协议验证（Inspector 与一致性套件）和智能体评估（可验证任务与基于对话记录的迭代），从而避免产出“能跑但用起来失败”的服务器。
不适用场景：修复测试发现的缺陷（stdout 污染、生命周期、schema 代码）应使用 mcp-server-implementation；重写描述或接口面应使用 mcp-server-design；安全检查清单或扫描应使用 mcp-server-security；认证流程问题应使用 mcp-server-auth；非 MCP 代码的通用单元测试或选择 LLM 也不适用。
工作流：
-
第 0 关——构建与启动。tsc/py_compile 通过；服务器能启动；环境校验失败时大声报错。业务逻辑应作为普通函数进行单元测试——如果逻辑只能通过协议测试，说明分层有误。
-
使用 Inspector 进行协议验证。命令示例：npx @modelcontextprotocol/inspector node dist/index.js（或任意启动命令）；Python 快捷方式：uv run mcp dev server.py。提供 Web UI（localhost:6274）和用于脚本化的 CLI 模式。需演练每个原语：每个工具用有效输入、每个工具至少一条错误路径（期望返回带恢复文本的 isError 结果，而不是协议错误或崩溃）、空结果行为（应有解释性文本，绝不能什么都不返回）、超大输入拒绝。若在 Inspector 中可用但在客户端不可用，通常指向 stdout 污染、路径或环境问题，属于 mcp-server-implementation 范畴。保持 Inspector 为最新版本（CVE-2025-49596 影响 0.14.1 之前的版本）。
-
一致性套件。命令示例：npx @modelcontextprotocol/conformance server --url http://localhost:3000/mcp；npx @modelcontextprotocol/conformance list 可列出可用场景。这是官方基于场景对生命周期、传输和功能行为的检查（--spec-version 选择修订版本）。需对每个失败进行分诊；一个能通过 Inspector 点击但未通过一致性套件的服务器存在真实客户端会发现协议缺陷。
-
智能体评估——质量门禁。方法（完整细节与模板见 references/agent-evals.md）：针对真实数据编写约 10 个评估问题，要求独立、只读、复杂（多跳、改写措辞使关键词搜索无法走捷径），每个问题有唯一稳定、可验证的答案和声明的格式。在接受每个问题前，自己先用工具解一遍——未解决的问题具有诊断价值，错误答案则有害。对套件进行 lint：python3 "${CLAUDE_SKILL_DIR}/scripts/lint_eval_suite.py" evals.xml。通过智能体测试框架对运行中的服务器执行，按精确匹配评分；记录准确率、工具调用次数、延迟、token 以及智能体自身的反馈。阅读失败的对话记录——描述正是在这里被修正。将对话记录交给编码智能体以提出描述/schema 修改建议（接口面规则见 mcp-server-design），保留一个留出子集，重新运行。
-
将工具选择准确率作为分类评估。当智能体选错工具时：构建 prompt→期望工具 的配对，离线运行仅选择的评估（成本低、不执行），通过重写重叠的描述来修复，而不是对智能体做提示调优。在 CI 中加入描述重叠检测，防止未来编辑悄悄让两个工具再次冲突。
-
CI 中的回归门禁。每次工具处理器或描述变更都运行：构建、一致性套件（或脚本化的 Inspector CLI 通过）、评估套件（低于阈值则失败）、schema 快照差异（破坏性变更告警），以及兄弟技能提供的 stdio 卫生与安全检查。评估失败应像单元测试失败一样阻止合并。
-
对远程服务器进行负载测试。向 MCP 端点发送真实的 tools/call POST 请求（请求头很重要：Content-Type: application/json、Accept: application/json, text/event-stream），使用有代表性的工具组合；阈值不达标则运行失败（例如错误率 <1%、p95 < 500ms）；包含一个昂贵工具并观察并发下的会话/认证情况。k6 模板见 references/agent-evals.md。
输出规范：一个经过测试的服务器应满足：Inspector 对每个原语（含错误/空路径）通过；一致性套件全绿（失败以书面形式分诊）；约 10 个已验证问题的评估套件及基线准确率报告（准确率、工具调用、token），并至少完成一轮由对话记录驱动的改进循环；CI 运行构建 + 一致性 + 评估 + schema 差异；远程部署有负载测试阈值。
常见陷阱：自我评估近乎随机——评估答案应按精确匹配或由不同会话/模型评分，绝不用产生答案的智能体本身。与无服务器基线对比一次：如果智能体在没有你的服务器时得分相同，那服务器就是上下文税（应重新设计，不要发布）。答案必须稳定：不要用“当前”“最新”或实时计数；使用固定时间窗口和历史数据。动态答案会让准确率变成噪声。不要过拟合：在完整套件上调优的描述会记住它——要留出。评估问题不得要求写入；破坏性路径测试属于护栏回归（被禁止的操作必须被拒绝，见 mcp-server-security），针对夹具运行。模型升级会改变选择行为——当客户端默认模型变化时重新运行选择评估，而不仅仅是代码变化时。
参考指针：references/agent-evals.md——问题要求与创建流程、正反示例、测试框架设计（智能体循环、评分、报告）、选择评估格式、k6 负载测试模板、一致性/Inspector CLI 参考。scripts/lint_eval_suite.py——确定性评估套件 linter（计数、重复、稳定性启发式、答案泄漏检查）。