MCP第三方Agent接入实战鉴权、能力暴露与计费三道坎上一篇《Google MCP 平台工程化》站内互链留言区留了三个问题这篇逐一回填。这三个问题——暴露什么、怎么鉴权、谁付钱——恰好对应 MCP 接入的三道坎也是几乎所有第三方接入方案会卡住的地方。接入架构总览先把角色分清动手前先理清三方角色MCP 接入的所有坑都出在角色边界上角色职责常见错误MCP Server服务方定义工具、校验 scope、执行动作把内部接口直接翻译成工具、不做二次鉴权MCP ClientAgent 框架发现工具、组装调用、处理结果缓存工具列表失效后仍调用、把错误静默吞掉授权层发放最小 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_URLhttps://api.example.com/mcpTOKENyour-scoped-token# 只授予本场景最小 scopeasyncdefmain():headers{Authorization:fBearer{TOKEN}}asyncwithstreamablehttp_client(MCP_URL,headersheaders)as(r,w,_):asyncwithClientSession(r,w)assession:awaitsession.initialize()toolsawaitsession.list_tools()print(可用工具:,[t.namefortintools.tools])# 调用示例作用域内的只读工具resultawaitsession.call_tool(get_user,{user_id:42})print(result.content)asyncio.run(main())排错清单401 Unauthorizedtoken 缺失或 scope 不含目标工具 → 检查授权范围initialize超时网关不支持 streaming → 换 SSE 传输或升级网关工具列表为空server 端按身份过滤了工具 → 确认 scope 命中暴露层配置。第三道坎计费模型行业信号已经出现据报道OpenAI 将从 12 月起合并 ChatGPTCodex 为单一 token 配额Agent 用量成为计费单位据公开报道口径以官方公告为准。这意味着什么成本测算单位从「次数」转向「token × 工具调用链深度」一个 Agent 任务内部可能包含 5–20 次模型调用计费评估要按任务粒度摊MCP server 提供方的成本回收第三方接入要么走调用配额要么走订阅分成「免费无限用」在 Agent 高频调用下不可持续给团队的账本建议上线前对典型任务跑一周调用链追踪记录每任务 token 消耗与工具调用数再倒推定价或配额。计费测算一个可落地的账本模板把「按任务粒度摊成本」落成表格式账本。以下是一个只读报表 Agent 的一周实测口径示意模板数值以你自己的追踪数据为准任务类型单任务模型调用单任务 token单任务工具调用折算成本占比简单查询2–3 次~8K1–2 次15%多步报表8–12 次~45K4–6 次45%跨源汇总15–20 次~120K8–12 次40%三个从账本里长出来的结论帕累托集中约 20% 的「跨源汇总」任务吃掉 40% 成本——优化优先级一目了然工具调用不是免费的每次调用带回的上下文会让后续轮次 token 膨胀工具返回值截断是性价比最高的优化配额设计要按任务类型分桶统一按次数限流会让「多步报表」类用户吃亏按 token 预算分桶更公平。结语三道坎对应三种角色能力暴露是服务方的安全设计鉴权是双方的信任契约计费是平台的商业模式。三道坎的次序也有讲究——先锁暴露面、再收鉴权、最后谈钱顺序反了的团队通常会在安全事件后被迫回炉重做。哪道坎你最担心评论区站个队——也欢迎说说你踩过的 MCP 接入坑。参考来源 / 信源清单站内互链10-30 Google MCP 头条文章 ID 169561062MCP 官方规范modelcontextprotocol.io成文时核验OpenAI 计费政策据公开报道存疑口径标注以官方公告为准AI 辅助生成人工核验后发布。