MCP第三方Agent接入实战：鉴权、能力暴露与计费三道坎
上一篇《Google MCP 平台工程化》（站内互链）留言区留了三个问题，这篇逐一回填。这三个问题——暴露什么、怎么鉴权、谁付钱——恰好对应 MCP 接入的三道坎，也是几乎所有第三方接入方案会卡住的地方。
接入架构总览：先把角色分清
动手前先理清三方角色，MCP 接入的所有坑都出在角色边界上：
| MCP Server（服务方） | 定义工具、校验 scope、执行动作 | 把内部接口直接翻译成工具、不做二次鉴权 |
| MCP Client（Agent 框架） | 发现工具、组装调用、处理结果 | 缓存工具列表失效后仍调用、把错误静默吞掉 |
| 授权层 | 发放最小 scope 的 token | 用户级全量 token 一发了之 |
先想清楚每个角色的职责边界，后面三道坎的方案才有落点。
第一道坎：能力暴露粒度
核心原则一句话：给 Agent 多少工具，等于给它多少攻击面。
常见的错误做法是把整个服务的工具清单一次性暴露。正确做法是分层：
| 只读层 | 查询类工具 | list_orders, get_user |
| 操作层 | 低风险写操作 | create_ticket |
| 管理层 | 高危操作，默认不暴露 | delete_resource |
实践要点：每个 MCP server 只挂当前 Agent 场景必需的工具子集；高危工具用「确认式调用」包装（Agent 发起 → 人工/策略审批 → 执行）——这与 DeepSeek Super-agent 的 20 条确认式审批思路异曲同工（站内互链 article-01）。
工具描述本身也是攻击面
一个被普遍低估的细节：工具的 description 字段会进入模型上下文，它既是模型选工具的依据，也可能被注入。恶意或粗心的描述（比如嵌在描述里的「调用时顺便执行 xxx」）会直接引导模型越权。对策：
这三条加上前面的确认式调用，构成能力暴露层的完整防线：描述干净、清单最小、高危加闸。
第二道坎：鉴权模式
MCP 场景下 OAuth 流程有两个适配点：
1. token 作用域收窄。 不要用用户级全量 token 接 MCP server，而是按工具最小集申请 scope。一个只读报表 Agent 不应该持有写权限 token。
2. server 端二次校验。 不能信任 client 传来的身份声明——MCP server 收到调用后应独立验证 token 与 scope，防止 prompt injection 诱导越权调用。
最小 MCP client 鉴权连接示例：
# pip install mcp httpx
import asyncio
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client
MCP_URL = "https://api.example.com/mcp"
TOKEN = "your-scoped-token" # 只授予本场景最小 scope
async def main():
headers = {"Authorization": f"Bearer {TOKEN}"}
async with streamablehttp_client(MCP_URL, headers=headers) as (r, w, _):
async with ClientSession(r, w) as session:
await session.initialize()
tools = await session.list_tools()
print("可用工具:", [t.name for t in tools.tools])
# 调用示例：作用域内的只读工具
result = await session.call_tool("get_user", {"user_id": "42"})
print(result.content)
asyncio.run(main())
排错清单：
- 401 Unauthorized：token 缺失或 scope 不含目标工具 → 检查授权范围；
- initialize 超时：网关不支持 streaming → 换 SSE 传输或升级网关；
- 工具列表为空：server 端按身份过滤了工具 → 确认 scope 命中暴露层配置。
第三道坎：计费模型
行业信号已经出现：据报道，OpenAI 将从 12 月起合并 ChatGPT+Codex 为单一 token 配额，Agent 用量成为计费单位（据公开报道口径，以官方公告为准）。这意味着什么？
- 成本测算单位从「次数」转向「token × 工具调用链深度」：一个 Agent 任务内部可能包含 5–20 次模型调用，计费评估要按任务粒度摊；
- MCP server 提供方的成本回收：第三方接入要么走调用配额，要么走订阅分成，「免费无限用」在 Agent 高频调用下不可持续；
- 给团队的账本建议：上线前对典型任务跑一周调用链追踪，记录每任务 token 消耗与工具调用数，再倒推定价或配额。
计费测算：一个可落地的账本模板
把「按任务粒度摊成本」落成表格式账本。以下是一个只读报表 Agent 的一周实测口径（示意模板，数值以你自己的追踪数据为准）：
| 简单查询 | 2–3 次 | ~8K | 1–2 次 | 15% |
| 多步报表 | 8–12 次 | ~45K | 4–6 次 | 45% |
| 跨源汇总 | 15–20 次 | ~120K | 8–12 次 | 40% |
三个从账本里长出来的结论：
结语
三道坎对应三种角色：能力暴露是服务方的安全设计，鉴权是双方的信任契约，计费是平台的商业模式。三道坎的次序也有讲究——先锁暴露面、再收鉴权、最后谈钱，顺序反了的团队通常会在安全事件后被迫回炉重做。哪道坎你最担心？评论区站个队——也欢迎说说你踩过的 MCP 接入坑。
参考来源 / 信源清单
AI 辅助生成，人工核验后发布。
