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
Error handling is triage: a 503 is a transient server problem that can recover with exponential backoff, while a 400 is a permanent client or configuration problem that won't recover no matter how long you wait. You need to classify the HTTP status first, then retry only 5xx failures and escalate 4xx failures immediately.
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.
The strategy that wraps all tool calls in a single try/catch block and retries up to 5 times with a 2-second delay regardless of the error type 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 because the request contains invalid data that will fail identically on every attempt. This pattern also delays escalation of permanent errors, which slows incident response.
The correct strategy is to implement error classification logic that checks the HTTP status code, retries with exponential backoff for 5xx errors, and immediately escalates 4xx errors without retrying. The standard HTTP error classification maps well to retry strategy decisions. 5xx errors such as 500, 502, 503, and 504 are server-side errors that may be transient because the server is overloaded, restarting, or temporarily unavailable. Exponential backoff with jitter, such as waiting 1 second, then 2 seconds, then 4 seconds, up to a maximum, gives the server time to recover while avoiding thundering herd problems. 4xx errors such as 400, 401, 403, and 404 are client-side errors indicating the request itself is wrong. Retrying won't fix a bad payload, an invalid token, or a missing resource, so these should be immediately escalated to the appropriate error handler or human reviewer.
The strategy that configures the agent to call the deployment tool only once and, if it fails, rolls back by deleting the repository and re-cloning from the remote 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, such as re-deploying the previous version, not destroying the repository.
The strategy that uses an auto_retry: true flag in the MCP server configuration to automatically classify errors and apply the appropriate retry strategy 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, retry 5xx errors with backoff, and immediately escalate 4xx errors. This is industry-standard resilience engineering applied to agent tool calls.