MCP Server 先别急着建：你的 API 网关早就管好了认证、限流和计费

MCP Server 先别急着建：你的 API 网关早就管好了认证、限流和计费

设想一个运营多年的 B2B SaaS：每个客户有自己的 API Key，API 网关统一执行配额，Cognito 管身份，用量精确计费。这套体系花了很多年才打磨到位。现在产品要支持 AI Agent，最顺手的做法是什么？写一个 MCP Server——一个 Node 服务，把 getInvoices、refundOrder 包成工具，转发给现有 API。为了省事，给它配了一个能访问所有租户的服务凭证。

于是整个技术栈里，出现了权限最大、年纪最轻、还没经过安全评审的一个组件。所有客户的 Agent 调用都从这里过：网关眼里只剩一个调用方，计费系统只剩一个调用方，审计日志里也只剩一个调用方。多年建成的租户隔离、按户限流和用量审计，一夜之间全部失效。

为什么 MCP Server 天生是个代理

MCP 的架构决定了它必须站在 Agent 和 API 之间。在一个已经安全加固的 API 前面加代理，只有两条路：

方案一：单一服务凭证。 这就是上面故事的结局。API 只能看到一个调用者，租户隔离完全依赖这个 MCP Server 的实现质量。它写错一行鉴权代码，就是全线失守。

方案二：Token 透传。 看起来完美，但 MCP 规范明确禁止——文档指出 MCP Server 不得接受不是签发给它自己的 Token，并警告调用方可能借此绕过下游限流等保护。这个提醒是对的。于是 MCP Server 必须升级成一个完整的 OAuth 组件：成为独立的资源服务器、校验 audience、为每个用户做 Token 交换签发下游 Token、处理第三方 API 的授权同意、重建按租户的限流与审计。能做到，强队也在做——但这等于在 API 前再造第二个身份感知网关。

UTCP 的思路：写说明书，不写代理

UTCP（Universal Tool Calling Protocol）提供了第三条路：不加服务器，而是提供一份"说明书"。这是一份 JSON 文档，描述每个工具做什么、怎么原生调用，通常通过现有 API 上的一个发现端点（如 GET /utcp）提供。

以两个现成端点为例：

{
  "name": "refund_order",
  "description": "退款。需要用户确认。",
  "inputs": {
    "type": "object",
    "properties": { "order_id": { "type": "string" } },
    "required": ["order_id"]
  },
  "tool_call_template": {
    "call_template_type": "http",
    "url": "https://api.example.com/v1/orders/{order_id}/refund",
    "http_method": "POST",
    "auth": {
      "auth_type": "api_key",
      "api_key": "${TENANT_API_KEY}",
      "var_name": "x-api-key",
      "location": "header"
    }
  }
}

关键在 "api_key": "${TENANT_API_KEY}"——说明书里没有任何秘密，只有一个占位符，由各 Agent 运行时根据自己的配置填充。A 公司的 Agent 发 A 的 Key，B 公司的 Agent 发 B 的 Key。

再看那张控制清单：认证鉴权，请求里带着真实客户 Key，现有授权器直接校验；限流配额，各客户的 Agent 消耗各自的使用计划；计费照常；审计日志里出现的是真实客户。我们没造新网关，只写了一份文档。

客户端拿到说明书后做的事也不神秘：从密钥管理服务加载本租户的 Key（模型永远看不到它）；对模型给的参数做 Schema 校验（永远不要信任模型输出）；高危操作先弹确认；填充 URL 和占位符，直接调 API。错误也是原生的——客户超额，Agent 收到的就是和其他客户端一模一样的 429，它可以把真实原因告诉用户。

MCP 仍然赢的地方

别相信"一边倒"的结论。分发能力：MCP 在 ChatGPT、Gemini、Claude、Cursor、VS Code 有一等公民地位，想让工具出现在这些客户端里，就得实现 MCP Server，UTCP 给不了。没有像样的 API：工具是数据库、文件系统或遗留系统时，需要一层受控的服务器，薄薄的 MCP Server 反而更安全。不受信任的运行环境：Agent 跑在你控制不了的设备上时，凭证和策略集中放在服务端更稳妥。不止工具：MCP 还定义了资源和提示的标准，UTCP 替代不了。API 本身没加固：UTCP 会继承你 API 的一切缺陷——没有按客户的 Key 和配额体系，直连也救不了你。

两者还能并用：MCP Server 本身可以被 UTCP 描述为另一种调用模板，同一个 Agent 可以用原生 UTCP 调自家 API，同时用 MCP 接其他一切。

决策清单

对每个想让 Agent 调用的工具问一遍：有带客户级凭证的、安全加固过的 API 吗？用 UTCP，写份说明书。有按租户限流、计费、审计的需求吗？用 UTCP，真实调用方会被看见。想让工具进 ChatGPT 和 Cursor 吗？实现 MCP Server。只有数据库或内部系统？薄服务层加 MCP。Agent 跑在不可信环境？凭证留在服务端，走 MCP。

结论

在一个安全加固过的 API 前面每加一层，就多承担一份认证、配额、计量和审计的责任。多数"让 Agent 调自家 API"的场景里，这份责任并不值得背。UTCP 建立在后台工程师早已熟练的那套信任之上：给出一份有文档的接口，让客户端带着自己的凭证来调。网关继续做它的工作，Agent 只不过是又一个守规矩的客户端。