The mechanism
JSON-RPC gives a request a method, parameters and an ID. A response correlates to that ID and contains either a result or an error. A notification has no ID and does not receive a response. These shapes describe messaging, not whether a business operation achieved the user’s goal.
Modern MCP ordinary results carry resultType: "complete". A tool may finish normally at the protocol layer while reporting isError: true in its tool result. An unknown method is a protocol error; an incident lookup that reaches its backend and cannot find an authorized record needs a deliberate application result.
Choose error semantics before adding retries. “Malformed identifier” should not trigger the same action as “temporary backend unavailable”. A timeout has yet another meaning: the caller may not know whether the effect occurred.
Worked example
The response below is a tool-result fixture, with a completed operation that reports a controlled failure. It contains no stack trace or private database detail. The client can ask for a corrected identifier rather than retrying the same malformed request. The text and structured value should agree.
{"jsonrpc":"2.0","id":2,"result":{
"resultType":"complete","isError":true,
"content":[{"type":"text","text":"Expected an incident ID such as INC-104."}],
"structuredContent":{"error":"invalid_incident_id","retryable":false}
}}Practice: predict, inspect, explain
Offline exercise. Make a four-row decision table: unknown method, malformed incident ID, unavailable backend, and a response lost after a write. For each, name the layer that detects it, what the user should see and whether retrying is safe. Use a fresh JSON-RPC ID for a new attempt but retain the same business idempotency key when retrying one intended write.
Expected observation: the correlation ID and business-operation key solve different problems. A completed RPC can still represent an unsuccessful tool, while a failed network exchange can hide a completed external effect.
Troubleshooting and trade-offs
If every exception becomes an empty object, clients lose the distinction between no data and service failure. If exceptions leak raw traces, callers gain implementation details they do not need. Define stable, minimal error categories and attach restricted diagnostic correlation separately. Do not reserve arbitrary application errors inside JSON-RPC’s reserved error-code range.
Interview practice
Does resultType complete mean success?
It means the protocol operation has produced its final result. Inspect the tool’s error indicator and application fields to determine the business outcome.
Why not retry every timeout?
The response may have been lost after execution. Reconcile the destination or use a service-enforced idempotency key; a fresh transport request does not make the original write disappear.
Completion check
Classify the four failure cases and justify each retry decision without relying only on an HTTP status.
Sources and version notes
This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.