A 311 validation error should not be retried in a loop. How should the tool mark it?
Select an answer to reveal the explanation.
Short Explanation
Bad address formats aren't fixed by hammering the API. Mark validation errors non-retryable and explain them in resident-friendly language.
Full Explanation
A 311 validation error should not be retried in a loop because repeating the same invalid payload will not become valid. The tool should set isRetryable false and include a resident-friendly explanation of the validation problem so the agent stops hammering the API and can tell the resident what to correct (address format, required fields, service area).
Non-retryable validation with clear explanation works because civic intake errors are often input problems, not blips. Marking them non-retryable converts the agent from a retry loop into a guidance path that improves first-contact resolution for 311 desks.
Setting isRetryable true and omitting any explanation encourages infinite retries without teaching the resident what failed. Returning success with empty data so the agent keeps calling forever falsifies outcome and burns quota while never fixing the validation issue. Crashing the MCP process without structured fields removes recoverability and observability for the whole resident-services stack.
Exam caveat: distinguish validation/business errors (non-retryable) from transient transport failures (retryable with backoff). Operational check: submit a known-bad 311 address, assert isRetryable is false with a clear explanation, and confirm the agent surfaces the message instead of looping.