A client built for revision 2026-07-28 also talks to a server that implements 2025-11-25. When it reads a URI that does not exist on that older server, it receives a JSON-RPC error with code -32002. How should the client interpret this error?
Select an answer to reveal the explanation.
Short Explanation
It's an old dialect for the same sentence. Older servers said "resource not found" as -32002; the new spec says -32602, but you still understand the old phrasing. The trap is deciding -32002 means nothing just because new servers stopped saying it.
Full Explanation
Revision 2026-07-28 changed the resource-not-found error from -32002 to -32602, Invalid params, to align with JSON-RPC. Servers implementing this revision must return -32602 and must not emit -32002, which stays reserved and will not be reused. For backward compatibility, the resources specification says clients should also accept -32002 as a resource-not-found error, because earlier protocol versions used that code. The error-code policy reinforces this: receivers must not assume meanings for codes in the legacy -32000 to -32019 sub-range, apart from -32002. Treating the code as meaningless discards a clear signal and would surface a confusing generic failure to the user. UnsupportedProtocolVersion handling applies to error -32022, which lists supported versions; nothing about this response indicates a version mismatch. HeaderMismatch is -32020, a transport-validation error in the range reserved for the MCP specification, not -32002. Exam caveat: the tolerance applies to clients receiving legacy codes; a server written for 2026-07-28 that still emits -32002 is non-compliant. Operational check: confirm the client's error mapper treats both -32602 on resources/read and -32002 from legacy servers as resource not found, and surfaces the same user message for each.