我每天都在用的 10 个 MCP 服务器:AI 编程效率直接翻倍
之前写过 MCP 协议的基础概念和怎么自己搭一个 MCP 服务器,但一直没整理过我实际在用的 MCP 服务器清单。最近有好几个朋友问我"你平时 Claude Code / Cursor 里都接了哪些 MCP",干脆写一篇汇总一下。
说实话,MCP 服务器这东西,数量已经多到离谱了。光 GitHub 上的 awesome-mcp-servers 列表就有几百个,但真正好用、稳定的其实不多。我折腾了大概三四十个,最后留下来每天在用的就这十个。有些服务器装上五分钟就卸了,有些用了两周才发现问题。今天把我的筛选过程和使用心得都写出来,省得你们再踩一遍我踩过的坑。
先说说怎么选 MCP 服务器
选 MCP 服务器跟选 npm 包差不多,踩坑率挺高的。有些服务器文档写得天花乱坠,实际用起来要么报错要么功能残废。我总结了几条选型经验:
- 优先选官方实现。GitHub 的 MCP 就用 GitHub 自己出的,Notion 的就用 Notion 官方的。社区版质量参差不齐,尤其是涉及 OAuth 认证的,自己搞容易翻车。我之前用过一个社区版的 Slack MCP,OAuth 回调老是失败,折腾了一下午没搞定,最后还是换回了官方版。
- 看最近更新时间。超过三个月没更新的,基本可以 pass。MCP 协议本身还在演进,API 变了旧服务器就废了。今年三月份 MCP 规范有一次大更新,不少老旧服务器直接就不能用了。
- 先装上试试再决定。大部分 MCP 服务器都是
npx -y一行命令就能跑,试错成本很低。不喜欢直接删掉就行。 - 看 GitHub star 和 issue 数量。star 超过 1000 的一般质量有保障,issue 太多且没人回的说明维护不积极。
- 注意 Node.js 版本要求。有些新服务器需要 Node 20+,如果你还在用 Node 18,可能会遇到语法兼容问题。我就被这个坑过一次,报了个
SyntaxError: Unexpected token '?',查了半天才发现是 Node 版本太低。
1. GitHub MCP — 代码管理的瑞士军刀
这个是装机必备,没什么好说的。GitHub 官方出的 MCP 服务器,能让 AI 直接操作你的 GitHub 仓库。
装上之后你可以直接跟 AI 说"帮我看看这个 repo 最近有什么 issue"、"给 main 分支提个 PR"、"review 一下这个 commit 的改动"。不用切浏览器,不用手动复制粘贴代码。
我最常用的场景是让 Claude Code 帮我处理 issue:给它一个 issue 链接,它自己读 issue 内容,切分支,写代码,提 PR,一条龙。之前这种活怎么也得半小时,现在五分钟搞定。有一次一个前端 bug 从 issue 到合并只花了八分钟,同事还以为我在吹牛。
配置很简单:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
有个坑得注意:Token 权限别给太大。我一般只给 repo 和 issues 权限,delete_repo 这种危险权限千万别勾。用 Fine-grained token 比 classic token 更安全,能精确控制到每个仓库的读写权限。
另一个常见问题是 token 过期。Fine-grained token 默认一年有效期,classic token 默认 30 天(现在好像改成不设过期了,但还是建议定期轮换)。我之前就遇到过突然 MCP 不能用了,查了半天发现是 token 过期了。
2. Playwright MCP — 浏览器自动化神器
微软出的 Playwright MCP,让 AI 能真正操控浏览器。不是截图看,是真的能点按钮、填表单、翻页。
这个东西我主要用来做两件事:
一是 E2E 测试。跟 AI 说"打开 localhost:3000,用测试账号登录,走一遍下单流程,看看有没有 bug",它就自己跑起来了。之前写 Playwright 测试脚本得花半天调选择器,现在让 AI 自己去点就行,它用的是 accessibility tree,比 CSS selector 稳定多了。
有一次我改了一个表单的验证逻辑,让 AI 帮我跑一遍完整的注册流程。它不仅跑了正常路径,还自动测试了各种边界情况:空值、超长字符串、特殊字符、非法邮箱格式。要我自己写这些 test case,怎么也得花一小时。
二是爬数据。有些网站没有 API,数据全在前端渲染。之前得写 Playwright 脚本去爬,现在直接跟 AI 说"打开这个页面,把表格里的数据提取出来"。它能处理翻页、懒加载、甚至需要登录的页面。
三是复现 bug。前端 bug 经常是"我这边看到是好的啊",有了 Playwright MCP 我可以让 AI 在一个干净的浏览器环境里复现,截个图发给同事看。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
这服务器不需要额外 API key,直接装就能用。但要注意,它会启动一个真实的 Chromium 进程,吃内存。如果同时开好几个,8G 内存的机器可能会卡。另外第一次用的时候需要下载 Chromium 浏览器,大概 100 多 MB,网络不好的话可能要等一会儿。
3. Supabase MCP — 数据库操作一步到位
Supabase 出了官方 MCP 服务器之后,我就再也不用手动写 SQL 然后去 dashboard 跑了。直接跟 AI 说"帮我查一下 users 表里最近注册的 10 个用户"、"给 orders 表加一个 status 字段"。
它不只是能查数据,还能管表结构、管 RLS 策略、管 Edge Functions。有一次我需要给一个表加一套完整的 RLS 规则,手动写怎么也得半小时,跟 AI 说了一句需求,两分钟搞定,还顺带帮我检查了有没有遗漏的场景。
印象最深的一次是做数据迁移。需求是把旧表的数据搬到新表,字段名和类型都变了。以前这种活我得先写 SQL 脚本,本地跑一遍没问题再上生产。这次直接让 AI 在 Supabase MCP 里操作,它先看了两个表的结构,自动生成了迁移 SQL,还能在 Supabase 提供的 SQL Editor 里预览结果。整个过程不到十分钟。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
这里得提醒一下:生产环境的 access token 别乱给。我一般用一个只有 read 权限的 token 日常查询,需要改表结构的时候再换有 write 权限的。Supabase 支持创建多个 API key,每个设置不同的权限范围,用起来很方便。
4. Brave Search MCP — 让 AI 能上网
大模型有个天然短板:训练数据有截止日期。昨天出的 npm 包、今天的 CVE 漏洞、上周的框架更新,它都不知道。Brave Search MCP 就是解决这个问题的。
装上之后 AI 能实时搜索互联网。我经常用它来查某个库的最新版本、搜索某个报错的解决方案、看看有没有新的技术方案出来。之前遇到一个 Next.js 的 hydration 报错,AI 自己的训练数据里没有相关信息,搜了一下发现是 Next.js 15 的一个已知问题,社区已经有 workaround 了。要是没有搜索能力,这个 bug 得卡我半天。
为什么选 Brave 而不是 Google?两个原因:一是 Brave 的 API 有免费额度,每月 2000 次查询,个人用足够了;二是隐私,Brave 不追踪搜索历史。Google 的 Custom Search API 要绑信用卡,而且免费额度只有每天 100 次。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
去 Brave Search API 官网注册一个账号就能拿到 key,免费的,一分钟搞定。
5. Filesystem MCP — 本地文件操作基础款
这个看起来不起眼,但其实很常用。它让 AI 能直接读写本地文件系统,不只是在当前项目目录里操作,而是能访问你授权的任意目录。
我主要用它来处理一些跨项目的文件操作,比如"把 ~/Downloads 里的 JSON 文件整理一下"、"看看 ~/.config 目录下的配置文件"。Claude Code 本身就有文件操作能力,但范围限于当前工作目录。Filesystem MCP 扩大了这个范围。
有一次我需要把好几个项目的 .env 文件都检查一遍,看看有没有用到某个废弃的环境变量。手动一个一个翻太麻烦了,让 AI 通过 Filesystem MCP 扫描所有项目目录,两分钟搞定。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
注意:授权目录要精确,别直接给 / 或 ~。给太多权限,AI 可能会误操作到不该碰的文件。我一般只给 projects 和 downloads 两个目录。
6. Figma MCP — 设计稿直接变代码
前端同学应该会喜欢这个。Figma 官方出的 Dev Mode MCP,能让 AI 直接读取 Figma 设计稿的结构信息,包括布局规则、间距、颜色变量、字体样式、组件属性等等。
之前从设计稿还原页面,要么自己对着 Figma 量像素,要么用截图让 AI 猜。现在 AI 能直接读到设计稿的结构化数据,还原精度高了很多。
有一次我让 Cursor 读一个 Figma 组件,它生成的 Tailwind 代码几乎不用调,间距和颜色都对。设计师看到效果之后问我怎么做到的,我说"AI 直接读的你的设计稿",她都不信。这种体验确实比截图方式好太多了。
不过有个局限:它只能读你在 Figma 里选中的图层,不能遍历整个文件。所以你得先在 Figma 里选好要实现的组件,再让 AI 去读。如果设计稿很大,选中整个 frame 可能会导致返回数据太多,AI 处理不过来。建议一次只选一个组件或一个页面区块。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
前提是你得有 Figma 的 Dev Mode 权限,免费版用不了。个人版的话需要 Professional plan($15/月)。如果你是学生,Figma 有教育版免费。
7. Composio MCP — 250 个应用一个入口
这个有点不一样。别的 MCP 服务器是一个服务对应一个,Composio 是一个服务器管 250 多个平台。GitHub、Slack、Gmail、Notion、Jira、Salesforce、HubSpot……全在一个地方。
我用它主要是在自动化场景里。比如"查看 Linear 里标记为 urgent 的 ticket,每个都创建一个对应的 GitHub issue,然后在 Slack 的 #engineering 频道通知一下"。这种跨平台操作,用 Composio 一个 MCP 就搞定了,不用装三个。
另一个场景是信息聚合。有次我想了解一个客户的所有相关信息——Gmail 里的邮件往来、Notion 里的项目文档、Linear 里的关联 ticket——Composio 能让 AI 一次性查所有这些数据源。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
缺点是它依赖 Composio 的云服务,认证要走他们的 dashboard。不想用第三方服务的话还是一个一个装单独的 MCP 服务器更踏实。另外免费版有调用次数限制,重度用户可能要付费。
8. E2B MCP — 安全沙箱里跑代码
E2B 提供的是一个云端沙箱环境,让 AI 能真正执行代码,不只是写代码。Python、JavaScript、shell 命令都行,全在一个隔离的虚拟机里跑。
这东西的价值在于"安全地验证"。AI 写了个数据处理脚本,你不确定对不对,让它在 E2B 沙箱里跑一遍看看输出。比直接在本机跑安全多了,万一脚本有问题也不会影响到你的系统。
我经常用它来测试正则表达式、跑数据转换脚本、验证 API 调用逻辑。之前得自己写个临时脚本然后手动跑,现在直接让 AI 搞定。有一次让 AI 写了个处理 CSV 的脚本,在 E2B 里跑了三遍调试好了才拿到本地用,省了不少时间。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
E2B 有免费额度,个人用够了。如果跑的代码量大或者需要长时间运行的沙箱,可能要升级付费计划。沙箱默认超时时间是 5 分钟,跑长任务需要注意。
9. Sentry MCP — 线上 Bug 直接让 AI 看
线上报错了,以前的流程是:去 Sentry 后台看错误详情 → 复制堆栈 → 粘贴给 AI → 让它分析。有了 Sentry MCP,中间两步全省了。
直接跟 AI 说"看看 Sentry 上最近的报错,帮我分析一下原因",它自己去拉错误数据,分析堆栈,给出修复建议。有一次生产环境报了一个莫名其妙的 TypeError,我让 Claude Code 通过 Sentry MCP 直接看了错误上下文,它定位到是一个异步竞态条件,给出的修复方案直接就能用。
还有个好处是能做错误趋势分析。让 AI 看看最近一周哪类错误最多,哪些是新出现的,哪些是老问题。以前这种分析得自己去 Sentry dashboard 里翻,现在 AI 帮你整理好了。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
Sentry 的 auth token 在 Settings → Auth Tokens 里创建,建议只给 event:read 和 project:read 权限。
10. Linear MCP — 项目管理也能 AI 化
如果你团队用 Linear 管项目,这个 MCP 服务器能让 AI 直接操作 ticket。查看、创建、更新、搜索,全在对话里完成。
我最常用的是让 AI 帮我整理今天的待办:"看看 Linear 里我名下有哪些进行中的 ticket,按优先级排一下"。或者写完代码之后让它自动更新 ticket 状态,附上 commit 链接。
还有一种用法是做 sprint 回顾。让 AI 查一下这个 sprint 完成了多少 ticket,哪些延期了,延期的原因是什么(根据 ticket 的评论和状态变更记录)。以前这种回顾得手动整理半天,现在几分钟就出结果了。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
不用 Linear 的话,Jira 和 Notion 也有对应的 MCP 服务器,功能类似。Notion 的 MCP 我用过但感觉 API 响应太慢了,查询经常要等好几秒,体验不太好。
一些通用的配置技巧
搞了一段时间 MCP,总结几个实用技巧:
配置文件放哪:不同工具位置不一样。Claude Code 用 .mcp.json(项目级)或 ~/.claude/mcp.json(全局);Cursor 用 .cursor/mcp.json;VS Code 用 .vscode/mcp.json。结构都一样,就是文件位置不同。建议项目级配置放 .mcp.json 然后加入 .gitignore,避免 API key 泄露到仓库里。
环境变量别硬编码:API key 不要直接写在配置文件里,尤其是项目级配置。用环境变量引用:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
这样配置文件可以安全地提交到仓库,key 从系统环境变量里读。
服务器太多会变慢:每多一个 MCP 服务器,AI 的启动时间就多几秒,context 里也会多一堆工具描述。我建议日常保留 3-5 个最常用的,其他的按需启用。我自己是 GitHub + Playwright + Brave Search 常驻,其他的根据项目需要开关。
调试方法:MCP 服务器出问题了怎么排查?Claude Code 可以用 claude mcp list 看已安装的服务器,claude mcp logs 看日志。大部分问题都是 API key 错误或者网络问题,看日志就能定位。如果是服务器本身启动失败,试试手动跑一下 npx -y <package-name> 看看报什么错。
别忘了更新:MCP 服务器用的是 npm 包,有版本更新。建议每隔几个月跑一下 npx -y @latest 看看有没有新版本。旧版本可能有 bug 或者不兼容新的 MCP 协议。
没选进来但值得提的
有几个我也试过,但最终没留在日常使用里,简单说说原因:
- Notion MCP:功能没问题,但 Notion API 太慢了,每次查询都要等好几秒。体验不好就卸了。如果你能接受这个速度,功能还是很全的。
- Docker MCP:让 AI 管容器听起来很酷,但实际上我操作 Docker 的频率不高,没必要常驻。偶尔需要的时候临时装一下就行。
- Postgres MCP:功能和 Supabase MCP 有重叠,我用 Supabase 更多,就留了 Supabase。如果你不用 Supabase,Postgres MCP 是个好选择。
- Cloudflare MCP:最近刚出,还在试。能管 Workers、KV、R2 这些,如果你用 Cloudflare 生态的话可以试试。
- Zapier MCP:类似 Composio,但更贵。免费版限制比较多,适合已经有 Zapier 付费账号的团队。
安全注意事项
用了这么多 MCP 服务器,安全这块得单独说一下。MCP 服务器本质上是给 AI 开了一扇通往外部世界的门,门开多大、开在哪,得你自己把控。
最小权限原则:每个 API key 只给它需要的最小权限。GitHub token 只给 repo 读写,别给 delete 权限。Supabase 的 key 分 read 和 write 两个,日常用 read 就够了。Figma 的 token 只给当前 team 的访问权限。我知道配权限很烦,但真的很重要——AI 有时候会"自作主张"执行一些你没预料到的操作。
警惕 prompt injection:有些 MCP 服务器会返回网页内容(比如 Firecrawl、Playwright),这些内容里可能包含恶意指令。如果 AI 读到了一段精心构造的文本,可能会被诱导执行危险操作。所以返回网页内容的服务器,尽量不要同时给它写权限。先读,确认安全了再写。
配置文件别提交到 Git:.mcp.json 里有 API key,一定要加到 .gitignore。我见过有人不小心把 Sentry token 提交到公开仓库的,后果很严重。如果实在想用版本控制管理配置,用环境变量引用的方式,config 文件里只写 ${ENV_VAR}。
定期审计:每隔几个月看看你装了哪些 MCP 服务器,不用的就删掉。每个服务器都是一个潜在的攻击面。特别是那些社区版的、好久没更新的,风险更高。
最后
MCP 这个生态还处在早期,每天都有新的服务器冒出来。但工具不在多,在于真的能提升效率。我这十个是从三四十个里筛出来的,每个都有明确的使用场景。
如果你刚开始玩 MCP,建议先装 GitHub + Brave Search + Playwright 这三个,覆盖了代码管理、信息检索、浏览器自动化三个核心场景。其他的慢慢加,别一口气装太多,不然 AI 的 context window 都被工具描述占满了,反而影响核心的代码能力。
后面打算再试试 Cloudflare MCP 和 Stripe MCP,用好了再写。有啥问题评论区聊。
- 本文写于 2026 年 6 月 14 日,基于实际使用经验整理。MCP 生态变化很快,文中提到的配置和功能可能会有更新,请以各官方文档为准。*