modelcontextprotocol / modelcontextprotocol/python-sdk
Make JSON-RPC ID type coercion configurable
还没有人认领这个 Issue。
- 主要语言
- Python
- 星标
- 24.3k
- 派生
- 4k
- 平均合并
- 1 天 1 小时
- 30 天内合并 PR
- 31
描述
Background
PR #1720 added automatic type coercion for JSON-RPC response IDs, allowing string IDs like "0" to match integer request IDs like 0. This makes the client more tolerant of servers that echo back IDs in a different but semantically equivalent format.
Spec Language
Per the JSON-RPC 2.0 and MCP specifications, response IDs should be exact matches:
JSON-RPC 2.0: Response ID "MUST be the same as the value of the id member in the Request Object"
MCP Spec:
- Result responses "MUST include the same ID as the request they correspond to"
- Error responses "MUST include the same ID as the request they correspond to"
The language "same as the value" / "same ID" implies exact matching including type. The spec does not describe IDs as opaque and does not mandate type conversion or normalization. Servers should echo back the exact ID they received.
Current Behavior
PR #1720 makes the client more lenient by accepting type-coerced IDs (e.g., "0" matching 0). This is a workaround for non-compliant servers.
Proposal
Make this ID type coercion behavior configurable:
- Strict mode: Require exact type matching (spec-compliant behavior)
- Lenient mode: Allow type coercion between numeric strings and integers (current behavior after #1720)
This could be exposed as a session or client configuration option, defaulting to lenient for backwards compatibility.
Ideally strict mode is default, with an error message being clear as to why something fails. If we receive a response with an ID that's a string, even though the original request ID was an int we could first check if there are any IDs which would match after type coercion and then include that in the error message. "Request ID with same value of different type found, but ignored due to strict ID matching configuration".
Reasoning
By spec language, request ID 1 and request ID "1" are different IDs, but with this type coercion they are treated as the same. Given that many clients/servers are non-compliant with this anyway and do their own type conversions we should allow server/client users of the SDK to configure the behaviour for themselves.
Related
- #1720 - Fix JSON-RPC error response ID matching
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
首先检查 PR #1720 以及当前的 JSON-RPC 响应 ID 匹配实现;该 issue 未指定具体的文件或测试。确定 session 或 client 配置应放置在哪里,然后验证严格匹配和宽松的数值强制转换是否可选,并确保对不匹配的响应 ID 有明确的处理,同时保留向后兼容性。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- python
- 领域
- api, backend-api-design
- Issue 类型
- 功能
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 45/100