Make JSON-RPC ID type coercion configurable

首先检查 PR #1720 以及当前的 JSON-RPC 响应 ID 匹配实现；该 issue 未指定具体的文件或测试。确定 session 或 client 配置应放置在哪里，然后验证严格匹配和宽松的数值强制转换是否可选，并确保对不匹配的响应 ID 有明确的处理，同时保留向后兼容性。

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