MCP并非简单的“API加文档”：从理论到落地的关键跨越
常有人将MCP（Model Context Protocol）简单定义为“API加文档”，认为这只是为旧有接口换了个新名字。诚然，传统的软件API早已包含参数、返回值及调用示例，部分演示场景如查询天气或订单也确实缺乏神秘感。然而，这种观点忽略了从“理解接口”到“实际执行”之间的关键鸿沟。
仅凭接口文档，AI模型或许能生成正确的调用代码，但这并不意味着Agent已具备执行能力。以物流接口为例，虽然文档明确了地址、参数及签名方式，但Agent是否拥有网络执行工具、凭证存储位置、签名生成机制以及异常处理流程，均需具体落实。模型在对话中生成的代码片段，无法直接驱动业务系统更新订单状态。
因此，若“API加DOC”仅指静态的接口与说明，显然不等同于完成接入；但若其涵盖可执行的连接适配、授权机制及完整的业务用例，则确实能实现与MCP相同的业务能力。这一实质性的工作成果不应被协议推广的话术所掩盖。
图1 开发工作场景：文档说明调用方法，连接代码负责实际执行
MCP的核心价值：标准化连接与能力发现
MCP的真正价值在于约定了AI应用连接外部服务的标准。支持该协议的客户端可按规范识别服务端提供的能力并进行交互。服务端除了提供工具，还可提供资源和提示模板，但无需为了凑齐功能类别而强行增加冗余服务。
原有的API通常继续保留，MCP服务端可在其后端进行调用。以物流服务商为例，其在原有查询接口之上，新增了一层适配AI客户端的服务。这并未凭空增加物流业务能力，而是改变了能力被Agent发现和使用的方式。
这也解释了为何业界对MCP的评价两极分化：对于拥有稳定内部连接器（涵盖库存、订单、财务等）的团队，切换至MCP未必带来即时收益；但对于需频繁重新解释接口、编写适配代码的场景，采用统一协议具有显著的实际意义。
警惕概念误区：连接器可靠性重于协议形式
以亚马逊SP-API为例，若Agent已通过可靠的连接器查询数据并执行授权操作，便无需为了迎合概念而额外绕路。评估重点应在于连接器的可靠性、权限设置的合理性以及业务动作的支持程度，而非仅仅关注是否使用了MCP。
反之，若仅向缺乏执行连接的Agent提供SP-API文档，指望其凭借“聪明”自然学会使用，并不现实。企业可以借助AI辅助开发连接器，但不能将尚未完成的能力视为可用。企业交付需要的是真实结果，而非看似正确的调用方案。
图2 两种接入路径均可实现相同业务目标
业务知识缺失：协议无法替代领域逻辑
接口文档能指导字段传输，却难以阐释背后的业务逻辑。例如商品命名规则、审核条件及自动处理的情形，往往不在通用文档中。服务商需整理这些必要说明，以减少Agent执行时的猜测。
此类工作不会因采用MCP而自动完成。若工具描述含糊、返回值缺失关键信息或文档与实际行为不一致，更换协议依然难用。企业不应只问“是否支持MCP”，而应通过具体任务测试Agent能否正确完成，并核对实际业务记录。
结语：以结果为导向的服务交付
服务商不应以“API加文档”为由推卸责任。客户关心的是其Agent当下是否可用。无论是选择MCP还是提供适配现有Agent的可靠连接器，都不能将开发者文档作为最终交付物，让客户自行补齐剩余工作。
过去客户学习后台是因为别无选择，如今客户倾向于让Agent处理工作，服务商必须提供相应入口。市场变化不会等待协议争论结束，未做好准备的服务商可能面临客户流失。
核心问题应更为具体：API能否被企业Agent真正调用？说明是否足以指导正确使用？失败时能否定位原因？执行后能否核对结果？唯有落实这些环节，讨论技术选型才有意义。仅有API和文档，远非事情的终点。
资料参考
MCP 官方文档：协议范围与客户端服务端架构
[2] 亚马逊官方文档：SP-API 接入与授权