mcp: ReadResource caches the result of a multi round-trip retry and serves a retry request from the cache

Finding: According to an external report (not reproduced by KFA), in modelcontextprotocol/go-sdk v1.8.0 and main at 3c08147 (reported 2026-10-09), ClientSession.ReadResource on a 2026-07-28 session mishandles its per-URI cache when multi round-trip requests (SEP-2322) are involved [https://github.com/modelcontextprotocol/go-sdk/issues/1369]. Reported symptoms: (1) The multi round-trip middleware runs inside handleSend, so the result of the retry that carried inputResponses and requestState is stored in the cache under the plain URI. A resource gated behind an elicitation is then served from cache on the next read without asking the user again. In the reporter's in-memory repro, both reads returned contents with handlerCalls=2 and elicitations=1; the second read returned the same result pointer as the first. The expected result is handlerCalls=4 and elicitations=2. (2) The cache lookup happens before sending and is keyed by URI only. With MultiRoundTrip disabled, a manual retry using the same URI plus InputResponses and RequestState is answered from cache with the first interim input_required result (NeedsInput() true, empty Contents), and the retry never reaches the server. Spec context quoted by the reporter: results from retries carrying inputResponses or requestState must not be cached, and interim input_required results are not cacheable. Per the reporter, the expected behavior is that requests carrying InputResponses or RequestState bypass the cache, neither interim nor retry results are stored, and ordinary results that needed no input are still cached [same issue]. Reporter's suspected root cause: ReadResource at mcp/client.go:1388-1407 looks up and stores by URI without considering InputResponses, RequestState, NeedsInput() or whether the middleware retried. This is the reporter's analysis; no maintainer confirmation was supplied. Practical implication: where a resource's content depends on elicited user input, it may be wrongly reused from cache on a 2026-07-28 session. Treat this as a possible correctness and privacy concern for gated resources. The report gives no workaround, and none is established here. Status: the issue is open. The reporter says a fix with regression tests (TestMultiRoundTrip_ReadResource_RetryResultNotCached and ..._ManualRetryBypassesCache) is ready and a PR will follow, but no PR, merged commit or release was supplied. Do not assume any released version fixes this. Limitation: this is a single self-reported source, not reproduced by KFA, and comments may be incomplete.