MCP就是API加文档?

说MCP就是API加DOC，我能理解这句话想表达什么。过去软件就有API，文档里也会写参数、返回值和调用示例。现在给AI用，好像只是换了个名字，又把同一套东西卖了一遍。尤其一些演示只展示查天气、查订单，看起来确实没有什么神秘之处。

但我觉得这个问题不能只看最后发出去的那条请求。你把一本接口文档发给AI，它能读懂，也可能写出正确的调用代码，这和你正在使用的Agent已经能执行这个调用，中间还有一段实际工作。明白操作方法，不代表手上已经有能操作的连接。

比如一个物流接口，文档把地址、参数、签名方式都写全了。模型可以告诉你怎样查运单，但当前Agent有没有网络执行工具，凭证放在哪里，签名由谁生成，请求失败怎么办，都得落实。模型在聊天里写出一段代码，订单状态并不会因此自动进入你的系统。

所以如果API加DOC指的是只有接口和说明，我不认为这就等于完成了接入。如果还包括可执行的连接适配、必要的授权以及完整的业务用例，那它当然可以做到与MCP接入相同的业务能力。这一点没必要为了推广一个协议而否认。

图 1  开发工作场景：文档说明怎样调用，连接代码把调用实际执行出来。 摄影：Dawit / Unsplash

MCP提供的价值，是把AI应用连接外部服务的部分约定下来。支持它的客户端可以按协议了解服务端提供什么能力，再按约定交互。服务端除了工具，也可以提供资源和提示模板，不过不需要为了凑齐类别，给一个简单查询服务硬加一堆功能。

原来的API通常继续存在，MCP服务端可以在背后调用它。物流服务商原来有查询接口，现在多提供一层适合相关AI客户端连接的服务。它没有凭空增加物流业务能力，改变的是这项能力怎样被客户的Agent发现和使用。

这也是为什么有些人觉得它很重要，有些人觉得没必要。如果一个团队早就有稳定的内部连接器，库存、订单、财务都能调用，改成MCP未必马上增加收益。但如果每接一个客户都要重新解释、重新写适配，采用共同协议就有实际意义。

拿SP-API来说，已有连接器的Agent可以通过连接器查询数据、执行被授权的操作，不需要再为了符合一个概念多绕一层。你要判断的是连接器是否可靠、权限是否合适、业务动作有没有被正确支持，不能只看它是否使用MCP。

反过来，给一个完全没有执行连接的Agent贴上SP-API文档，说它足够聪明所以自然会用，也不现实。你可以让它辅助开发连接器，却不能把开发尚未完成的能力当作已经可用。企业交代任务以后，需要真实结果，不能只收到一份看起来正确的调用方案。

图 2  两条接入路径，可以完成同样的业务

还有业务知识的问题。接口说明能告诉它某个字段怎么传，却未必告诉它公司为什么这样填。商品命名规则、审核条件、哪些情况允许自动处理，往往不在通用接口文档里。服务商把这些必要说明整理清楚，才能减少Agent执行时的猜测。

这些工作也不会因为用了MCP就自动完成。工具描述含糊，返回值缺少关键内容，文档和实际行为不一致，换一种协议照样难用。企业不该只问有没有MCP，还应该给出一项具体任务，看Agent能否用它完成，再核对实际业务记录。

站在服务商这边，我不建议用API加DOC这句话替自己省事。客户关心的是他的Agent今天能不能用。你可以选择MCP，也可以提供适配现有Agent的可靠连接器，但不能拿开发者文档当作最终交付，让客户自己补齐剩下的工作。

过去客户愿意学你的后台，是因为很多事情只有在那里才能办。现在客户开始让Agent处理工作，服务商就得提供相应入口。这个变化不会等所有人先把协议争论明白。你没有准备，客户可能直接选择一个已经能接入的服务。

所以我会把问题问得更具体：你的API能不能真的被企业Agent调用，你的说明能不能让它正确使用，遇到失败能不能找到原因，执行之后能不能核对结果。这几件事完成了，用MCP还是已有连接器，都可以讨论。只有API和一份DOC，还不能算事情已经做完。

资料参考

[1] MCP 官方文档：协议范围与客户端服务端架构

[2] 亚马逊官方文档：SP-API 接入与授权

[配图] Dawit / Unsplash（场景照片）