MCP Server API包装

复杂化还是必要的工程化？

一句话总结

MCP 给开发者提供了一个"LLM-可消费"层。如果你的目标是真正让模型/Agent 自助调用工具，那么为旧 API 加一层 MCP 抽象几乎不可避免；但若只想让人类程序员继续写拉取脚本，把 API 直接暴露就够了——此时再包一层 MCP 大概率是在叠加你不需要的责任。

为什么会被认为"增加无谓复杂性"?

来源 典型抱怨 复杂性根因
Spring AI 实践【Craig Walls】 1 对 1 映射端点 → LLM 反复试错 → Token 爆炸 API 粒度不适合自然语言问题，需要二次聚合/裁剪
Honeycomb 团队经验 默认 JSON 响应巨大，Agent 陷入"doom loop"反复查询 业务 API 和 LLM 消费模式不匹配
FeatureForm 评测 JSON-RPC + 自带 IdP 的 Auth 扩展"过度工程" 需要自己维护 OAuth / Token 映射，门槛高
规范层 MCP 引入 stdio/HTTP/SSE 多传输、资源/工具/提示 三大功能块 对"只是想暴露几个 GET 接口"的团队而言超标
生态声音 "这只是把旧 API 再包一层而已" 乍看像重复造轮子，价值不显而易见

归纳下来，有三类附加成本：

  • 数据重塑成本：为减 token & 推理轮次，必须在 Server 侧做裁剪、聚合、缓存。
  • 协议适配成本：要实现 JSON-RPC 握手、能力协商、流式传输等（尤其是 Stdio 模式）。
  • 安全与治理成本：企业要落地，就得实现 OAuth 2.1 风味的 MCP Auth 子规范。
这些成本若不付出，就会由 LLM 端以更多调用次数 + 更长 prompt + 更高费用的形式偿还。

为什么说它"必不可少"?

统一接口，降低客户端复杂度

MCP 把工具描述、参数验证、能力声明都标准化，让 LLM/Agent 像插 USB-C 一样即插即用，而不用为每个 REST API 单独写 prompt 模板和 schema 翻译器。

生态正快速聚拢

Open-source & SaaS 已涌现 >100 个 MCP Server（Google Drive、GitHub、Zapier 等），外部生成器一键把 OpenAPI → MCP （Speakeasy、Stainless, CLI 工具）。选择跟随主流可减少未来迁移成本和碎片化风险。

Agent Graph / Namespacing 等高级能力依赖 MCP

MCP Roadmap 里的 Graph-Aware 通信、交互式 Workflows 都以 Server → Client 能力协商为前提；裸 REST 很难参与。

商业可行性

大型平台（Zapier MCP、AWS ModelArk 等）已把 "把 API 包成 MCP" 当作新品卖点；行业新闻普遍看好其"连接 AI 与传统软件"的潜在市场。

减少"无谓复杂性"的 6 条实践建议

1

先 PoC，再深度改造

利用OpenAPI→MCP 自动生成器或 GitHub 通用包装器快速出雏形，验证场景可行性后再重构 Tool 粒度。

2

避免 1 : 1 端点暴露

把用户常问的任务抽象成高阶 Tool（例如 getParkHours(date,parkName) 而不是暴露 destinations + schedule 多步链），并在 Server 侧裁剪冗余字段，可减 90 % token 消耗。

3

针对 LLM 设计 Schema

JSON 里保留对话必要字段即可；大对象转成摘要、分页或图像 URL （参见 Honeycomb 把复杂查询结果转"图像识别"来省 token 的做法）。

4

采用分层鉴权

若不想自建 IdP，可在 MCP Server 前加反向代理或使用 MCPEngine 之类框架，把标准 OAuth2/JWT 验证托管出去，弱化 MCP Auth 的侵入性。

5

选合适的传输模式

本地桌面插件更适合 stdio；SaaS-级多租户就上 HTTP + SSE，并用反向 proxy 复用已有 Ingress / 监控体系。

6

渐进引入 Graph-Aware 特性

先以单 Server → Client 模式落地，待场景成熟再开启 Agent Graph namespacing，减少一次性设计过度。

何时不要包装成 MCP Server?

判断标准 说明
LLM 不在你的业务链路里 比如 SDK 只给前端或后台服务消费，人类开发者写代码即可。
API 高度定制、回调/流式形态复杂 实现 JSON-RPC → gRPC → Streaming 桥接可能比原生集成更难。
安全合规压倒一切，但 MCP Auth 能力尚不满足 医疗、金融等对最小权限、审计追踪有硬性要求时，可等规范/SDK 成熟再上。

结语

将旧 API "包进" MCP 绝非银弹，也绝非一纸规范就能搞定的工作：

  • 对外 它把碎片接口"标准件化"，简化 LLM 调用路径；
  • 对内 它要求你思考如何让数据、鉴权、错误模型更"LLM-友好"。

如果你确实要让 Agent 自主调用工具、并打算在未来利用 Agent Graph、workflow 审批等能力，早点投入这层适配是"必要复杂性"；否则，把时间花在产品本身，而不是协议迁移，更符合"工程禅"。