@modelcontextprotocol/express@2.0.1
MCP TypeScript SDK 发布 @modelcontextprotocol/express@2.0.1 补丁版本,为 Streamable HTTP 请求体读取引入默认 4 MiB 大小限制。涉及 WebStandardStreamableHTTPServerTransport、Node transport、createMcpHandler、toNodeHandler 与 createMcpHonoApp 的 JSON 预解析,超限在解析前返回 413 Payload Too Large。toWebRequest 超限时抛出名为 RequestBodyTooLargeError、status 为 413 的错误。JSON-RPC 批量数组上限 100 条,超长批次返回 400 / -32600 且不派发。限制可通过 maxRequestBodySize 选项配置,默认常量 DEFAULT_MAX_REQUEST_BODY_SIZE = 4 MiB 从 @modelcontextprotocol/server 导出。
Development
- First Report@modelcontextprotocol/express@2.0.1MCP TypeScript SDK Releases
- Current AssessmentMCP 生态正从「能连通」走向「可运维」,默认请求体上限与批量条数上限是服务端防护的常规动作,说明该协议开始被当作生产入口而非演示接口。对托管 MCP 服务的厂商,这类默认值会改变容量规划与错误码约定;对客户端实现者,批量语义被收紧意味着需要适配分片调用。可验证的下一信号是其他语言 SDK 是否跟进同一默认值与错误命名。Agent Pulse · analysis
MCP TypeScript SDK 的 Express 适配包发布 2.0.1 补丁,核心变化是给 Streamable HTTP 请求体读取加上默认 4 MiB 上限。SDK 自有的所有请求体读取路径——WebStandardStreamableHTTPServerTransport 及其上的 Node transport、createMcpHandler、toNodeHandler、createMcpHonoApp 的 JSON 预解析——都会在解析前停止并返回 413 Payload Too Large;该限制与旧版 SSE transport 已使用的限制一致,Express 适配器与 stdio 也约束了读取。toWebRequest 自行读取 Node 流时,超限会以 name 为 RequestBodyTooLargeError、status 为 413 的错误拒绝,toNodeHandler 将其转为 413;手工调用 toWebRequest 的代码需处理该拒绝或传入已解析的 body,isLegacyRequest 会把这类请求判为非 legacy 交由现代 handler 处理。JSON-RPC 批量数组限制为 100 条消息,更长批次返回 400 / -32600 且不派发任何一条。限制可通过新增 maxRequestBodySize 选项(字节,默认 DEFAULT_MAX_REQUEST_BODY_SIZE = 4 MiB,从 @modelcontextprotocol/server 导出)配置。
这是把资源边界从「调用方自觉」改为「传输层默认拒绝」的改动:限制发生在解析之前,因此超限请求不会消耗 JSON 解析与对象分配成本,属于典型的早期拒绝设计。对自建 HTTP 入口的集成方,需要确认是否依赖超过 4 MiB 的请求体,以及手工调用 toWebRequest 时是否捕获 RequestBodyTooLargeError;批量上限 100 条则要求客户端把大批量拆分为多次调用。可验证的下一信号是官方文档或后续版本是否给出 maxRequestBodySize 的推荐取值与流式上传替代方案。
MCP 生态正从「能连通」走向「可运维」,默认请求体上限与批量条数上限是服务端防护的常规动作,说明该协议开始被当作生产入口而非演示接口。对托管 MCP 服务的厂商,这类默认值会改变容量规划与错误码约定;对客户端实现者,批量语义被收紧意味着需要适配分片调用。可验证的下一信号是其他语言 SDK 是否跟进同一默认值与错误命名。
对运行 MCP 服务端的团队,默认上限降低了单请求内存放大与解析开销带来的稳定性风险,减少为防护而自写的中间件;代价是既有大请求体调用可能开始收到 413,需要在升级前做兼容性排查。对客户端与平台方,批量 100 条上限会影响调用编排逻辑,需评估拆分成本。可验证的下一信号是升级后 413 与 400 错误率的变化,以及是否有团队因此调整请求分片策略。
若各语言 SDK 逐步对齐 4 MiB 默认值与 413 语义,MCP 服务端的请求体防护会趋于统一,客户端库需要内建分片与错误处理。反之,若默认值在后续版本被调整或按传输方式分化,集成方仍需显式配置。可验证的下一信号是后续 release note 是否出现该默认值的变更或新增相关配置项。