S45：MCP Discovery、Call、Scope 与 Audience

内容类型：预习教材（不代表已完成）
日期：2027-01-06
阶段：P2 · AI Systems Engineering 90
总路线：Day 135 / 360
周次：W7 · Protocols & Enterprise Integration
节奏：周三引导练习
状态：教材已备；学习未完成
标签：mcp、discovery、authorization、scope、audience

一句话定义

MCP 让客户端发现并调用服务器暴露的能力，但发现可见、令牌有效、scope 匹配和业务动作获准是四个不同判断。

学习目标

1. 描述 MCP 初始化、能力发现、工具调用和结果返回的基本顺序。
2. 区分 authentication、scope、audience、resource authorization 与业务审批。
3. 能观察现有 server/auth 示例的真实行为与教学边界。
4. 理解工具描述会影响模型选择，但不能承担最终安全控制。

核心知识

• Discovery 提供工具名、描述、输入 schema 等元数据。可发现只表示客户端知道能力存在，不表示当前 actor 可执行。
• Authentication 确认凭证主体；authorization 判断主体对资源能否执行动作；scope 表示授权能力范围；audience 限制 token intended recipient，防止把给服务 A 的 token 用到服务 B。
• MCP server 是资源服务器边界之一，仍需验证 issuer、audience、expiry、scope 与业务资源。客户端声明“用户已同意”不是服务端证据。
• 工具 description 与 schema 是模型决策输入，可能被错误或恶意内容影响。真正的参数验证、最小权限与副作用控制必须在服务器执行。
• Tool call 结果应区分协议错误、授权拒绝、业务冲突、依赖不可用和状态未知；否则 runtime 无法选择纠正参数、停止、重试或对账。
• Delegation 需要知道 Agent 代表谁、为了什么目的、被允许做什么、有效多久，并保留原始主体链。

机制与推导

调用链可以分为四道检查：

listTools -> visible by server/catalog policy
callTool  -> token signature/issuer/audience/expiry
          -> scope permits action class
          -> resource/business policy permits this case
          -> optional human approval before side effect

授权谓词可写为：

[ allow = tokenValid \land audienceMatch \land scopeMatch \land resourcePolicy \land purposeAllowed ]

其中任何一项失败都不应由模型自行“换个工具绕过”。高风险效果还可能返回 escalate，在人工决定前 workflow 保持等待状态。

最小练习或观察步骤

1. 只读查看 server.ts、auth.ts、toolRegistry.ts 的公开接口和验证分支。
2. 画初始化→list tools→call→auth→handler→result 的序列图。
3. 准备三个合成 token 情景：audience 错、scope 缺、token 合法但案件资源不允许。
4. 对每个情景写期望拒绝层与可记录证据，不伪造实际运行输出。
5. 找一个带副作用工具，写出为什么 schema 合法后仍需业务审批。
6. 若确实运行示例，只记录观察到的事实，并注明本地 demo 范围。

常见误区与边界

• list tools 能看到就认为可以调用。
• 只检查 scope，不检查 audience 或具体资源权限。
• 把用户 token 直接转发给所有下游，造成 confused deputy 与凭证扩散。
• 将敏感 token、参数正文写入 trace 或错误信息。
• 用 prompt 告诉模型“不要越权”替代服务器策略。
• 本地示例不能证明企业身份联邦、token rotation 或生产隔离已实现。

系统 / 金融 / Web3 场景连接

AML 分析师可具有 case:read，却未必拥有 case:escalate，且只能访问分配给自己的案件。Web3 Agent 的 wallet:simulate 与 wallet:sign 必须分开；即便 token 有签名 scope，也要检查链、合约、金额、会话授权和用户确认。

自检问题

1. discovery、authentication、authorization 与 approval 各回答什么？
2. audience 错误会阻止哪类 token misuse？
3. 为什么工具 schema 不能成为最终安全边界？
4. delegated identity 至少要保留哪些信息？

专业课程对齐

• 阅读 Model Context Protocol 官方文档 的 lifecycle、tools 与 authorization 内容，具体对照初始化、发现、调用和资源服务器验证顺序。
• 阅读 OpenAPI Specification 的 Security Scheme 与 Operation security 章节，比较 API 契约怎样声明授权要求、运行时为何仍需真正验证。
• 阅读 A2A Protocol 官方文档 的 Agent discovery 与任务安全相关说明，观察跨 Agent 委派比单工具调用多出的身份与任务边界。

深入学习提示

阅读时画两条链：协议消息链和身份委托链。每一步标 token 面向谁、允许什么、能否下传。再用“合法 token 访问错误案件”的反例检验资源级策略。不要扩大为真实身份供应商集成；先把四种授权判断说清。

学后填写区

• 实际查看或运行的范围：
• 协议调用序列：
• 三种拒绝情景：
• Demo 与生产能力边界：
• 尚未理解的问题：