MCP 这东西一年前还是个新鲜词，现在已经变成一堆要挑的东西了。问题也从「有没有」变成了「装哪些」。

最近有一份清单，把 30 个常用的 MCP server 按用途分成了 10 类。我照着过了一遍，说说我的判断：哪些值得装，哪些先放着，哪些别碰。

这 10 类覆盖了什么

先给全貌：

  • 搜索与互联网：Brave Search、Google Maps、World Monitor
  • 编程：Sentry、Context7、GitHub
  • 浏览器与自动化：Fetch、Chrome DevTools、Playwright
  • 文件与文档：Filesystem、Google Drive、Obsidian
  • 数据库：PostgreSQL、SQLite、MCP Toolbox for Databases
  • 记忆与检索：Knowledge Graph Memory、Graphiti、cognee
  • Agent 协作：Taskmaster、BlenderMCP、Talk to Figma
  • 办公效率：Google Workspace、Todoist、Thunderbird
  • 研究与分析：Phoenix、Zotero、NotebookLM
  • 商务与金融：Finance Toolkit、Financial Datasets、Stripe

把这十类串起来，正好是一个完整的闭环：找信息 → 写和查代码 → 操作浏览器 → 读文件 → 查数据 → 记住上下文 → 分派任务 → 跑运维 → 分析证据 → 处理支付。

看到这个结构，装什么其实就有答案了：闭环上你哪一段最常断，就先补那一段。

先记一句话：这份清单里有坑

清单里给了个提醒，我觉得比清单本身更值钱：

其中有一部分 server 放在已经归档的仓库里。 归档不等于不能用，但意味着没人维护了——安全补丁、依赖升级、协议变更都指望不上。

所以真要接到生产环境之前，两个动作必须做：看仓库最近一次提交是什么时候，看它要什么权限。

第二点尤其要紧。MCP server 是直接挂在模型手上的，权限给多了，等于把钥匙串递出去。一个「读文件」的需求，不该配一个能删文件的工具。

我挑工具只看三条

我不看 star 数，看这三条：

  1. **每天会不会真的用到。** 一周用不满两次的，装了也是白占上下文，还增加模型选错工具的概率。
  2. **权限面能不能收紧。** 只读永远优于可写；能限定目录就别给整个盘；能用只读账号就别用管理员账号。
  3. **还在不在维护。** 见上一节。

按这三条过一遍，30 个里能留下的其实不多。

我会先装哪几个

如果只允许装六个，我的顺序是这样：

第一梯队（几乎人人用得上）

  • **Context7**：让模型去查库的最新文档，而不是凭记忆写 API。这一条能省掉大量「代码看着对，跑起来报错」的时间，性价比最高。
  • **Filesystem**：最基础也最实用，给只读 + 限定目录。
  • **Playwright 或 Chrome DevTools（二选一）**：很多任务最后都卡在「网页上点一下」。这两个都能干，按你更熟的那套选。

第二梯队（看你干哪一行）

  • **GitHub**：读代码、读 issue，做开发的必备。
  • **PostgreSQL 或 SQLite**：看你数据放在哪儿，只开只读账号。
  • **Knowledge Graph Memory 或 Graphiti**：跨会话记住上下文。想做「越用越顺手」的助手，这一类不能省。

剩下那些，等真的遇到那个场景再装。Stripe 这种直接碰钱的，我建议最后再考虑，而且要单独隔离，别和别的工具共用一套凭据。

落地顺序

别一次装十个，这是我踩过的坑：工具一多，模型在「下一步该用哪个」上就开始犹豫，反而更慢、更容易出错。

我的做法是：

  1. 先装一个，跑通一条真实的日常流程（比如「读我的项目代码 → 查最新文档 → 提出修改」）；
  2. 稳定一周，再考虑加第二个；
  3. 每加一个，都问一遍：它带来的便利，值不值得多一份权限暴露。

一句话结论

MCP 的价值不在于你装了多少，而在于你有没有把某一条流程真正跑顺。清单是好东西，但清单上的东西不是你的能力——跑顺的那一条才是。