MCP Server是刚需还是噱头？

很多产品经理或技术负责人现在一听到 MCP (Model Context Protocol) 就两眼发光，觉得不接这个协议就落伍了。但在公司内部推行 AI 落地时，我发现最容易踩的坑就是：为了用协议而用协议。

说白了，MCP 只是个“翻译适配器”。它把你的产品功能（比如“创建发票”、“查询订单”）包装成 AI Agent 能读懂的格式。如果你只是想在自己的 App 里加个 AI 聊天窗口，直接调 LLM API 就行了，根本不需要搞 MCP，而且后者成本更高、更复杂。

除非你处于以下三种场景，否则别被这个概念忽悠了：

• 客户是技术大牛/极客： 对方自己跑着 Claude 或内部 Agent 堆栈，直接问你“能不能把你们的产品当成工具接入我的 Agent”，这时候给个 MCP Server 能让成交速度快得惊人。
• 你在做 Agent 编排层： 需要给上层监督 Agent 提供子工具。
• 主打 AI-native 的开发者平台： 这种情况下，支持标准协议是基建，不是加分项。

如果你只是个普通的 SaaS，其实一个标准的 REST API 配合 OpenAPI 文档就足够了，现在的 Agent 框架基本都能直接吃掉，没必要特意加一层 MCP。

至于开发成本，如果底层逻辑已经写好了，写个适配层也就一周左右的事。最耗时的其实是“工具设计”——决定开放哪些接口、颗粒度怎么定。我们之前尝试把“提取信息”和“写邮件”两个步骤合并成一个工具调用，在定义 Schema 上磨蹭的时间比写代码多得多。

简单总结一下我的实操体感：

• 适用场景： 外部 Agent → 你的产品 → 执行动作。
• 误区： 内部 AI 功能 $\neq$ 需要 MCP。
• 核心成本： 不在协议实现，而在 Tool Design 的定义上。