@modelcontextprotocol/node@2.1.0
MCP TypeScript SDK 发布 @modelcontextprotocol/node@2.1.0，新增请求级 OAuth scope 挑战：tools、resources、resource templates、prompts 的 scopeChallenge 回调接收解析后的请求与已验证认证信息，可继续执行或返回 insufficient_scope 所需 scope 集合；requireScopes 提供静态 all-of 检查辅助。createMcpHandler 与 Streamable HTTP 传输会在处理器执行或 SSE 建立前返回 HTTP 403 与 insufficient_scope 挑战。该预检在注册原语带 scopeChallenge 回调时自动生效，无处理器或传输层配置开关。WWW-Authenticate 头由与 bearer-auth 401/403 相同的格式化器生成，resource_metadata 参数来自已验证 AuthInfo；requireBearerAuth / verifyBearerToken 现将配置的 resourceMetadataUrl 写入返回的 AuthInfo（新增可选字段），否则回退到 HTTP(S) RFC 8707 资源标识的 well-known 位置，两者都不可用时省略该参数。
发展脉络
- 首次出现@modelcontextprotocol/node@2.1.0MCP TypeScript SDK Releases
- 当前判断MCP 生态正从「能连上」走向「按原语最小授权」，这对多租户 Agent 平台与企业内工具网关是必要能力。把 scope 挑战标准化到协议层，可能减少各家自建授权中间件的碎片化，但也意味着服务端实现需与 SDK 版本对齐。可验证下一信号：主流 MCP 服务端与托管平台是否声明支持 insufficient_scope 挑战与 resource_metadata 发现。Agent Pulse · 分析
MCP TypeScript SDK 的 @modelcontextprotocol/node@2.1.0 把 OAuth 授权粒度下沉到单个原语：每个 tool、resource、resource template、prompt 可注册 scopeChallenge 回调，在请求解析与认证校验后决定放行或返回精确的 insufficient_scope scope 集合，requireScopes 覆盖静态 all-of 场景。createMcpHandler 与 Streamable HTTP 传输在进入处理器或建立 SSE 之前即返回 HTTP 403 挑战，且该预检随注册原语自动启用，无需处理器或传输层配置。挑战头复用 bearer-auth 401/403 的格式化器，resource_metadata 由 AuthInfo 携带的 resourceMetadataUrl 或 RFC 8707 资源标识的 well-known 回退推导。
这是把授权决策从传输层前移到原语注册层的设计：scope 检查与具体 tool/resource 绑定，403 在 handler 执行和 SSE 建立之前返回，避免未授权请求占用执行资源。resource_metadata 与 AuthInfo 绑定，使客户端能按 RFC 8707 资源标识发现授权服务器元数据。可验证下一信号：SDK 是否补充 scopeChallenge 的测试用例与文档示例，以及 Python/其他语言 SDK 是否跟进同一语义。
MCP 生态正从「能连上」走向「按原语最小授权」，这对多租户 Agent 平台与企业内工具网关是必要能力。把 scope 挑战标准化到协议层，可能减少各家自建授权中间件的碎片化，但也意味着服务端实现需与 SDK 版本对齐。可验证下一信号：主流 MCP 服务端与托管平台是否声明支持 insufficient_scope 挑战与 resource_metadata 发现。
对提供 MCP 工具网关或 Agent 平台的一方，原语级 scope 挑战降低了越权调用与无效执行成本，并让授权失败对客户端可编程处理，减少人工排查。价值兑现取决于客户端能否正确解析 WWW-Authenticate 与 resource_metadata 并完成再授权流程。
若该模式被其他语言 SDK 采纳，MCP 的授权语义可能趋于统一，客户端可基于 403 挑战自动完成增量授权。需观察是否出现跨 SDK 一致性测试或规范文本更新，否则各实现仍可能分叉。