MCP 到了该认真做减法的时候：它不是万能接口，而是 AI 工具层的基础协议

过去一段时间，MCP 几乎成了 AI 工具圈的公共语言。很多产品、框架、插件都在往 MCP 靠，官方规范也在继续推进，注册表、SDK 分层、MCP Apps 这类配套能力陆续补齐。热度是真的，但问题也来了：一热，大家就容易把它讲成“接上 MCP，AI 就万物互联”。这显然过头了。

我的判断是，MCP 值得关注，而且是重度关注。但关注方式不是追着每个 server 试一遍，而是把它当作 AI 应用里的“工具接入层”来理解。它解决的是连接问题、上下文问题和可组合问题，不直接解决产品价值问题，更不自动解决可靠性问题。

MCP 真正解决了什么

在没有 MCP 的时候，做一个稍微复杂点的 AI 应用，最大的麻烦之一就是工具接入方式碎片化。文件系统一套、数据库一套、浏览器自动化一套、内部 API 又是一套。每接一个能力，都像写一次定制适配层。短期能跑，长期非常难维护。

MCP 的价值就在这里：它把“模型如何发现工具、拿到资源、调用能力、接收结构化结果”这件事抽象成了统一协议。资源、提示模板、工具，这三层拆分看起来朴素，但它让客户端、服务端和第三方扩展终于有了一个共同接口。对开发者来说，这意味着复用性上来了，迁移成本下降了，组合不同能力时的工程摩擦也低了很多。

因为 MCP 越流行，越容易被滥用。很多人把“能接入很多工具”误解成“应该接入很多工具”，然后做出一个工具菜单非常豪华、实际却不稳定的 AI 产品。工程上这不是进步，而是把系统复杂度悄悄抬高。

协议统一，不等于产品自动变简单。每多一个 server，你就多一份权限管理、多一份超时处理、多一份错误恢复、多一份上下文污染的风险。更别说现在还有 MCP Apps 这样的 UI 扩展能力，一旦引入交互式组件，产品边界、审核逻辑和维护成本都会继续上升。

所以真正成熟的做法不是“先把生态全接上”，而是只保留那些高频、可验证、可维护的能力。对个人开发者而言，这一点尤其关键。你不是平台公司，没有资源去维护一个泛化工具市场。你更适合围绕一个明确场景，挑 3 到 5 个真正必要的能力，把可靠性做扎实。

我觉得机会不在“再造一个通用 MCP 平台”，而在两个方向。一个方向是做垂直场景 server，把某个领域里原本零散、难用、需要人工拼接的操作封装好。另一个方向是做 workflow 产品，不是卖协议本身，而是卖“基于 MCP 的结果交付”。

举个更实际的说法：如果你熟悉某个行业工具链，比如客服系统、广告投放、数据看板、内容运营、独立站后台，你完全可以围绕那个细分场景做一个高质量 server 或一个轻量应用层。用户买的不是 MCP 三个字，而是“少点一次后台、少复制几段数据、少走几个页面”的效率提升。

我的建议是：开发者应该投入理解，个人开发者可以小规模投入实践，但别重资产押注。理解层面，你至少要搞清楚 MCP 的资源、工具、提示模板分别适合承载什么，知道它和传统插件体系、API 网关、自动化脚本的边界差异。实践层面，可以先做一个非常小的真实场景，用它服务你自己，而不是一上来就想做生态平台。

现在还不值得做的，是那种“什么都能接”的大而全产品。一方面同质化严重，另一方面维护成本会迅速吞掉个人开发者的时间。MCP 的长期价值很高，但早期红利不一定属于连接最多的人，往往属于把一个具体问题解决得最顺手的人。

所以我的结论是：MCP 不是该不该看，而是该怎么看。它确实正在成为 AI 工具层的重要基础设施，但对大多数开发者和独立开发者来说，真正值得投入的是利用它做减法、做聚焦、做可维护的产品，而不是被生态热度带着一路加功能。