应该从OpenAPI自动生成MCP？

我们应该直接从现有的API规范生成模型上下文协议（MCP）服务器吗？MCP旨在让像Claude、Cursor和Windsurf中的AI代理与工具和API进行交互。那么，我们是否可以简单地将现有的REST API作为LLM的接口，并完全代码生成一个MCP服务器呢？

1、从REST生成MCP

这个想法确实很有吸引力。你已经投入时间构建并记录了你的REST API以及其OpenAPI模式，为什么不将其转换为MCP服务器呢？

思路是这样的：如果创建的是1对1的映射，那么MCP服务器肯定会是全面的？有几个项目已经出来帮助弥合API和LLM之间的差距。例如，openapisearch这样的工具允许代理基于其OpenAPI规范探索和理解现有的API。你可以问，“如何使用GitHub API创建一个存储库？”它会首先找出需要的OpenAPI标识符，以简单的自然语言提供摘要，然后找到并返回适当的端点，让你能够通过对话查询浏览整个API。

还有像Tadata这样的服务，它提供了更直接的方法，自动发现所有FastAPI端点并将其作为MCP工具公开。

2、隐患

克雷默的核心论点触及了几个根本性的不匹配。

首先，当典型的公司REST API可能通过其OpenAPI规范暴露几十或几百个不同的操作时，LLM在面对大量选择时会遇到困难。例如，GitHub API包含超过600个！简单地将这些全部作为单独的工具导入到MCP服务器中，会为LLM创造一个令人不知所措的选择空间。

即使是一组稍微相似的工具，模型在没有非常具体指示的情况下通常无法正确选择。最糟糕的情况是，这会导致非常令人沮丧的用户体验，MCP调用不断失败或不按预期工作。在处理像数据库这样的关键基础设施时，错误的工具调用不再只是不便。

接下来是交互结构本身的问题。LLM在导航复杂的JSON负载或确定API调用中哪些可选参数适合给定任务方面并不特别擅长。这对试图理解结果并决定下一步的LLM来说是不可解释的，因为这些格式和模糊性不是它擅长处理的。

最后，也是最重要的一点，REST API和MCP服务器的目标存在根本上的不匹配。REST API通常围绕资源为中心的低级操作而构建：创建用户、获取记录、更新字段。MCP服务器则在任务和工作流层面运行：“完成新客户的入职”，“迁移数据库模式”，“总结最近的活动”。简单地将每个细粒度的API端点映射到MCP工具，迫使LLM表现得像传统的程序化客户端，这并没有充分利用LLM的优势。

有效的MCP设计意味着思考你希望代理执行的工作流，并可能创建更高层次的工具来封装多个API调用，而不是仅仅暴露整个API规范的原始构建块。

3、混合方法

因此，如果直接的1对1方法存在问题，这是否意味着我们要完全放弃这个想法，只能手动为每个MCP服务器工具编写代码？

也许不是。手动定义每个工具定义、输入/输出模式和处理函数，尤其是在你已经有了一个定义良好的API的情况下，可能是巨大的时间浪费。这就是混合方法的用武之地，其中代码生成不是最终产品，而是起点。

我建议查看用于从OpenAPI规范生成MCP服务器的工具，然后开始积极修剪并删除大多数生成的工具，只保留真正有用且具有独特能力的低级操作，这些操作可能是LLM应该执行的。然后重写剩余工具的描述，使其不仅说明工具“做什么”（就像复制API端点摘要一样），还要说明LLM“何时”和“为什么”应该使用它。提供清晰的例子，概述预期的工作流程，并给出如何处理常见场景或参数的指导。

最后，也是最重要的，创建新的更高层次的工具，抽象常见的多步骤工作流，在后台调用多个底层API端点。（不过要小心不要让你的MCP服务器有状态！）

4、结束语

对于我们的MCP服务器，我们决定使用我们的TypeScript API SDK，以便轻松复制许多API端点。然而，我们只实现了我们认为LLM通过Cursor/Windsurf使用有意义的工具，然后构建了更高的层次工作流，将多个端点组合在一起完成任务。事实上，其中一个更高层次的工作流（以流线化和有意见的方式运行和测试数据库迁移）是我们2024年12月发布的MCP服务器的亮点。

最后，我们的MCP服务器是开源的，我们继续对其进行大量改进。如果你想参与，请查看GitHub上的内容。

原文链接：Auto-generating MCP Servers from OpenAPI Schemas: Yay or Nay?

汇智网翻译整理，转载请标明出处