A developer is building an agent that calls an external deployment MCP tool. Occasionally the deployment tool returns a transient 503 Service Unavailable error. Other times it returns a 400 Bad Request indicating a permanent configuration error. The developer wants to retry transient failures but immediately escalate permanent errors without retrying. Which implementation strategy correctly handles both cases?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Error handling for agent tool calls is like a doctor's triage — a 503 is a patient who needs to wait a bit and will probably recover (retry with backoff), while a 400 is a patient whose prescription is wrong and waiting won't help (escalate immediately). The key is classifying the error first: HTTP 5xx errors are server-side and often transient; HTTP 4xx errors are client-side and usually indicate a configuration problem that retrying won't fix. Always classify before deciding to retry.
Full explanation below image
Full Explanation
Effective error handling for agent tool calls requires distinguishing between transient and permanent failures, applying different strategies to each, and ensuring the agent does not waste time retrying errors it cannot recover from.
Option A is incorrect because it applies an identical retry strategy to all errors regardless of type. Retrying a 400 Bad Request 5 times is wasteful and misleading — the request contains invalid data that will fail identically on every attempt. This pattern also delays escalation of permanent errors, which slows incident response.
Option B is correct. The standard HTTP error classification maps well to retry strategy decisions: - 5xx errors (500, 502, 503, 504) are server-side errors that may be transient — the server is overloaded, restarting, or temporarily unavailable. Exponential backoff with jitter (e.g., wait 1s, then 2s, then 4s, up to a maximum) gives the server time to recover while avoiding thundering herd problems. - 4xx errors (400, 401, 403, 404) are client-side errors indicating the request itself is wrong. Retrying won't fix a bad payload (400), an invalid token (401), or a missing resource (404). These should be immediately escalated to the appropriate error handler or human reviewer.
Option C is incorrect. Deleting a repository and re-cloning is an extreme and dangerous rollback action that could destroy uncommitted work and is disproportionate to a tool call failure. Rollback strategies for failed deployments typically involve reverting to a previous known-good state (e.g., re-deploying the previous version) — not destroying the repository.
Option D is incorrect. There is no auto_retry: true flag in the MCP server configuration specification. Error classification and retry logic are the responsibility of the agent implementation, not an automatic server-side feature.
Key pattern: classify errors by HTTP status family → 5xx = retry with backoff → 4xx = immediate escalation. This is industry-standard resilience engineering applied to agent tool calls.