如何将已有的应用转换成 MCP 服务？

• 标签：大模型、AI、MCP、开发实践

🏛 业务架构师

把存量应用改造成 MCP 服务，我按"成本从低到高"给三条路径，业务上按 ROI 排序：

路径一：注解化封装（首选，改造成本最低）。Java 应用加 Spring AI MCP Server 依赖，在现有 Service 方法上标注 @Tool，写清名称、描述、参数 Schema；Python 用 FastMCP 几行代码同理。半天到一天即可把一个"查订单"接口变成 AI 可调用的工具。关键动作是描述要面向模型重写——给模型看的说明和给人看的接口文档不是一回事。

路径二：网关层适配（不动存量代码）。在 API 网关或 BFF 层加一个 MCP 适配层，把已有 REST API 批量映射为 MCP 工具，参数转换、鉴权透传在适配层统一处理。适合代码不能动的老系统、第三方 SaaS。

路径三：新建 MCP 门面（治理最优）。为老旧核心系统（无 API 的 ERP）单独建 MCP 服务，内部走数据库或屏幕抓取，对外统一暴露标准化工具。

改造原则：不是所有接口都值得 MCP 化——按"AI 场景调用频度×业务价值"筛选 Top 20% 的能力先行，配套补齐鉴权和审计。盲目全量改造是浪费，MCP 化本身不产生价值，被 Agent 用起来才产生。

🏗 系统架构师

把已有应用转换成 MCP Server，我的方法论是**"能力盘点 → 接口封装 → 治理上线"三步**：

第一步：能力盘点与筛选。不是所有 API 都值得暴露——按"AI 使用价值 × 风险等级"筛选：读多写少、幂等、语义清晰的接口优先（查询类）；高危写操作（支付、删除）要么不暴露，要么加确认机制。

第二步：封装实现。两条路线：

• 轻改造：官方/社区 SDK（FastMCP、Spring AI 的 @Tool、TypeScript SDK）在应用侧或独立网关进程包装现有 REST API——工具的 name/description/inputSchema 是给模型看的"产品文档"，描述质量直接决定调用准确率，要按"模型可理解"的标准重写而不是照抄 API 文档；
• 网关聚合：对存量大量 API，做 MCP 网关统一注册、协议转换、鉴权透传，避免每个服务单独实现。

第三步：治理上线。OAuth2 接入企业身份体系、限流与配额、全量审计日志、工具版本管理（schema 变更要兼容，破坏性变更上新版本号）。

架构师提醒：description 注入风险要审（别把不可信内容拼进工具描述）；返回结果控制大小（超大 JSON 先裁剪/摘要）；工具数量控制在几十个内——太多会稀释模型选择准确率，按场景拆分多个 Server 而不是一个巨石 Server。

💻 全栈开发专家

把已有应用转 MCP 服务，按成本从低到高三条路：

路径一：API 网关直接代理（最快）。用现成 MCP Gateway（Kong 3.x、LiteLLM、Higress 都内置 OpenAPI→MCP 转换），把现有 REST 的 OpenAPI 文档喂进去，自动生成 MCP Server：

# Higress/Kong 配置：openapi spec → mcp tools
openapi: https://myapp.internal/v3/api-docs
prefix: orders

原 API 的鉴权由网关统一映射成 OAuth，半天上线。适合内部大量存量 API。

路径二：SDK 封装（推荐，控制粒度）。用官方 Java SDK（Spring AI）只把适合给模型用的接口暴露出来：

@Tool(description = "查询订单物流状态")
public LogisticsDTO track(@ToolParam(description = "订单号") String orderId) {
    return restClient.get()...;  // 内部调已有 REST/Service
}

路径三：MCP 市场现成 Server + 配置对接（数据库、文件、GitHub 这类通用场景）。

转换时的关键设计（吃过亏的）：一，别把 CRUD 裸暴露——工具粒度要面向任务（「取消订单」而不是「update orders 表」）；二，每个工具写清楚 description 和参数语义，这是模型能不能用对的关键；三，写操作必须过确认门；四，返回值压缩成模型友好的摘要，别把分页大 JSON 直接扔回上下文。