API to MCP

想象一下你是个独立开发者，正在做一个 AI 客服 agent。你想让它能查订单状态、改地址、退换货。这些功能你的电商平台都有 API，但你的 agent 没法直接用——它只懂 MCP 协议，不懂 REST、GraphQL、OAuth。你不得不花两天写一个中间层：处理认证、解析 JSON、封装成 MCP 格式。写完发现平台 API 升级了，参数变了，你又得改。更烦的是，你手头有三个不同的 SaaS 要接，每个都要重复这套流程。你开始怀疑，到底是在做 AI 还是在做 API 适配工。

API to MCP 就是来解决这个问题的。你是一个开发者，你手头有一个 API——可能是 Stripe 的支付接口、Notion 的数据库、或者你们公司内部的 CRM。你把这个 API 的 OpenAPI 规范或者一个简单的端点描述扔给 API to MCP，它自动生成一个 MCP 服务器。这个服务器跑起来之后，你的 AI agent 就能像调用本地函数一样调用它：agent 说“查订单 12345”，MCP 服务器就去调那个 API，把结果翻译回 agent 能理解的格式。整个过程你不需要写一行胶水代码。上下游也很清楚：上游是你已有的 API，下游是任何支持 MCP 的 AI agent——比如 Claude、GPT 或者你自己写的 agent 框架。你只需要把生成的 MCP 服务器地址告诉 agent，它就能用了。

你可以把这个过程想象成给一个只会说普通话的人配一个同声传译耳机。API 说的是方言——REST、GraphQL、SOAP，各有各的语法和认证方式。MCP 是普通话，AI agent 只听得懂这个。API to MCP 就是那个耳机，它实时把方言翻译成普通话，而且不需要你手动调频。你只要把耳机戴在 API 上，agent 就能跟它聊天了。

市面上已经有类似的东西，比如 Zapier 的 AI 动作或者 Make 的模块。它们走的是“低代码工作流”路线：你拖拽一个触发器，配置一个动作，然后让 AI 在特定场景下触发。这条路的好处是可视化，非技术人员也能用。但代价是慢——每次调用都要经过 Zapier 的中间层，延迟几百毫秒起步；而且你只能使用 Zapier 已经集成好的 API，自定义的、内部的、小众的 API 接不进去。API to MCP 走的是另一条路：它不提供 UI，不帮你编排流程，它只做一件事——把 API 的“方言”翻译成 MCP 的“普通话”。这意味着它更快（没有额外中间层）、更灵活（任何 API 都能接）、更底层（你可以自己控制认证和缓存）。如果你需要让 agent 高频调用一个内部 API，比如每秒查一次库存，Zapier 那种方案根本扛不住，API to MCP 生成的服务器可以跑在你的服务器上，延迟只有网络往返的时间。

当然，它也有边界。API to MCP 假设你的 API 是稳定的、定义清晰的。如果你的 API 三天两头改字段、换端点，你每次都要重新生成 MCP 服务器，虽然比手动改代码快，但依然有维护成本。它也不适合那些需要复杂状态管理的场景——比如一个 API 调用依赖前一个调用的结果，你需要在 agent 端自己处理逻辑，API to MCP 只负责单次翻译。另外，安全方面你要自己负责：生成的 MCP 服务器会暴露你的 API 给 agent，如果你把 API key 写死在配置里，那 agent 就能无限调用。你需要自己控制 agent 的权限范围。

我有个朋友，他在一家 SaaS 公司做客服系统。他们想用 AI 自动处理退款，但退款 API 是内部自建的，没有现成的 MCP 封装。他花了 15 分钟把那个 API 的 OpenAPI 文件拖进 API to MCP，生成了一个 MCP 服务器，然后让 Claude 连上它。现在客服 agent 可以这样说：“查一下订单 8823，如果金额小于 50 美元且没有争议，直接退款。” 整个过程从“写两天代码”变成了“喝杯咖啡的功夫”。他后来跟我说，最爽的不是省了时间，而是他终于可以把精力放在 agent 的逻辑上，而不是 API 的适配上了。