Make JSON-RPC ID type coercion configurable

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

Start by reviewing PR #1720 and the current JSON-RPC response ID matching implementation; the issue does not name specific files or tests. Determine where session or client configuration belongs, then verify that strict matching and lenient numeric coercion are selectable, with clear handling for mismatched response IDs and preserved backward compatibility.