Appearance
前言
Jeremiah Lowin 在 Stop Converting Your REST APIs to MCP 里把问题落在了调用成本上，REST API 可以保持细粒度，因为程序员读过一次文档，就能把接口选择和调用顺序固定在代码里，MCP Tool 列表却会进入模型的推理过程，接口越多，模型的选择成本越高，动作拆得越碎，一项任务经历的推理与调用轮次也越多，OpenAPI 转换器因此适合生成初稿，生产服务仍要人工裁剪
本文从接口治理完成之后开始，假定要开放的 HTTP API 已经选好，Tool 的粒度和名称也已经确定，后文只讨论这些接口怎样包装成 MCP，再通过 API Key 提供给远程客户端
订单系统已经有查询订单、取消订单、搜索商品和创建售后单等 HTTP 接口，普通程序拿着文档、地址与 API Key 就能调用，接入大模型后，接口可调用还不等于能力可用，模型缺少一份适合自己阅读的合同，它要知道系统提供哪些动作，每个动作何时使用，参数从哪里取得，调用会不会修改外部状态，失败以后又该改参数、重试还是停下来
MCP Server 就放在大模型与原有 HTTP 服务之间，它把面向程序员的路径、Header 与状态码整理成模型能够发现的 Tool、Resource 和 Prompt，再把一次 MCP 调用翻译回业务 HTTP 请求，协议转换只占很小一部分，麻烦集中在权限、参数所有权、错误语义和副作用上
两层 HTTP
HTTP 包装成 MCP 后，链路里会出现两段 HTTP，它们处在不同协议层
外层 HTTP 承载 MCP 协议，客户端通过同一个 /mcp 端点完成初始化、能力协商、工具发现和工具调用，消息使用 JSON-RPC 表达，远程 MCP 当前采用 Streamable HTTP，早期 HTTP+SSE 传输已经被它取代
内层 HTTP 属于原有业务系统，路径、方法、状态码、API Key 和返回格式仍由订单 API 定义，后端换成 RPC、数据库或消息队列也不会改变 MCP 对外合同，MCP Client 只看到能力，不需要理解上游部署细节
一次查询订单会经过四个阶段
前两步是普通 HTTP 调用里没有的能力发现，AI 应用由此得到工具名称、使用说明、输入模式、输出模式和副作用提示，后两步把 Tool 调用映射成业务请求，业务 URL、API Key 与内部状态码都留在服务端
包装
拿两个已经上线的订单接口做例子，查询接口按订单编号读取数据，取消接口修改订单状态，调用者目前需要理解路径、Header、请求体和状态码
| 业务动作 | 上游 HTTP 合同 | 调用方提供 | 适配层补充 | 主要结果 |
|---|---|---|---|---|
| 查询订单 | GET /v1/orders/{order_id} | 订单编号 | X-API-Key、可信租户编号、三秒超时 | 200 返回订单，404 表示不存在 |
| 取消订单 | POST /v1/orders/{order_id}/cancel | 订单编号、取消原因、操作号 | X-API-Key、可信租户编号、幂等 Header | 200 返回取消结果，409 表示状态冲突 |
包装后的交付物是一项独立运行的 MCP Server 服务，订单系统继续提供原来的 HTTP API，MCP Server 在启动时登记 Tool 合同与调用处理器，收到 tools/call 后找到对应处理器，再由处理器调用订单 API
协议层交给官方 SDK，JSON-RPC 编解码、初始化、能力协商、tools/list、tools/call 和 Streamable HTTP 都属于它的职责，项目代码提供 Tool 合同、处理器、身份上下文与上游调用，自己手写一套 MCP 协议解析器没有收益
项目代码落在五个位置
| 组件 | 负责什么 |
|---|---|
| Streamable HTTP 入口 | 在 /mcp 接收 MCP 请求，把消息交给 SDK 运行时 |
| API Key 中间件 | 校验客户端 Key，产生 Principal、Tenant 与 Scopes |
| Tool 注册表 | 保存名称、说明、输入模式、输出模式、行为注解与所需 scope |
| Tool 处理器 | 校验业务参数，组装固定上游请求，翻译结果与错误 |
| 上游 HTTP Client | 保存订单服务地址与上游 Key，统一控制连接池、超时和重试 |
Tool 注册在 MCP Server 中建立名称到处理器的映射，OpenAPI 只提供接口素材，以 get_order 为例，合同收敛如下
| 合同项 | get_order |
|---|---|
| 名称 | get_order |
| 使用说明 | 已知完整订单编号时查询订单状态、金额与可执行动作，不支持手机号或姓名搜索 |
| 模型输入 | order_id |
| 服务端上下文 | Tenant、Principal、客户端 Key ID |
| 结构化输出 | 订单编号、状态、金额、币种、更新时间、允许的后续动作 |
| 权限 | orders:read |
| 行为 | 只读，可在超时后有限重试 |
| 上游映射 | GET /v1/orders/{order_id} |
服务启动时，注册表把这份合同和 get_order 处理器绑定，客户端调用 tools/list 时，SDK 从注册表读取合同并返回，订单 API 此时不会收到请求，这一步解决的是能力发现，只有模型选择 get_order 并发出 tools/call，处理器才会运行
一次 get_order 调用在服务内按下面的顺序流动
这里要盯住参数的所有权，订单编号来自模型，上游地址和两份 Key 来自服务端配置，租户与调用者身份来自客户端 Key 的验证结果，模型没有机会指定 URL、Header、上游凭据或租户，get_order 因而只能访问预先写死的订单接口
cancel_order 的注册方式相同，合同增加取消原因、操作号、orders:cancel scope 与破坏性注解，处理器把参数映射到取消接口，用户确认由 MCP Host 展示，重复提交由上游幂等合同吸收，查询和取消由两个处理器承担，各自拥有权限、超时、审计与错误策略
注册表、处理器和上游客户端接好以后，订单系统仍然只讲 HTTP，MCP Client 也看不到订单服务地址，/mcp 成了两者之间唯一的公开合同
能力
REST 方法无法直接决定 MCP 原语，GET 不会天然对应 Resource，POST 也不必机械地对应 Tool，判断依据是由谁选择它，以及数据进入模型上下文后准备怎样使用
| MCP 原语 | 控制者 | 适合暴露的内容 |
|---|---|---|
| Tool | 模型根据对话决定调用 | 查询、搜索、计算、写操作和外部动作 |
| Resource | AI 应用决定读取并装入上下文 | 文档、配置、模式、目录与可浏览数据 |
| Prompt | 用户显式选择 | 固定工作流与领域提示模板 |
查询订单虽然来自 GET /orders/{id}，仍然适合 Tool，因为模型要从用户对话中取得订单号并主动查询，订单 API 文档更适合 Resource，由 AI 应用按需加入上下文，取消订单属于有副作用的 Tool，售后排查步骤则可以做成 Prompt，引导模型按查询状态、判断条件、请求确认和创建售后单的顺序工作
万能 HTTP Tool 不应开放给模型，让模型自己填写方法、URL、Header 和 Body，会把服务端请求伪造 SSRF、内网探测、任意写操作和凭据选择都带进对话调用面，工具描述也说不清某次请求究竟在查询订单还是删除数据
接口应按业务动作收敛
| HTTP 接口 | MCP Tool | 模型决定什么 | MCP Server 决定什么 |
|---|---|---|---|
| 查询订单 | get_order | 订单编号 | 上游地址、API Key、超时与字段裁剪 |
| 取消订单 | cancel_order | 订单编号、原因、操作幂等号 | 权限、上游凭据、审计与错误翻译 |
| 搜索商品 | search_products | 查询词、筛选条件 | 分页上限、排序白名单与结果大小 |
| 创建售后单 | create_after_sale | 订单编号、问题类型和说明 | 用户身份、租户、风控与幂等 |
一个 Tool 对应一个能够独立解释的业务动作，模型才有机会从名称和说明里选对它，服务端也能单独配置权限、限流和审计，内部 HTTP 接口数量不必与 Tool 数量相等，查询订单可能只调用一个接口，创建售后单则可能在处理器里组合订单、物流和工单三个服务
HTTP 适配层可以做得很薄，也可以承载领域编排，通常有三种厚度，选哪一种取决于原有 API 是否已经接近业务语义
| 形态 | 做法 | 优点 | 代价 |
|---|---|---|---|
| 薄适配 | 一个 Tool 对应一个 HTTP 接口 | 实现简单，行为容易追踪 | 上游细节容易泄漏，Tool 数量可能过多 |
| 领域适配 | 一个 Tool 对应一个业务动作，内部调用少量接口 | 模型看到的语义稳定，权限容易收口 | 适配层开始承担业务判断 |
| 工作流适配 | 一个 Tool 执行完整流程或启动异步任务 | 模型调用次数少，流程一致 | 执行时间、补偿、进度和幂等更复杂 |
订单查询适合薄适配，取消订单通常需要领域适配，因为服务端要检查订单状态、权限和幂等，批量导出对账单适合工作流适配，调用后返回任务编号，再通过查询任务状态或 MCP Tasks 取得结果
适配层过薄，模型就得自己拼装内部流程，调用顺序和错误恢复容易漂移，适配层过厚，业务规则又会在订单系统和 MCP Server 中各写一份，合适的边界是让领域服务继续裁决业务合法性，MCP Server 只做协议转换、少量编排和安全收口
合同
Tool 合同直接影响模型的选择与填参，它包含名称、说明、输入模式、输出模式与行为注解，名称保持稳定并使用业务动词，说明则要交代使用条件、禁止场景和副作用，一句查询订单接口提供不了这些信息
get_order 的说明可以明确要求完整订单编号，返回订单状态与金额，不支持按手机号模糊搜索，cancel_order 的说明要指出调用前必须获得用户确认，只允许取消满足业务条件的订单，重试时必须复用同一个幂等号，这些信息会参与模型的工具选择
输入模式仍然是一道服务端校验，订单号要限制长度和字符范围，状态使用枚举，分页数量设置上限，时间采用固定格式，模型参数不能因为来自 MCP Client 就被视为可信，模式只能拦截结构错误，订单归属、状态流转与权限仍由业务服务检查
输出也要单独建模，上游完整 JSON 里常有数据库主键、风控备注和调试链接，一旦从 MCP 返回，它们就进入了对外合同，也可能进入模型上下文，订单查询保留订单编号、状态、金额、币种、更新时间和允许的后续动作已经足够
行为注解记录工具性质
| 注解 | 表达什么 |
|---|---|
readOnlyHint | 是否只读 |
destructiveHint | 是否可能造成删除、取消或覆盖 |
idempotentHint | 相同参数重复调用是否保持相同效果 |
openWorldHint | 是否会与开放网络或外部实体交互 |
这些注解属于提示，AI 应用可以据此展示确认界面，MCP Server 仍需执行权限和业务检查，来自不可信 Server 的注解也不能被客户端当作安全证明
错误
上游 HTTP 状态与 MCP 错误分属两层协议，订单 API 返回 404，只说明某次工具执行没有找到订单，/mcp 端点仍然存在，因此，外层 HTTP 通常保持成功，工具结果标记为执行错误
这项区分会改变客户端处理逻辑，MCP 端点返回 HTTP 401 表示 API Key 未通过验证，工具结果中的 isError 表示调用已经进入 Tool，只是参数、业务状态或上游服务发生问题，若把订单不存在直接映射为 MCP 端点的 HTTP 404，客户端可能把它误判成协议地址失效
错误要让模型知道下一步怎么走，又不能泄漏内部结构
| 上游结果 | 对外 Tool 错误 | 建议动作 |
|---|---|---|
| 400、422 | 参数不符合业务规则 | 修正参数后重试 |
| 401、403 | MCP Server 无权访问上游 | 停止重试，检查服务配置 |
| 404 | 业务对象不存在 | 核对编号 |
| 409 | 当前状态不允许执行 | 查询最新状态后调整计划 |
| 429 | 调用过于频繁 | 按退避时间重试 |
| 5xx、网络失败 | 上游暂时不可用 | 有限重试或结束任务 |
上游响应不宜原样透传，网关地址、数据库错误、内部堆栈和租户信息可能混在错误正文中，对模型只返回稳定业务错误码与简短说明，详细响应写入受控日志，并通过追踪编号关联
输入模式校验失败也应作为 Tool 执行错误返回，让模型根据字段约束修正参数，JSON-RPC 协议错误留给非法消息、未知方法与协议版本问题
API Key
这个设计用 API Key 保护 MCP Server，链路上有两份凭据，一份确认哪个 MCP Client 正在连接，另一份供 MCP Server 访问原有 HTTP API
两份 Key 不能复用，客户端 Key 面向 AI 应用或租户，控制它能发现和调用哪些 Tool，上游 Key 面向订单 API，代表 MCP Server 的服务身份，客户端 Key 一旦能够直连订单 API，适配层的字段校验、限流和审计就都能被绕过
API Key 属于部署层约定，MCP 标准授权文档为远程 HTTP 定义了 OAuth 2.1 流程，私有系统、服务间调用或客户端可预先配置固定 Header 时，API Key 更容易落地，部署前要确认目标 MCP Host 支持为 Streamable HTTP 连接配置自定义 Header，若 Host 不支持，需要增加本地桥接进程、接入网关支持的认证方式，或改用标准 OAuth 流程
一把能够轮换和吊销的客户端 Key，至少要关联这些数据
| 字段 | 用途 |
|---|---|
| Key ID | 定位记录，支持日志展示与轮换 |
| Secret | 高熵随机值，只在创建时展示一次 |
| 调用主体 Principal | 调用方应用、用户或服务身份 |
| 租户 Tenant | 允许访问的租户边界 |
| 权限范围 Scopes | 可调用能力，例如 orders:read、orders:cancel |
| 环境 Environment | 开发、测试或生产环境 |
| 到期时间 Expires At | Key 在何时失效 |
| 状态 Status | 启用、冻结或吊销 |
| 配额 Quota | 速率、并发与每日调用量 |
服务端不需要保存明文 Secret，可以保存带服务端密钥的摘要，收到 Key 后先用 Key ID 定位记录，再用常量时间比较验证 Secret，随后检查状态、有效期、环境、来源网络、scope 与配额，验证完成后形成请求身份上下文
API Key 不能作为 Tool 参数，模型不应读取、选择或回显它，租户编号和用户身份也不应由模型填写，它们来自 Key 对应的身份记录，MCP Server 把这些信息加入服务端调用上下文，模型只提交订单编号与业务参数
传统 API 网关常按路径和方法授权，MCP 的所有调用却集中在 /mcp，网关看到的大量请求都是同一个 POST 路径，只在路径层验证 Key，无法区分查询订单与取消订单
路径级鉴权到这里就结束了，网关验证 Key 是否有效，顺便限制请求大小和总速率，MCP Server 解析 JSON-RPC 后，再按具体 Tool 检查 scope
| Tool | 需要的 scope |
|---|---|
get_order | orders:read |
search_products | products:read |
cancel_order | orders:cancel |
create_after_sale | after-sale:create |
tools/list 也应根据 scope 过滤，只拥有 orders:read 的 Key 不必看到 cancel_order，这可以减少模型误选和能力信息泄漏，但隐藏工具不能替代调用校验，客户端仍可能绕过列表直接发送 tools/call，服务端必须再次检查
同一个 Key 跨租户调用会把普通填参错误放大成横向越权，一份 Key 应绑定一个明确租户，服务端从身份上下文取得租户，再给上游请求加入可信租户信息，模型传来的 tenant_id 不参与授权
Key 缓存直接决定吊销速度，每个请求都查数据库代价偏高，缓存时间过长又会让已吊销 Key 继续有效，常见折中是短 TTL 加吊销事件，高风险 Tool 执行前再查一次，查询类 Tool 接受几秒钟的缓存窗口
生产 API Key 必须支持无中断轮换，调用方在过渡期同时持有旧 Key 与新 Key，流量切换完成后吊销旧 Key，过渡窗口要写进制度，不能无限期保留两份有效凭据
Key 日志只记录 Key ID，不能记录完整 Secret，错误响应也不要回显 Key，Secret 应保存在 Secret Manager 或加密配置中，禁止写进系统提示词、Tool 描述、对话历史和追踪正文
API Key 还需要环境隔离，测试 Key 不能访问生产 MCP Server，生产 Key 也不应出现在开发机配置中，Key 前缀可以帮助识别环境和用途，但前缀没有授权能力，服务端仍要以记录中的环境字段为准
写操作
取消订单要过三道控制，MCP Host 的用户确认拦住误操作，Key scope 拦住越权，上游幂等合同处理网络重试带来的重复执行
在 Tool 参数中加入 confirm=true 不能形成可靠确认，模型自己就能填写这个字段，有效确认发生在 MCP Host 的界面，Host 展示 Tool 名称、订单编号、原因和影响，用户同意后再发起调用，MCP Server 随后检查 orders:cancel scope
幂等要落在最接近副作用的业务服务中，MCP Server 为一次取消生成或转发稳定操作号，上游把操作号与调用者、订单号、动作和请求摘要绑定，相同请求重复到达时返回第一次结果，同一个操作号携带不同请求时返回冲突
idempotentHint 只描述已有合同，无法替业务接口产生幂等，查询接口可以在超时后有限重试，写接口只有在幂等保护成立时才适合自动重试，遇到 409 时应先查询最新状态
输出
订单前端使用的 HTTP 响应往往不适合直接进入模型上下文，字段太多只是一个问题，列表、文件和长任务还会挤占上下文或长期占用连接，MCP Server 因此要维护一份独立输出模型
订单查询只返回模型完成任务所需字段，列表查询设置固定上限并返回不透明游标，模型不能把上游分页令牌拆开修改，大文件返回受控资源链接或短期下载地址，批量任务返回任务编号与状态，不要让一次 Tool 调用长期占用连接
| 数据形态 | MCP 输出方式 |
|---|---|
| 单个业务对象 | 结构化结果 |
| 小型列表 | 限量数组与下一页游标 |
| 大文件 | Resource Link 或短期受控地址 |
| 长任务 | 任务编号、状态查询或 MCP Tasks |
| 内部诊断 | 只写服务端日志，返回追踪编号 |
适配层还要处理版本变化，上游字段调整可以在内部翻译，对外 Tool 名称和输出语义保持稳定，新增可选字段通常可以原位演进，删除字段、改变业务含义或扩大副作用时，应增加新 Tool 并给旧 Tool 留迁移期
部署
把 Streamable HTTP 挂到 /mcp 后，本地进程已经能接受协议请求，远程开放还差服务部署、网络入口和客户端登记，生产链路如下
发布工作落在下表六处
| 交付面 | 要完成的事 | 完成后的结果 |
|---|---|---|
| 服务 | 将 MCP Server 作为独立进程或容器运行，注入上游地址和上游 Key | 内网可以访问服务端口与 /mcp |
| 出口 | 只允许 MCP Server 访问订单 API 的固定域名或网段 | Tool 无法借参数访问任意地址 |
| 入口 | 网关把公网或企业网地址转发到 /mcp，保留 MCP 与流式响应所需 Header | 远程 MCP Client 可以完成协议请求 |
| 地址 | 为 mcp.example.com 配置 DNS 与 TLS 证书 | 客户端得到稳定 HTTPS 地址 |
| 鉴权 | 网关或 MCP Server 校验 X-MCP-API-Key，服务内继续执行 Tool scope | 连接身份与具体能力都受控 |
| 接入 | 在 MCP Host 中登记名称、Streamable HTTP、URL 与自定义 Header | Host 可以发现并调用 Tool |
远程 MCP 使用 Streamable HTTP，一个 /mcp 端点承载协议消息，POST 用于发送每一条 JSON-RPC 消息，GET 用于可选的服务端事件流，不提供独立事件流时可以返回 405，有状态会话还可以接受 DELETE 来结束会话，网关若只放行 POST，服务端通知、断线恢复和会话终止就可能失效
初始化后的请求还会携带协商得到的 MCP-Protocol-Version，有状态服务会增加 MCP-Session-Id，恢复事件流时会使用 Last-Event-ID，这些 Header 与 Accept、Content-Type、X-MCP-API-Key 都不能被代理层删除，启用 SSE 时还要关闭响应缓冲并调整空闲超时
客户端登记远程 MCP Server 时填写四项信息，服务名称、传输类型、完整 /mcp 地址和 API Key Header，保存并连接后，MCP Host 自动完成下面这段协议过程
模型不会直接操作这段连接，MCP Host 负责初始化、维护客户端与展示 Tool，模型在对话中选中 get_order 后，Host 生成 tools/call，MCP Server 才开始执行前文的订单 HTTP 映射
API Key 必须跟随每次 HTTP 请求发送，初始化成功只能说明当前请求通过了验证，不能替后续请求长期背书，MCP-Session-Id 用来关联会话，也不能承担身份认证
无状态模式适合查询和短写操作，请求可以分散到多个副本，MCP Server 不依赖本机内存保存会话，有状态模式适合服务端通知、进度推送和事件恢复，需要共享事件存储或一致路由，反向代理也要允许 SSE 并调整响应缓冲与长连接超时
Streamable HTTP 上线前还要补齐这些控制
| 控制 | 作用 |
|---|---|
| HTTPS | 保护 API Key 与业务数据 |
Origin 校验 | 防止网页通过 DNS 重绑定访问 MCP Server |
本地只绑定 127.0.0.1 | 避免开发服务暴露到局域网 |
| API Key 每请求校验 | 防止会话劫持后绕过身份验证 |
| 请求体与并发上限 | 防止大参数和并发耗尽资源 |
| 固定上游与出口策略 | 限制 SSRF、内网探测和数据外传 |
有些通用 MCP Host 不允许为远程连接配置任意 Header，这会直接影响 API Key 方案，选型阶段要先验证客户端能力，能配置 Header 时使用固定 Key，不能配置时可以部署一个本地 stdio 桥接器，由桥接器从环境变量读取 Key 并连接远程 MCP Server，公开互联网服务则更适合标准授权流程
网关只看到统一 /mcp 路径时，不应承担全部 Tool 授权，除非它能够安全解析 JSON-RPC 并理解 tools/call 参数，MCP Server 掌握 Tool 名称，适合做细粒度 scope 校验，业务 API 掌握订单归属和状态机，继续保留最终裁决权
限流也要分层，网关按 Key 控制总请求速率，MCP Server 按 Tool 控制成本和风险，查询订单可以较高频，取消订单并发应更低，批量导出按任务数和数据量计费，只按 IP 限流会让共享出口下的多个租户互相影响
负载均衡器的健康检查应使用单独的 /healthz，不要拿 /mcp 的 GET 充当探活，请求 /mcp 可能建立事件流，也可能按服务能力返回 405，这两种结果都无法准确说明订单 API 与 Key 存储是否可用，健康检查还应区分进程存活与依赖就绪，防止上游短暂故障把全部 MCP 副本同时摘除
上线前可以用 MCP Inspector 选择 Streamable HTTP，填入远程 URL 与 X-MCP-API-Key，然后按下面的结果验收
| 检查 | 预期结果 |
|---|---|
| 不带 Key 或使用无效 Key 连接 | /mcp 返回 HTTP 401，消息不会进入 Tool 分派 |
| 携带只读 Key 初始化 | 协议版本协商成功，Server 声明 tools 能力 |
| 使用只读 Key 获取 Tool 列表 | 可以看到 get_order，看不到 cancel_order |
绕过列表直接调用 cancel_order | 请求进入 MCP 后得到 Tool 权限错误，不能触发上游取消接口 |
调用 get_order | 上游只出现预期的固定路径，租户和上游 Key 由服务端注入 |
| 上游返回 404 | MCP 连接保持有效，Tool Result 表示订单不存在 |
| 重复提交同一取消操作号 | 上游返回同一操作结果，不执行第二次取消 |
| 查看日志和追踪 | 能按 Key ID 与 Tool 定位请求，看不到任何完整 Secret |
能够访问 /mcp 只能证明网络已通，tools/list 返回预期合同才能证明 Tool 已经注册，等 tools/call 准确到达固定上游，权限和错误映射也符合预期，这个 HTTP API 才算以 MCP Tool 对外提供
OpenAPI
OpenAPI 很适合生成适配骨架，却没有资格决定对外能力，一份内部文档里常同时放着普通接口、管理员接口、调试接口、批量接口和历史版本，全量生成会把内部攻击面直接变成模型工具面
生成前先加上八项约束
- 建立允许列表，只选择确实需要被 Agent 调用的业务动作
- 按业务语义重新命名 Tool，不直接照搬内部
operationId - 删除 API Key、租户、用户身份、内部路由和调试参数
- 收紧长度、枚举、分页和文件大小
- 定义独立输出模型，去掉内部字段
- 标注只读、破坏性和幂等性质
- 为每个 Tool 绑定 scope、限流、超时和审计策略
- 将上游错误映射成稳定 Tool 错误
生成器只做路径、字段和模式转换，Tool 边界仍由人决定，OpenAPI 更新可以触发适配器检查，却不能顺手扩大 MCP 的对外能力
观测
一次 MCP 调用跨过客户端、网关、适配器和业务 API，每次 Tool 调用都要生成统一追踪编号，日志记录 Key ID、Principal、Tenant、Tool、耗时、结果类别、上游状态和幂等操作号
参数与结果按字段脱敏，订单号可以部分掩码，原因文本可能含有个人信息，API Key、Authorization Header、Cookie 和完整上游错误禁止进入日志，模型提示词与对话正文也不应默认写入基础调用日志
指标可以按 Tool 维度统计调用量、成功率、P95 耗时、上游状态分布、限流次数、用户拒绝确认次数与幂等命中次数，只有总接口 QPS 时，查询和取消会混在同一个 /mcp 路径下，无法判断具体能力出了什么问题
选型
MCP 适合需要被多个 AI 应用发现和调用的 HTTP 能力，如果模型只存在于一个自有后端，函数调用与普通 HTTP 客户端已经由同一套代码控制，增加 MCP 会多出协议、鉴权和运维成本
业务接口还没有稳定权限边界时，也不宜急着开放 MCP，哪些调用方能看哪些订单，取消需要什么条件，审计保留多久，这些规则应先在业务服务中成立，MCP Server 负责执行和翻译合同，无法补出上游缺失的权限模型
判断并不复杂，能力要被多个 MCP Host 复用，HTTP API 已经有稳定业务语义，权限能够映射到 API Key scope，输出也能控制在模型上下文承受的范围内，这时加一层 MCP 才有收益，其中任何一项还说不清，都应先整理原有服务
结论
把现有 HTTP API 包成 MCP，工程动作很具体，挑出适合模型调用的业务接口，为每个动作注册 Tool 合同与处理器，处理器注入服务端配置并调用固定上游，再由官方 SDK 把 Tool 挂到 Streamable HTTP 的 /mcp，经过 HTTPS 网关和 API Key 交给 MCP Host
协议代码大多由 SDK 提供，工程判断落在另一处，什么能暴露，什么由模型填写，身份从哪里取得，写操作如何确认和去重，结果能带出多少字段，MCP Server 的价值就在这些判断里