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」）会直接引导模型越权。对策：
- 工具描述只写「做什么 + 参数含义」，不写流程性指令；
- server 端对第三方提交的工具描述做入网审核（等价于应用商店审核）；
- client 侧对返回结果做长度截断与内容审查，防止工具响应里夹带注入指令。
这三条加上前面的确认式调用，构成能力暴露层的完整防线：描述干净、清单最小、高危加闸。
第二道坎：鉴权模式
MCP 场景下 OAuth 流程有两个适配点：
1. token 作用域收窄。不要用用户级全量 token 接 MCP server，而是按工具最小集申请 scope。一个只读报表 Agent 不应该持有写权限 token。
2. server 端二次校验。不能信任 client 传来的身份声明——MCP server 收到调用后应独立验证 token 与 scope，防止 prompt injection 诱导越权调用。
最小 MCP client 鉴权连接示例：
# pip install mcp httpximportasynciofrommcpimportClientSessionfrommcp.client.streamable_httpimportstreamablehttp_client MCP_URL="https://api.example.com/mcp"TOKEN="your-scoped-token"# 只授予本场景最小 scopeasyncdefmain():headers={"Authorization":f"Bearer{TOKEN}"}asyncwithstreamablehttp_client(MCP_URL,headers=headers)as(r,w,_):asyncwithClientSession(r,w)assession:awaitsession.initialize()tools=awaitsession.list_tools()print("可用工具:",[t.namefortintools.tools])# 调用示例：作用域内的只读工具result=awaitsession.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 的一周实测口径（示意模板，数值以你自己的追踪数据为准）：
| 任务类型 | 单任务模型调用 | 单任务 token | 单任务工具调用 | 折算成本占比 |
|---|---|---|---|---|
| 简单查询 | 2–3 次 | ~8K | 1–2 次 | 15% |
| 多步报表 | 8–12 次 | ~45K | 4–6 次 | 45% |
| 跨源汇总 | 15–20 次 | ~120K | 8–12 次 | 40% |
三个从账本里长出来的结论：
- 帕累托集中：约 20% 的「跨源汇总」任务吃掉 40% 成本——优化优先级一目了然；
- 工具调用不是免费的：每次调用带回的上下文会让后续轮次 token 膨胀，工具返回值截断是性价比最高的优化；
- 配额设计要按任务类型分桶：统一按次数限流会让「多步报表」类用户吃亏，按 token 预算分桶更公平。
结语
三道坎对应三种角色：能力暴露是服务方的安全设计，鉴权是双方的信任契约，计费是平台的商业模式。三道坎的次序也有讲究——先锁暴露面、再收鉴权、最后谈钱，顺序反了的团队通常会在安全事件后被迫回炉重做。哪道坎你最担心？评论区站个队——也欢迎说说你踩过的 MCP 接入坑。
参考来源 / 信源清单
- 站内互链：10-30 Google MCP 头条（文章 ID 169561062）
- MCP 官方规范：modelcontextprotocol.io（成文时核验）
- OpenAI 计费政策：据公开报道（存疑口径标注，以官方公告为准）
AI 辅助生成，人工核验后发布。
