今天这篇文章，我会带你了解几个实用的 MCP 服务器。做测试自动化的同学会觉得特别贴合，但其实 IT 行业的人都能用得上。
#ReportPortal MCP —— 怎么从测试结果里拿到实用信息
什么是 ReportPortal MCP 服务器
ReportPortal MCP 服务器，是架在你的 ReportPortal 实例和 AI 助手（比如 Claude Desktop、GitHub Copilot、Cursor）之间的桥梁。简单说，你能用大白话问关于测试运行的问题，直接从 ReportPortal 拿到答案。它完全遵循官方 MCP 规范。
举个例子：不用登录 ReportPortal 界面，你直接问 AI 助手 "上次运行哪些测试失败了""列出最近 5 次测试运行"，它就会去 ReportPortal 拉对应的数据。测试人员和管理者都能用自然语言查询测试结果，分析和汇报效率都更高。
为什么用它
- 快速获取测试洞察：不用写代码、不用翻界面，立刻拿到测试运行汇总、失败数、错误详情。
- 对话式查询：用你常用的 AI 助手（Claude、Cursor 等）直接和 ReportPortal 数据对话，就像聊天窗口里坐了个智能测试报告助手。
- 集成灵活：兼容所有支持 MCP 的 AI 工具，只要指向这个服务器，底层就能自动执行 ReportPortal 查询。
- 不用自定义脚本：常用查询（列运行记录、查失败、做分析）都内置成了简单指令，聊天里就能调用。
目前 ReportPortal 是展示自动化测试结果最好的工具之一。它能聚合不同测试框架的自动化结果，单元测试、功能测试、非功能测试的结果都能存进去，做出清晰全面的看板。
它支持 JUnit、xUnit、NUnit、PyTest 等等 —— 几乎主流自动化测试框架全覆盖。就算用偏小众的框架，加自定义集成也不难，因为 ReportPortal 提供 REST API。我之前和团队做过这类集成，难度不高。
除此之外，ReportPortal 还有个很有意思的机器学习功能，能帮我们减少分析自动化测试结果的时间。更进一步，现在 ReportPortal 官方出了自己的 MCP 服务器，可以装在带大模型的 IDE 里，直接访问测试结果。比如我们可以直接在 IDE 里（比如 Cursor）拿到上次发布的相关信息，用来辅助调试。
这个测试看起来像这样：
为了写这篇文章，我写了一个简单的 Playwright 测试，对接好了 ReportPortal。
我故意加了个错误：实际添加的商品数量是 2，但断言里写购物车里应该有 3 件。运行测试后，ReportPortal 里就出现了这条测试报错。我发了个提示词来查结果：
可以看到，ReportPortal 返回了 Playwright 报错和其他有用信息。我直接给 Cursor 发了个 "修复它" 的指令，大模型就开始尝试修复。
大模型的回复里，建议加一个 requestedQuantity 变量，用来表示购物车里的商品数量，同时用这个变量来校验预期数量。除了优化测试本身，这种复用测试数据的思路还能帮我们优化代码，减少重复。
结果：模型把测试修好了。我们再跑一次...... 测试顺利通过了！不仅如此，模型还发了个 ReportPortal 的链接，指向这次修复后正常运行的测试记录。
#Jira MCP
大家都知道，Jira 是 IT 项目管理的主流工具之一，它也有对应的 MCP 服务器。能把你的 AI 工具（Claude、Cursor 等）和 Jira 实例打通。能做什么？比如你可以直接在 Cursor IDE 里拉取任务描述。想象一下你在 Cursor 里调试测试的时候发现了 bug，不用手动写一堆内容，能自动创建工单 —— 配合合适的提示词或者说明（比如写在 Claude.MD 里的指令），还能直接生成带详细描述的工单。这点在智能体或者子智能体流程里特别好用。
怎么操作
首先，想试的话得有一个 Jira 实例（现成的也行）。我专门建了一个用来演示。下一步生成 API 密钥，用来连接 Jira 实例。
给 Cursor 装 Atlassian 插件
装完插件之后，IDE 里就能用更多功能了。比如直接在 Cursor 里创建 Jira 工单、拉取任务信息。要注意，这种用法在底层联动的时候价值更大 —— 把几个模型串起来，扩展原生大模型的能力。
为了演示，我写了个带错误的测试：给电商演示站的某个商品加评论，但测试里用的邮箱是无效的，不符合邮箱校验规则。很简单的例子，演示 Jira MCP 实际怎么用。
测试跑完之后，我打开 Cursor 的上下文聊天，输入创建 bug 工单的信息 —— 包括上下文和堆栈，方便看工单的人定位问题。
Jira 里就生成了带问题描述的工单。
大模型自动加了不少信息，包括测试标题和测试场景总结。说实话，我没说明是表单校验相关的问题，测试还超时了。但我换了个提示词，让它详细说说怎么解决问题，描述就清楚多了。还能补充更多报错细节，大模型会把缺口补上，效果好很多。
我在提示词里加了点改进建议的提示，发现确实有用。
工单内容描述得很全面，问题是什么一目了然。
更有意思的是，你可以指令提示词在工单里加更多信息 —— 比如可能的解决方案思路。看问题情况（还有给了多少上下文），大模型还能试着给出合适的修复方案。
#GitHub MCP
这个 MCP 集成特别实用。很多人说它是必备的 MCP 之一，因为能调用 GitHub 的大量能力。
大家都知道，GitHub 是全球最主流的 Git 托管平台，也提供 GitHub Actions、Copilot 这类热门 CI/CD 和代码审查工具。
这里特别好用的一点是，我们可以给大模型或者 IDE（连了大模型的）生成的代码建仓库，也能快速改代码。说明一下，这篇文章我用偏手动的方式来演示 MCP 的能力。在子智能体或者智能体模式下，这些操作都能自动完成，整个流程会顺畅很多。日常工作里，这才是工具联动真正发挥价值的地方：智能体发现并修复代码问题，通过 GitHub MCP 直接就能开 PR 提交修改。
怎么用 GitHub MCP
想象一下你用 GitHub 跟踪项目 bug。你可以把失败测试的所有信息录成 issue。还有个例子，我专门为这篇文章建了个私有仓库。操作就是打开上下文窗口，输入提示词让 GitHub 给项目建个仓库。
首先，你得把 GitHub MCP 加到 mcp.json 配置里。不过在这之前，得先给 GitHub 账号生成 token。去这个页面创建：https://github.com/settings/tokens
⚠ 注意：这是高度敏感信息，绝对不要传给模型。
token 加到 mcp.json 配置里之后，我用双重验证登录，模型就自动为这篇文章生成了仓库。
#Playwright MCP
除此之外，这个集成还能用来自动创建 PR。想象一下你有个智能体做代码审查，或者给特定页面生成页面对象。你可以做一套方案：从工单里拿 URL，用 Playwright MCP 生成页面对象，最后开 PR 提交修改。需要操作网页的特定场景里，Playwright MCP 是最好用的工具之一。当然，页面复杂度不同效果不一样，但探索空间很大。
Playwright MCP —— 我之前写过一篇相关的文章《Playwright MCP + Claude AI：理性实验，不夸大》。Playwright 在 AI 场景下有几种用法。首先可以直接用 Playwright MCP。除此之外，还能用 Playwright Agents —— 这个工具包含三个子智能体：规划师、生成器、修复器。还有 Playwright CLI，能帮你有效管理 token 消耗（提醒一下：关于省 token 这个说法我听过不同意见，我自己还没验证过，所以不好说是不是真的更省）。
我认为 Playwright MCP 有几个潜在的使用场景。它能直接导航到你 web 应用的页面，提取特定页面的 HTML。还有 Playwright CLI，之后我会单独写一篇讲。Playwright MCP 还能帮你探索应用，我专门写了对应的提示词。
做得好的地方：
-
用了 fixture 的概念 -
通过 submitReview 方法传测试数据的写法也没问题。添加评论之后断言是有意义的。 -
评论待审核，所以 URL 里有 "unapproved" 字样，大模型建议用正则来匹配。剩下的断言逻辑也合理 —— 屏幕上能看到评论内容，也能看到断言校验的文本。 -
同样，每次 MCP 更新或者模型新版本，我都发现代码质量在提升 —— 前提是生成的时候我们知道怎么正确写提示词。这点很重要，不懂的话，还是可能生成质量很差的代码。
#使用 MCP 的不足
根据我的经验，大模型有时候处理集成会出问题 —— 比如我之前用集成创建 Jira 工单的时候就遇到过问题。得新开一个上下文窗口重新操作一次，才正常运行。
我也发现越来越多工具开始提供命令行集成 —— 比如 Playwright Agents，比 Playwright MCP 耗 token 更少（至少理论上是）。也许未来我们会更偏向命令行方案，而不是 MCP，但我还是觉得社区增长很快。
安全挑战
值得注意的是，MCP 出现之后也产生了新的攻击面，连主流服务都受影响：
2025 年 6 月：Anthropic MCP Inspector 远程代码执行漏洞
事件：研究人员发现 Anthropic 的 MCP Inspector 开发工具，通过其检查代理架构，能实现未授权远程代码执行。攻击者只要让受害者检查一个恶意 MCP 服务器，甚至从浏览器引导检查器，就能在开发机上执行任意命令。
风险与原因：检查器以用户权限运行，在本地监听的时候没有鉴权，利用成功就能拿到开发工作站上的整个文件系统、API 密钥、环境密钥 —— 等于把调试工具变成了远程 shell。
2025 年 8 月：Anthropic 文件系统 MCP 服务器漏洞
事件：安全研究人员发现 Anthropic 的文件系统 MCP 服务器有两个严重漏洞：沙箱逃逸、符号链接隔离绕过，能实现任意文件访问和代码执行。
泄露与原因：能访问主机文件系统，服务器上的敏感文件、凭证、日志等数据都可能受影响。根源是沙箱实现太差，MCP 服务器的文件工具接口，目录隔离管控不足。
当然还有更多 MCP 和大模型相关的安全问题。攻击永远都会有，但保持谨慎就能避免不少。
Token 效率
用大模型的另一个挑战，就是有效管理 token。MCP 往往用得不够高效，用 Playwright MCP 或者 Playwright CLI 的时候特别明显。Playwright CLI 是什么？是个比较新的库，能更高效地用 Playwright —— 因为它不用把庞大的工具 schema 和冗长的无障碍树都加载到模型上下文里，而是用精简的、专门设计的指令让智能体执行。所以 CLI+SKILL 更适合高吞吐量的编码智能体，要同时处理浏览器自动化、大量代码，还要在有限上下文窗口里推理。基于这点，我们可以更高效地利用 token。
有人可能会问 —— 至于吗？我订阅是最高档的。有几个原因：
未来 token 可能会变少，或者更贵。我们现在还在技术普及早期，风投和大模型厂商都在砸钱，鼓励大家用、习惯用。你也知道，早晚他们要开始赚更多钱。就算我们 token 多得用不完，重度使用的话也很容易触顶，大模型厂商已经开始出使用限制了。总而言之，学会高效用 token 很关键。
以后项目越习惯用大模型，使用成本就会在项目总成本里占很大一块。
而且，上下文窗口用得越久，结果可能越差 —— 时间长了幻觉会变多。
还有提示注入的风险 —— 比如拿到系统里不该访问的区域权限。上面举了两个安全问题的例子，还有很多。我想强调的是，只用经过验证的 MCP 服务器，同时尽量少授权限。谨慎一点总没错。当然，全开权限诱惑很大 —— 智能体模式下更快更顺，但另一方面也非常危险，我不推荐。
MD 文件呢
目前用大模型的场景里，有种思路是用 MD 文件给大模型写操作指令。在我看来，MCP 在底层依然有用 —— 比如我们可以在 MD 文件里指定，用 MCP 生成页面对象，或者错误自动同步到 Jira。
CLI 模式呢
我发现 CLI 模式通常 token 效率更高。也有人说更安全 —— 某些场景下确实是。这也是我想专门写一篇的原因之一。不过不是所有工具都有 CLI 模式 —— 比如 ReportPortal 目前还没有 —— 有时候我们就想通过 MCP 组合工具快速验证想法。归根结底看我们要达成什么目标、有多少 token 可用。日常工作里 MCP 依然好用，但复杂流水线的话，CLI 可能是更好的选择。
#总结
这篇文章我演示了几个能帮测试自动化从业者的 MCP 用法。MCP 依然是扩展大模型能力非常有意思的方式。
