Two MCP servers from different vendors both answer a tools/call for a nonexistent tool with JSON-RPC error code -32602. Why is this consistency valuable?
Select an answer to reveal the explanation.
Short Explanation
Common error codes work like international road signs: you know what a stop sign means in any country. Because both servers say -32602 for an unknown tool, your client can handle it the same way everywhere. Don't confuse that protocol error with an isError tool result.
Full Explanation
MCP builds on JSON-RPC 2.0 error codes and adds a small set of its own, so implementations from different vendors report the same failure in the same way. The tools specification lists an unknown tool as a protocol error returned as a standard JSON-RPC error, and its example uses -32602, Invalid params. When every server follows this, a client can write one handling path for unknown tools instead of special-casing each vendor, which is a direct interoperability benefit. The same applies to MCP-defined codes such as -32020 HeaderMismatch, -32021 MissingRequiredClientCapability and -32022 UnsupportedProtocolVersion, which the specification reserves and requires to be used only with their defined meanings. Reading the shared code as proof of a common SDK is wrong; any conforming implementation in any language uses the same code. Treating -32602 as a temporary outage that warrants retrying the same call misreads it; invalid params means the request itself is wrong, so an identical retry will fail again. Saying -32602 reaches the model as isError output confuses the two error mechanisms: isError marks tool execution errors inside a result, while protocol errors are JSON-RPC errors that clients may or may not show to the model. Exam caveat: older servers may return -32002 for a missing resource, which clients should still accept. Operational check: call an unknown tool on each server and confirm both return a JSON-RPC error with -32602.