三步跑通 AI 技能评估：用 10 道测试题给 MCP 服务器打分

三步跑通 AI 技能评估：用 10 道测试题给 MCP 服务器打分

【免费下载链接】skillsPublic repository for Agent Skills项目地址: https://gitcode.com/GitHub_Trending/skills3/skills

MCP 服务器写完，工具描述也调过了，可模型实际用起来到底行不行？不少人的判断还停留在"感觉还行"。GitHub_Trending/skills3/skills 里的 mcp-builder 模块内置了一套 AI 技能评估流程：丢给它 10 道固定问题，让它只靠你暴露的工具独立作答，再用准确率、耗时、工具调用次数这些评估报告指标给你打分。入口脚本在 evaluation.py，本地 stdio、远程 SSE/HTTP 都能测。

这个工具替你干了什么

自己口头试几次，你只能验证"这一个问题能不能答对"；换个问题、换个会话，结果可能完全不一样。这套机制的做法是把"模型 + 你的 MCP 工具"当成一个闭环来压测：每道题它要自己规划、自己调工具、自己汇总，答完自动比对标准答案。也就是说，MCP 技能测试的对象不是你的工具文档有多漂亮，而是模型在零额外上下文时，能不能真把事办成。跑完还会输出每道题的过程总结和模型对工具的主观反馈，方便你下一轮改工具。

三步跑通一次评估

先装依赖，只需要 anthropic 和 mcp 两个包：

pip install -r skills/mcp-builder/scripts/requirements.txt

然后写一份 evaluation.xml：根节点 evaluation 下放 10 个 qa_pair，每个 pair 里一个 question、一个 answer（标准答案，必须是单一值）。本地 stdio 服务器跑一次的最小命令长这样，加 -u 换成 SSE/HTTP 地址即可：

python skills/mcp-builder/scripts/evaluation.py -t stdio -c python -a my_mcp_server.py evaluation.xml

不想刷屏可以把报告写到文件，也可以用 -m 指定模型。

报告里的四个数字，分别看什么

• Accuracy：实际答案和标准答案做字符串直接对比得出。答不对时，多半不是"运气差"，而是工具描述含糊、参数没写清、返回结构模型读不懂。
• Average Task Duration：单题端到端耗时。整体偏长时，别只看总数，翻每题的工具调用明细找慢在哪一步。
• Average Tool Calls per Task：调用次数。偏多通常意味着工具粒度太细或返回太散，模型要绕很多圈才能拼出答案——这往往比耗时更早暴露问题。
• 每题的summary / feedback：模型亲笔写的"我为什么这么调"和"这工具哪里别扭"，改工具时优先从这里下手，比你自己盲猜高效。

改进闭环就是：看指标定位 → 改工具描述或返回 → 重跑同一份题目确认分数变化。

怎样把测试问题写"刁钻"

题目固定 10 道，硬性要求：只读、相互独立、非破坏性，答案是单一值且能稳定不变。写法上可以试试这几条：

• 做多跳问题：答案要靠连续多次工具调用串起来，前一步的输出是后一步的输入。
• 绕开关键词：用同义词、上位概念描述目标，逼模型自己推导，而不是关键词一搜就中。
• 塞进聚合和计算：分页拉取、跨多条记录汇总、时间或数量推算。
• 压测大返回：故意触发大 JSON 或长列表，看模型会不会被信息淹没。
• 保持现实感：问的是真实用户会关心的信息检索，不为绕而绕。

卡住了怎么办

• STDIO 连不上：先单独执行那条启动命令，确认服务本身能拉起。
• SSE/HTTP 连不上：确认 URL 可达、鉴权头（-H）拼写正确。
• 报告题目数为 0：检查 XML 里每个 qa_pair 是否都有 question 和 answer 两个节点。

这套流程最适合刚做完 MCP 服务器、想知道"模型到底能不能用我的工具把事办成"的开发者。花半天把 10 道题写好，之后每次改工具都重跑一遍，比反复"我觉得变好了"踏实得多。

【免费下载链接】skillsPublic repository for Agent Skills项目地址: https://gitcode.com/GitHub_Trending/skills3/skills