最值得先装的 6 个 MCP：Claude、Codex、Trae 都能用
wayn约 9 分钟但如果让我给 Claude Code、Codex、Trae 配一套日常可用的 MCP，我不会按热度一路装下去。
原因很简单。
BlenderMCP 很火，但不是每个人都做 3D。
AntV Chart 很有用，但更偏内容和数据展示。
搜索类 MCP 很强，但装两个就容易重复。
所以我这次只选 6 个。
标准不是“最火”，而是这几个问题：
能不能让 Agent 少猜？
能不能减少复制粘贴？
能不能提升真实交付质量？
Claude、Codex、Trae 这类工具能不能都接？
装完以后，我是不是一周内真的会用到？
按这个标准，我会先装这 6 个。
先给结论：这 6 个最值得先装
如果你只写代码，前 4 个就够。
如果你还写公众号、做技术调研、整理资料，再加 Firecrawl 和 AntV Chart。
如果你做设计稿转代码，可以把 AntV Chart 换成 Figma MCP。
如果你做搜索型资料整理，可以把 Firecrawl 换成 Tavily。
如果你做 3D、游戏或建模，再考虑 BlenderMCP。
这才是我觉得更真实的选择方式。
Context7：我最怕模型用旧文档写新项目
如果只能装一个开发类 MCP，我会先装 Context7。
它在 LobeHub 上排得很靠前，也确实符合我的使用习惯：写代码时，最怕的不是模型不会写，而是它拿旧 API 写得一本正经。
现在很多框架变化太快。
Next.js、React、Supabase、Prisma、Tailwind、Cloudflare Workers，版本一变，写法就可能变。模型如果只靠训练数据，很容易写出“语法看着合理、项目跑起来报错”的代码。
Context7 的价值就是把最新、版本相关的文档和代码示例拉进上下文。
我会这样用：
按 Next.js 15 最新写法，帮我写 middleware 登录拦截。
先用 Context7 查文档，不要用旧版本 API。
或者：
查一下 Supabase 当前 RLS 策略推荐写法，
然后帮我给 orders 表设计一套用户只能看自己订单的策略。
这类场景里，Context7 不一定让模型“更聪明”，但能让它少胡来。
这点很重要。
AI 编程工具最常见的问题不是完全不会，而是半懂半写。Context7 正好补的是这块短板。
Playwright MCP：前端任务必须让 Agent 看到页面
Playwright MCP 是 LobeHub 最常安装榜里非常靠前的一个，我觉得它确实值得。
它的作用很明确：让 Agent 通过 Playwright 操作网页，读取页面结构、点击按钮、填写表单、检查状态。
对前端来说，这比让模型只看代码靠谱得多。
我以前最烦一种情况：Agent 改完页面，告诉我“已修复”，结果打开浏览器一看，按钮还歪着，弹窗还遮住内容。
有了 Playwright MCP，可以直接这样问：
打开 http://localhost:3000/login，
检查登录按钮是否居中。
如果样式不对，修改代码后重新打开页面验证。
或者：
复现一下筛选条件不生效的问题。
步骤是：进入订单页，选择“待支付”，点击查询。
看页面列表是否真的变化。
这类任务如果没有浏览器能力，模型只能猜。
Playwright MCP 的优势是更偏结构化页面交互，不依赖截图，也不需要视觉模型。它适合让 Agent 做稳定的页面验证、表单测试和简单自动化。
如果你写前端，这个优先级很高。
Chrome DevTools MCP：调试时比 Playwright 更接近现场
Playwright 更像“自动化测试工具”，Chrome DevTools MCP 更像“浏览器调试工具”。
这两个我会分开看。
Playwright 适合点页面、跑流程、验证交互。
Chrome DevTools MCP 更适合看控制台、网络请求、性能 trace、页面加载细节。
LobeHub 的介绍里，Chrome DevTools MCP 可以让 coding agent 控制和检查真实 Chrome 浏览器，用于自动化、调试和性能分析。
我会在这类场景用它：
打开这个页面，检查控制台有没有报错。
如果有，定位到对应源码并修复。
或者：
帮我看一下首页加载慢在哪里。
记录性能 trace，找出主要耗时点。
再比如：
这个接口返回 200，但页面没有渲染。
检查 Network 和 Console，判断是数据结构问题还是前端状态没更新。
这类问题只看代码很容易绕。
浏览器现场会告诉你真正发生了什么：哪个请求失败、哪个 JS 报错、哪个资源堵住、哪个组件没更新。
不过 Chrome DevTools MCP 权限也更敏感。它能看到浏览器内容，甚至可能看到登录态页面。所以我会建议只在开发环境使用，不要随手打开包含敏感信息的浏览器页面。
GitHub MCP：让 Agent 读到真实协作上下文
GitHub MCP 不一定是 LobeHub 首页最显眼的那个，但如果你用 GitHub 做开发，它非常值得装。
因为很多开发任务并不只发生在代码里。
需求在 Issue。
争议在 PR 评论。
失败原因在 Actions。
变更历史在 commit。
上线问题可能挂在 release 或 workflow 日志里。
如果没有 GitHub MCP，你就要不停复制粘贴。
我会这样用：
读取 PR #128 的 review comment，
按“必须修改 / 可以优化 / 需要确认”整理成待办。
或者：
检查最近一次 GitHub Actions 失败原因，
如果是测试问题，定位失败用例和相关代码。
再比如：
根据这个 Issue 找到最可能相关的代码文件，
先不要改，先给我一版实现计划。
这类任务对 Claude、Codex、Trae 都有价值。
Claude 适合把 Issue 和方案拆清楚。
Codex 适合按 PR 评论执行修改。
Trae 在 IDE 里接 GitHub 上下文，也能减少来回切换。
我会给 GitHub MCP 开权限，但不会一上来给满。
读仓库、读 Issue、读 PR、读 Actions 可以先开。自动创建 PR、改 Issue 状态、写评论这种操作，最好确认后再放开。
Firecrawl MCP：写文章和调研时，比普通搜索更实用
搜索类 MCP 里，LobeHub 首页能看到 Tavily 和 Firecrawl 都很靠前。
如果让我二选一，我会更偏 Firecrawl。
原因是我写文章和做资料整理时，经常不只是“搜一下”，而是要把网页内容抓下来、抽取正文、批量整理、做结构化分析。
Tavily 更像搜索入口。
Firecrawl 更像网页抓取和内容提取工具。
如果你主要问“有什么资料”，Tavily 很合适。
如果你要把资料拿回来继续加工，Firecrawl 更适合。
我会这样用：
抓取这 5 个产品官网的 pricing 页面，
整理成一个对比表：套餐、价格、限制、适合人群。
或者：
读取这篇发布公告，
提取和开发者有关的更新点，
不要写成新闻摘要，按使用影响来整理。
再比如：
爬取这个文档站的指定页面，
整理出安装步骤、配置项和常见坑。
Firecrawl MCP 需要 API Key，这点要提前知道。它适合重一点的资料任务，不适合每次随手问一句都调用。
我的建议是：写文章、做竞品、做技术选型的人装 Firecrawl；只是偶尔搜资料，可以先用 Tavily 或客户端自带搜索。
AntV Chart MCP：写技术文章和报告时很加分
LobeHub 最常安装榜里，AntV Chart 也很靠前。
这个 MCP 很容易被开发者忽略，因为它不是“写代码更强”的工具。
但如果你经常写技术文章、做汇报、整理数据，它会很实用。
AntV Chart MCP 可以生成很多图表：折线图、柱状图、饼图、漏斗图、桑基图、流程图、鱼骨图、思维导图、组织结构图、词云等等。
这对公众号文章尤其有用。
比如你写 MCP 推荐文，可以让它生成一张：
帮我生成一张 MCP 使用场景图：
开发文档、页面验证、浏览器调试、代码协作、资料抓取、图表生成。
或者你写模型对比文章，可以让它生成：
根据这张表生成一个雷达图：
维度包括代码执行、文档检索、页面验证、资料调研、可视化输出、团队协作。
再比如写排障文章，可以生成：
画一个故障排查流程图：
用户反馈 -> 复现问题 -> 看浏览器 Console -> 查 Network -> 看后端日志 -> 提交修复。
我把它放进前 6，不是因为每个开发者每天都要画图，而是因为它能明显提升文章、报告、方案的表达质量。
很多内容不是缺结论，是缺一张让人看懂的图。
为什么我没有把 BlenderMCP 放进前 6
按 LobeHub 首页最常安装榜，BlenderMCP 很靠前。
但我没有把它放进这 6 个。
不是它不强，而是它太垂直。
如果你做 3D、游戏、场景建模、动画资产，它值得试。它能把 Blender 接进 MCP，让 Claude 这类工具直接操作 Blender，做场景创建和模型调整。
但对大多数写代码、写文章、做产品分析的人来说，它不是第一批要装的 MCP。
我这篇推荐的目标不是列“最火”，而是列“装完马上能用”。
所以我会先给 Chrome DevTools、GitHub、Firecrawl、AntV Chart 这种更通用的工具留位置。
Claude、Codex、Trae 怎么配，我会按同一套思路
MCP 协议相对统一，但不同客户端配置方式不一样。
Claude Code 通常可以直接命令添加：
claude mcp add playwright -- npx @playwright/mcp@latest
claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest
Codex CLI 常见方式是写到 ~/.codex/config.toml：
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest"]
Trae 更像 IDE 配置，一般放到 MCP 设置里，或者按项目放到配置文件里：
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}
Windows 下如果 npx 启动不稳定，可以包一层 cmd /c：
{
"mcpServers": {
"chrome-devtools": {
"command": "cmd",
"args": ["/c", "npx", "-y", "chrome-devtools-mcp@latest"]
}
}
}
我建议先只配 2 到 3 个。
比如：
Context7 + Playwright + GitHub
等这套用顺了，再加 Firecrawl、Chrome DevTools、AntV Chart。
MCP 不是装得越多越强。装太多以后，Agent 会多一堆工具要判断，反而可能更慢、更乱。
如果是我来装，顺序会这样排
我自己的安装顺序会是：
Context7 Playwright MCP GitHub MCP Chrome DevTools MCP Firecrawl MCP AntV Chart MCP
为什么 Chrome DevTools 排在 GitHub 后面？
因为 GitHub 是协作上下文，几乎所有项目都会用。Chrome DevTools 更偏前端和浏览器调试，如果你主要写后端，它可以往后放。
为什么 Firecrawl 没有排更前？
因为它更适合资料型任务。写文章、做调研的人会很爱；只写业务代码的人，不一定每天用。
为什么 AntV Chart 还能进前 6？
因为它不是提高模型智商，而是提高表达质量。写技术方案、公众号文章、数据分析报告时，一张图的价值很大。
最后我的判断
MCP 真正有价值的地方，不是让 Claude、Codex、Trae 多几个按钮。
而是让它们接触真实现场。
真实文档。
真实页面。
真实浏览器。
真实 PR。
真实网页内容。
真实图表输出。
这 6 个 MCP，我会优先推荐：
Context7 解决文档过期。
Playwright 解决页面验证。
Chrome DevTools 解决浏览器调试。
GitHub 解决协作上下文。
Firecrawl 解决资料抓取。
AntV Chart 解决可视化表达。
如果你只是想尝鲜，先装 Context7 和 Playwright。
如果你想把 AI 工具真正用进日常工作，再把 GitHub、Chrome DevTools、Firecrawl、AntV Chart 补上。
MCP 不需要一次装满。
先装最能减少返工的那几个，就够了。
最后分享一下我在用的中转站 Unity2.Ai 。它支持codex、claude code、IDE 和各类现成工具集成会比较省事，适合想尽快跑起来的人。注册地址：https://unity2.ai/register?ref=TvkMJGTU&source=wechat。
注册后新增 codex 分组的 apikey 即可。