A permitting MCP returns only "Operation failed" with no metadata, so the agent cannot decide retry versus explain. What should errors include?
Select an answer to reveal the explanation.
Short Explanation
"Operation failed" tells a permitting agent nothing useful. Ship structured errors—category, isRetryable, and a clear description—so it knows whether to retry or explain.
Full Explanation
When a permitting MCP returns only “Operation failed” with no metadata, the agent cannot decide whether to retry, fix inputs, escalate, or explain to the applicant. Errors should include structured metadata such as errorCategory, isRetryable, and a human-readable description so recovery policy is machine-actionable and resident communication stays clear.
Structured errors work because permitting workflows mix transient outages with durable business rules (incomplete applications, zoning conflicts). Category and retry flags let the agent branch correctly instead of guessing from a opaque failure string that wastes applicant time.
A blank body with HTTP 200 so failures look successful hides errors and can cause false progress or duplicate submissions. Only a stack trace with no agent-facing fields may help engineers but does not give the model retry or explain cues. A random emoji and no category or retry flag is non-informative theater that blocks appropriate permitting-agent decisions.
Exam caveat: human-readable text should be safe for applicant-facing paraphrase—avoid leaking internal hostnames or secrets. Operational check: inject a transient timeout versus a validation failure and confirm the agent retries only when isRetryable is true and explains when it is false.