上一篇文章讲了 MCP 是什么、和 API 什么关系。这篇讲更实际的问题：你手上有一堆现成的 API，到底要不要包一层 MCP？怎么包？包完怎么保证它能用、敢用？
先给结论：MCP server 不是换个协议重新卖一遍接口，它是在你现有 API 前面加一层"AI 能直接用"的适配层。值不值得做，取决于你的客户里有多少人在跑 Agent，而不是热度。
一、先想清楚：你的 API 该不该上 MCP
很多人被"MCP 是趋势"带着走，上来就问怎么写代码。顺序反了。先做三个判断：
1. 客户里有没有人在跑 Agent？
这是最关键的判断。如果你的客户大多数还是"写代码调接口"的开发者，他们直接读文档、调 REST API 就够了，MCP 对你没有增量价值。只有当客户开始用 Claude、ChatGPT、各类 Agent 框架去"让 AI 自己调工具"时，MCP 才变成他们选择服务商的考量点——已经有客户在问"你们支不支持 MCP"了。
2. 你的 API 是不是被 AI 高频复用？
MCP 解决的是"同一个工具被多个 AI 应用反复用"的问题。如果你只有一两个核心接口，客户接入方式也固定，写一套 MCP 反而增加维护负担。
3. 有没有人持续维护？
MCP server 不是写完就完事：接口变更要同步、鉴权要轮换、日志要有人看。没有维护人力，不如先不做。
一句话：客户在跑 Agent、接口会被 AI 反复调、有人长期维护——三个都满足，值得做。缺任何一个，先放一放。
二、实操：三条路把 API 变成 MCP server
确认要做之后，有三条路，从"最可控"到"最快"：
路线 1：官方 SDK 手写（最可控）
MCP 官方提供 Python、TypeScript、Java、Rust 等语言的 SDK（Python 包名为 mcp，当前版本 1.9.x）。以 Python 为例，核心代码骨架非常短：
from mcp.server import MCPServer
mcp = MCPServer("MyAPI")
@mcp.tool()
def query_balance(account: str) -> str:
"""查询指定账户的余额与用量。"""
return call_your_existing_api(account) # 复用你已有的业务逻辑
if __name__ == "__main__":
mcp.run()
注意：工具函数里不要出现 api_key 之类的参数——密钥走环境变量或网关注入，不要让模型来传（见下面"入站鉴权"）。
本地调试用官方工具 uv run mcp dev server.py，会自动打开 MCP Inspector 图形界面，可以逐个测试工具、看 JSON-RPC 2.0 报文，不用先接任何客户端。
为什么推荐手写起步：工具名、描述、参数 schema 完全由你控制，而这三样直接决定"AI 会不会用、用得对不对"。
路线 2：FastMCP 从 OpenAPI 自动生成（最快）
如果 API 已经有 OpenAPI 规范（或本身是 FastAPI 写的），FastMCP 3.0 提供了 OpenAPIProvider：把 OpenAPI 定义喂进去，每个路由自动变成一个 MCP 工具，不需要手写工具处理函数，官方示例 20 行内完成。
适合场景：接口多、规范全、想快速出一个可演示的版本。
注意：自动生成省事，但工具名和描述是"机器味"的——get_xxx_info 这类名字模型能猜，复杂参数就很容易理解错。自动生成之后，必须人工打磨工具描述。
路线 3：现成适配器 / 云厂商 MCP 工具集（不写代码）
社区有 REST-to-MCP 适配器（读 OpenAPI 生成工具），云厂商也在推自己的 MCP 工具集，比如火山引擎的 AgentKit 支持把 API 配置成 MCP 工具集并做入站身份认证。微软 Azure Foundry 也支持把 Function App 注册成 MCP server，提供 Key 或 Entra ID 认证。
适合场景：没有专职开发、想快速验证"客户到底要不要 MCP"。
三、生产级封装：决定"能用"和"敢用"的 5 个细节
demo 阶段跑通很简单，生产环境能不能让客户放心接，看这 5 件事：
1. 工具设计是给模型看的，不是给代码看的
一个端点拆成一个工具，名字要表达业务含义（比如 query_balance 而不是 api_123），描述里写清每个参数是什么、返回结构长什么样。模型没有文档可查，它全靠工具描述来理解你的接口——描述写不清楚，工具就等于不存在。
举个真实会发生的反例：你把工具描述写成 get_data(offset, limit)，返回一个"字段很多的对象"，模型大概率会乱猜参数含义，甚至把"分页"当成"筛选"，一次调用就报错；用户试两次发现工具不可用，转头就去用别的服务商了。反过来，描述里写清楚"offset 是第几条开始，limit 是返回条数，最多 100"，模型一次就能用对。
2. 参数校验必须自己加
用 Pydantic 之类做参数校验。模型的输入不是可靠的，把脏参数直接透传给后端，轻则报错，重则把异常数据写进你的业务系统。
3. 入站鉴权必须自己扛
这是最容易被忽略的一条。MCP 授权规范基于 OAuth 2.1，但协议层面把授权标为可选；2025 年 7 月一次公开扫描发现至少 1862 个公开 MCP 实例对未认证请求开放。所以入站认证（API Key、OAuth、网关层校验）必须由你自己实现，不要指望协议帮你兜底。
4. 字段投影：只暴露该暴露的
把后端返回的整体 JSON 原样透传给模型是常见错误。做一层字段投影，只把模型完成任务需要的字段暴露出去，敏感字段（内部 ID、密钥、计费明细里的非必要信息）留在服务端。
5. 全程可观测
记录每一次工具调用：谁在调、传了什么参数、返回了什么、耗时多少、消耗了多少额度。没有日志，客户出了问题你连排查入口都没有——这也是目前大量 MCP 部署的普遍短板。
四、算一笔账：投入和维护
- 首版：一个熟悉 SDK 的开发者，1-3 天能做出第一个可用的 server（含鉴权和日志）。
- 持续维护：接口变更要同步工具定义、鉴权凭据要定期轮换、调用日志要有人看。这是一项长期运维，不是一次性交付。
- 值得做的判断标准：你客户名单里有 2-3 个在跑 Agent 的，或者有明确客户在问"MCP"，就值得投入；否则可以再等等。
对 API 服务商来说，MCP 的增量其实不只是技术——它还是一个可写进报价单的交付物。"支持 MCP 接入"意味着你的接口多了一个别人没有的消费入口：客户用 Claude、ChatGPT 或自己的 Agent 框架时，少了一道"读文档、写集成、反复调试"的工序，这对正在跑 Agent 的客户是实打实的采购加分项。而且这是一次性投入、重复受益：同一个 MCP server，所有支持 MCP 的 AI 客户端都能直接连。
首版做到什么程度算"能上线"？ 四条验收标准：
- 至少一个核心工具能在 MCP Inspector 里完整跑通，参数校验和错误返回正常；
- 入站鉴权已生效，未带凭证的请求被明确拒绝；
- 每个工具调用都有日志（谁调的、参数、耗时、结果）；
- 用 Claude 或任意一个 MCP 客户端实测，AI 能靠描述正确调用工具、拿到想要的结果。
五、结论
MCP 对 API 服务商的意义，是给现有 API 加一层"AI 友好"的入口，而不是让你去重新发明一套协议。
做之前先判断客户结构，别为热点硬上；做的时候从最小工具集起步（先 Tools，必要时再补 Resources、Prompts），有 OpenAPI 就从 FastMCP 起步，没有就官方 SDK 手写；上线前把鉴权、参数校验、字段投影、可观测性四件事做扎实。
你的 API 本身没变，变的是多了一个"会思考的消费者"能直接使用它的入口。这才是 API 服务商在 Agent 时代真正的增量。
（参考资料：MCP 官方 Python SDK 文档 py.sdk.modelcontextprotocol.io、FastMCP 官方文档与 OpenAPIProvider 示例、火山引擎 AgentKit MCP 工具集文档、Microsoft Foundry MCP 文档、Cloud Security Alliance 公开扫描报告）
