2.2 — Structured Error Responses

CCAR-F Domain 2 · Task 2.2

What You Need to Know

A structured error response tells the agent the error's category, whether a retry can work, and how to recover. The MCP protocol provides the isError flag.

Two Error Layers

1. Protocol errors — JSON-RPC errors (malformed request, unknown tool, schema failure). The model never sees a tool result.
2. Tool execution errors — The tool ran but something went wrong. Returned with isError: true. The model reasons about recovery.

The Four Error Categories

Category	isRetryable	Recovery
Transient (timeouts, rate limits, unavailability)	true	Resend the same call after a delay
Validation (bad format, missing fields)	false	Correct the input, send a new call
Business (policy violations, limits)	false	Alternative path or escalate
Permission (access denied)	false	Escalate or use different credentials

isRetryable answers one narrow question: will resending this exact request work? Only transient errors get true.

Access Failure vs Valid Empty Result

• Access failure = tool could not reach the data source → may be retryable
• Valid empty result = tool queried successfully and found no matches → not an error, do not retry

Confusing the two causes wasted retries and incorrect escalations.

Error Propagation in Multi-Agent Systems

1. Subagents implement local recovery for transient failures.
2. Only propagate errors that cannot be resolved locally.
3. Include partial results and what was attempted.

Exam Traps

• Retrying when a tool returns an empty result from a successful query
• Using generic error messages without structured metadata
• Treating business errors as retryable
• Marking a validation error isRetryable: true
• Reading isRetryable: false as "abandon the task"
• Silently suppressing subagent errors by returning empty results as success