MCP TypeScript @modelcontextprotocol/server 2.1.0：工具/资源请求时 OAuth scopeChallenge，默认 4 MiB 请求体上限

核心背景与行业痛点

把 MCP 服务挂到企业 OAuth 资源服务器时，仅靠连接级 bearer 校验往往过粗：同一连接上不同 tool/resource 需要不同 scope，却缺少「按请求挑战精确 scope」的一等钩子。另一方面，Streamable HTTP / createMcpHandler 若无限制地读 body，易被超大 JSON 或超长 batch 打满内存；历史实现把 JSON-RPC id 0 当 falsy，导致首个 sampling/createMessage 的 cancel 与 debounce 静默失效。Agent 网关与 IDE 侧 MCP 宿主都需要一次「权限细粒度 + DoS 边界」对齐。

架构亮点与底层机制

@modelcontextprotocol/[email protected] 经 #1624 为 tools/resources/resource templates/prompts 增加 scopeChallenge(request, authInfo)：可继续放行或返回精确 scope 集以触发 insufficient_scope；requireScopes 提供静态 all-of 辅助。createMcpHandler 与 Streamable HTTP 在 handler/SSE 之前回 HTTP 403，WWW-Authenticate 与 bearer 401/403 共用格式化器，并从 AuthInfo.resourceMetadataUrl（或 RFC 8707 resource 的 well-known）填充 resource_metadata。读 body 默认封顶 4 MiB（maxRequestBodySize / DEFAULT_MAX_REQUEST_BODY_SIZE），超限 413；batch 数组 >100 回 400/-32600。另：id 0 视为有效；禁止对 initialize 发 cancel 通知；现代 tasks 路径交叉校验 Mcp-Name 与 params.taskId。

权威 Benchmark 与实测跑分对比

本发行为协议/SDK 安全与正确性升级，没有公开延迟或吞吐榜单数字。可量化验收：未授权 scope 是否稳定收到 403/insufficient_scope；>4 MiB body 是否 413；id=0 的 cancel 是否中止 in-flight handler；initialize 超时是否不再误发 cancel。规范对照见 Authorization 与 Architecture。

开发者实战落地与开箱指南

npm i @modelcontextprotocol/[email protected]（包页：npm 2.1.0）。在注册 tool/resource 时挂 scopeChallenge 或 requireScopes；按部署调大/调小 maxRequestBodySize。手写 tasks 客户端需补 Mcp-Name。仓库与发行说明：typescript-sdk、Release。旧线 @modelcontextprotocol/[email protected] 同日带回部分 body limit backport，新旧包勿混用 API 假设。