程序员的MCP实战清单：三个月筛选后只剩这些

龟小豹

【程序员的MCP实战清单：三个月筛选后只剩这些】


快速阅读：一位开发者用了三个月，把15个MCP服务器精简到6个。核心结论是：每多一个MCP，就是让代理在更多工具里选择，反而会拖慢它。真正活下来的，都是每天都在用的。

---

装了15个MCP服务器，三个月后还在配置文件里的只剩6个。这个淘汰率说明了一些事情。

活下来的是：filesystem + git（内置的，没什么好说的）、GitHub MCP、AgentMail、Postgres直连、Playwright、还有一个记忆/知识图谱。被卸载的是Slack MCP、Notion MCP和日历MCP，原因都一样：以为会用，但没用。

帖子引起了广泛讨论。评论区最高赞的观点直接指出：GitHub MCP是浪费token，Claude Code内置支持`gh` CLI，根本不需要单独挂一个MCP。同样的逻辑也适用于Playwright，有CLI能用的地方，就别上MCP。

有观点认为，MCP最大的隐性成本是context污染。每个MCP服务器的工具列表都会写进system prompt，装了15个服务器，还没开始干活就烧掉了一大块上下文窗口。一个更极端的解法是，把所有工具包在一个本地web server后面，让代理用curl调用，没有MCP开销，工具数量也不受限制。

AgentMail是这个帖子里意外的亮点。让代理拥有自己的邮件收件箱，用来订阅竞品通讯并每周总结、接收部署失败告警并在你醒来前完成分类，这个“代理在你睡觉时处理完事情”的模式，让很多人打算照搬。

context7也被反复提到，专门解决Claude用训练数据里的旧文档回答问题、导致API调用写错的问题。

有网友提出了记忆分层的思路：session记忆用一个MCP，项目架构文档、编码规范这类静态知识用另一套，两者分开管理，因为你不希望架构决策像聊天记录一样被压缩和遗忘。

原帖作者在评论里承认，他准备换掉GitHub MCP改用CLI，原因只有一个：省token。每天被限流的人，开始认真计算每个工具的实际成本了。

工具越少，代理越专注。这大概是这条线程里最反直觉，也最实用的结论。

ref: www.reddit.com/r/ClaudeAI/commen ... e_day_whats_in_your

##