MCP 火了以后很多团队会自然冒出一个想法既然 AI 应用以后都要调工具那我们是不是应该把现有 API 全部改成 MCP这个想法听起来很顺。公司里有订单 API、用户 API、工单 API、知识库 API、监控 API、财务 API。把它们都包装成 MCP ServerAI 不就什么都能用了但真这么做大概率会把系统搞复杂。MCP 很有价值但它不是业务 API 的替代品。它更像 AI 应用和工具之间的一层适配协议。原来的业务 API 仍然应该存在仍然应该承担确定性业务流量。一句话说MCP 适合把“AI 需要使用的工具能力”暴露出来不适合把所有业务接口原封不动搬过去。不是所有 API 都值得 MCP 化。API 和 MCP 面向的使用者不同传统 API 面向的是程序。程序调用 API输入输出明确流程固定错误处理明确。比如GET /api/orders/12345 POST /api/refunds POST /api/users/{id}/disable调用方通常是另一个后端服务、前端页面、移动端、批处理任务。它们知道自己要调什么接口参数从哪里来失败怎么处理。MCP 面向的是 AI 应用。AI 应用不是固定写死每一步而是让模型在一定范围内选择工具。它需要理解工具描述、参数含义、返回结果并把工具结果放进上下文继续推理。这就带来一个差别API 设计给确定性程序MCP 工具设计给模型使用。一个内部 API 可能叫POST /v2/ord/sts/sync程序员知道什么意思模型不一定知道。一个 MCP 工具如果叫sync_order_status描述写清楚“同步并返回指定订单的最新物流状态”模型才更容易正确使用。所以 MCP 化不是简单暴露接口而是重新设计“模型可理解的工具能力”。不是所有 API 都适合被模型选择很多业务 API 是流程内部的一环不应该被模型单独调用。比如支付系统里可能有这些接口创建支付单锁定库存计算优惠发起扣款写入财务流水更新订单状态发送通知。这些接口组合起来才是完整流程。中间任何一步单独调用都可能造成状态不一致。如果你把每个接口都暴露成 MCP 工具让模型自己选择调用顺序就很危险。模型不应该决定支付流程的事务边界。正确做法是保留后端确定性流程只把少数高层能力暴露给 AI。比如查询订单状态生成退款建议创建待审批退款申请查询支付异常原因。而不是把底层支付 API 全部暴露出去。AI 应用适合做辅助判断、信息查询、草稿生成、流程发起不适合绕过业务系统自己拼核心交易流程。MCP 工具应该是“任务语义”不是“接口搬家”把所有 API 原样搬成 MCP通常会出现几个问题。第一个问题是工具太多。模型面对 200 个工具时选择会变差。很多工具名字类似参数类似描述也类似。人都看晕模型更容易选错。第二个问题是粒度太细。业务 API 往往是系统内部粒度适合程序组合。模型更适合使用任务粒度工具。比如“查询用户近 30 天售后记录”比“查用户、查订单、查工单、查退款、再组合”更适合模型。第三个问题是权限太散。底层 API 权限复杂。如果都暴露给模型每个工具都要重新审权限、审参数、审风险。工作量大漏一个就出事。第四个问题是返回结果不适合模型。很多 API 返回的是机器友好的大 JSON字段很多命名历史包袱重。模型拿到以后可能误解字段含义。MCP 工具返回最好是面向任务整理过的结果而不是把内部 DTO 原样甩出来。所以 MCP 工具应该围绕 AI 使用场景设计而不是围绕已有接口一键生成。还要算迁移成本不只是接入成本很多团队低估了“全量 MCP 化”的维护成本。把接口包一层 MCP Server 很容易难的是后面长期维护。业务 API 会变。字段会改名权限会调整错误码会新增流程会拆分。原来只有程序调用方需要适配现在 MCP 工具描述、参数 schema、返回摘要、权限策略、模型使用说明都要跟着更新。更麻烦的是模型对工具描述很敏感。一个字段描述写得含糊可能导致工具被误用一个工具名字和另一个工具太像可能导致选择错误。传统 API 文档写得差一点程序员还能看代码兜底MCP 工具写得差模型会直接在运行时踩坑。所以不要只问“能不能包装”。还要问谁维护工具语义谁负责权限审计谁验证模型会正确选择谁处理旧工具下线如果这些问题没有答案全量迁移会变成长期负担。什么时候适合做成 MCP第一类AI 经常需要主动发现和调用的工具。比如文件读取、代码搜索、知识库检索、数据库查询、浏览器操作。这些能力本来就是给 AI 助手在任务中动态使用的。第二类多个 AI 客户端会复用的能力。比如公司有 AI IDE、客服助手、运营助手、数据助手都需要接知识库。做一个知识库 MCP Server比每个应用各接一套更清晰。第三类工具能力需要被标准描述。比如工具列表会变化资源列表会变化客户端需要动态发现。MCP 的协议价值就在这里。第四类面向 AI 的高层业务动作。比如“创建待审批工单”“生成退款方案”“查询客户风险摘要”。这些不是底层 API而是模型容易理解、业务上也相对安全的工具。什么时候不适合第一核心交易链路不适合让模型自由编排。支付、账务、库存、权限变更、生产配置这些都应该走确定性流程。AI 可以辅助但不要让模型直接拼流程。第二高频低延迟接口不适合给 MCP。如果一个接口每秒几千次调用延迟和吞吐很敏感它就应该继续走原来的服务调用。MCP 不是性能优化工具。第三前端页面固定流程不需要 MCP。比如用户点击按钮提交表单后端校验保存。这里没有模型动态选择工具的需求。别为了统一而套 MCP。第四只服务一个应用的简单接口不一定需要 MCP。如果你只有一个 AI 应用里面就三个固定函数Function Calling 够了。MCP 带来的标准化收益不明显。第五业务含义还没稳定的接口不要急着 MCP 化。内部 API 还在频繁试错时先别急着把它暴露给模型。工具一旦被模型和用户依赖后面改名、改参数、改语义都会更麻烦。先让业务流程稳定再抽象成模型可用的工具。一个比较合理的改造方式不要从“有哪些 API”开始而要从“AI 需要完成哪些任务”开始。比如客服场景不要把订单系统所有接口都 MCP 化。先列 AI 真正需要的能力查询订单摘要查询物流轨迹判断是否满足补偿规则创建售后工单生成客服回复草稿。然后再看这些能力背后需要调用哪些内部 API。内部 API 仍然留在后端MCP Server 只暴露面向 AI 的工具。这样工具数量少语义清晰权限也好控制。再比如研发场景AI 编程助手真正需要的是读取文件搜索代码查看 Git diff运行测试应用补丁。它不需要直接访问公司所有 DevOps API。发布、合并、删除分支这类危险动作可以单独加审批或根本不暴露。更稳的做法是分层底层保留原 API中间有业务服务封装规则最上层 MCP 只暴露少数模型友好的工具。MCP 层不要承载业务规则本身它应该调用已有业务服务而不是复制一套规则。MCP 层要做裁剪和保护如果你决定做 MCP Server别把它当透明代理。透明代理的意思是内部 API 有什么MCP 就暴露什么API 返回什么MCP 就返回什么。这很省事也很危险。MCP 层至少应该做几件事第一裁剪工具。只暴露 AI 场景需要的能力。工具数量越少越好。第二重命名和重写描述。工具名和参数要让模型看得懂。内部缩写、历史命名、奇怪字段不要直接暴露。第三做权限校验。不要相信模型“不会乱调”。每次调用都要按当前用户和当前场景校验权限。第四做参数校验。金额、ID、时间范围、状态枚举都要严格校验。不要让模型传什么就执行什么。第五做结果整理。返回给模型的结果要够用但不要泄漏无关敏感字段。大 JSON 可以压成摘要必要字段保留来源。第六危险操作默认 dry-run 或审批。MCP 工具不是免审通道。越靠近写操作越要谨慎。最后总结一下MCP 是 AI 工具生态里很重要的一层但它不是“新一代 API 网关”更不是“把所有接口换个协议”。传统 API 继续服务确定性业务流程。MCP 负责把 AI 需要的工具和资源以模型更容易理解、客户端更容易复用的方式暴露出来。所以不要问“要不要把所有 API 改成 MCP”。应该问这个能力是不是 AI 需要动态调用是不是多个 AI 客户端会复用是不是适合让模型选择权限和风险能不能控制返回结果是不是适合进入上下文维护成本有没有人承担如果答案是否定的就别改。保留普通 API省事也更稳。