从REST API到MCP服务器，只需10分钟

如果你有一个REST API，你就已经有了MCP服务器的90%。这是没人告诉你的事。

你的端点就是你的工具。你的请求模式就是你的输入模式。你的响应格式就是你的输出类型。映射关系直接得几乎令人尴尬。

POST /users/create？那就是一个create_user工具。GET /orders/:id？那就是get_order。参数类型、验证规则、错误格式——你都已经写过了。如果算上OpenAPI规范，可能写了两遍。

唯一缺少的是翻译层。还有——这是会绊倒你的地方——好的描述。不是"description: 创建用户"。是LLM能够实际推理的描述。这个区别比你想象的更重要。

MCP工具几乎与REST端点一一对应。这不是巧合。两者从根本上回答的是同一个问题：这个服务能做什么，我怎么让它做事？

模式翻译是机械性的。JSON Schema进去，JSON Schema出来。必填字段还是必填。枚举还是枚举。嵌套对象还是嵌套。眯起眼睛看，MCP工具定义就像是人体工程学更好的OpenAPI操作。

你可以自动化这个转换。我们已经自动化了。结构映射是个已解决的问题。你不需要操心。

你需要操心的是结构无法捕捉的一切。隐含的契约。顺序依赖。那些"在调用那个端点之前别调用这个端点"的知识，只存在于你团队的脑子里，别的地方找不到。这才是真正的翻译工作。

大多数迁移在这里失败。而且原因出乎意料。

你复制端点名称，从OpenAPI规范生成模式，然后部署。一切看起来很棒。工具定义很干净。类型正确。你感觉很有成效。

然后LLM在该调用update_user时调用了create_user。为什么？因为两个描述都写着"管理用户数据"。你是为那些会读URL路径并理解区别的开发者写的。LLM不读URL路径。它读描述。

你的描述需要明确、具体，为一个从未见过你的系统、以后也不会见到的读者而写。"使用提供的电子邮件和密码创建新用户账户。返回带有生成ID的已创建用户对象。如果电子邮件已注册则失败。"这是LLM能使用的描述。

这是迁移中真正困难的工作。不是管道工程——是命名。

捷径来了。把SmeltSec指向你的OpenAPI规范或GitHub仓库。就这样。这就是起点。

它读取你的端点，从路由结构和现有文档推断意图，生成带有正确模式的MCP工具，编写LLM能实际解析的描述。然后运行安全扫描，检测工具投毒向量和过于宽松的输入模式。

标题里的10分钟说得很宽裕了。大多数仓库用不了60秒。瓶颈不是生成——是你审查输出，判断描述是否准确捕捉了每个工具的功能。

你可以手动完成这一切。你会花掉一个周末。模式会做对，描述会做错，因为写好描述是大多数后端工程师从未需要培养的技能。这是那种无聊但关键的工作，应该交给工具来处理。

转换到MCP最令人惊讶的不是转换本身。是之后发生的事。

你的API突然有了意想不到的新消费者。AI代理开始以你从未测试过的方式调用你的工具。它们将你的工具与完全不相关的服务的工具组合——一个日历工具调用你的支付工具，再调用通知工具，全部由一个自己搞清楚工作流程的LLM编排。

你不再是在构建API。你在为生态系统做贡献。你的工具变成了你没有设计、也无法预测的系统中的构建模块。

如果你习惯了控制整个集成面，这会让人不舒服。但如果你意识到这意味着什么，就会很兴奋：你的服务刚刚以你无法想象的方式变得有用，被你永远不会遇到的用户使用，解决你不知道存在的问题。

这才是切换的真正原因。不是因为MCP更新或更时髦。而是因为它让你的工作在一个更大的世界里产生意义。