CCA Prep

Lesson 2.2Lesson 9 of 30

Structured errors from MCP tools

Implement structured error responses for MCP tools

Structured errors from MCP toolsTool call failed — what kind?isError: true + errorCategorytransient (timeout)Retry locallyisRetryable: truevalidationFix the inputand call againbusiness ruleExplain to thecustomer orescalateisRetryable: falsepermissionDon't retry;escalateEmpty result ≠ failure: "0 records found" is a success with no data

Key points

  1. 1A tool reports failure with the MCP isError flag, so the agent knows the call failed instead of reading the error as data.
  2. 2Return errorCategory (transient, validation, business, permission), isRetryable and a human-readable description. "Operation failed" gives the agent nothing to decide with.
  3. 3Business-rule violations are not retryable; include a customer-friendly explanation the agent can pass on.
  4. 4A subagent retries transient failures itself and escalates only what it couldn't resolve, with partial results and what it tried.
  5. 5"No matching records" is a valid empty result. "Could not reach the database" is a failure. Never return one as the other.
What the exam guide checks here

Objective wording from the exam guide (English).

  • 2.2.K1MCP isError flag communicates tool failures to the agent
  • 2.2.K2Error kinds: transient, validation, business (policy), permission
  • 2.2.K3Uniform generic errors ("Operation failed") block good recovery decisions
  • 2.2.K4Retryable vs non-retryable; structured metadata prevents wasted retries
  • 2.2.S1Return errorCategory, isRetryable and a human-readable description
  • 2.2.S2Business rule violations: retriable false plus customer-friendly explanation
  • 2.2.S3Subagents recover locally from transient failures; propagate only unresolved errors with partial results and attempts
  • 2.2.S4Distinguish access failures from valid empty results

Lock it in

Answer scenario questions on this topic. Every option comes with an explanation.

Practise 2.2 · 21 questions