A company builds a complex agentic system using the Model Context Protocol (MCP). The MCP server exposes 40 tools across 6 domains. During production, the orchestrating Claude agent makes tool calls to MCP tools that return unexpected error formats — MCP tools return domain-specific error objects (e.g., {error_code: 'DB_TIMEOUT', retry_after: 30, partial_result: {...}}) but the agent treats all errors as terminal and halts the pipeline. What is the correct architectural approach for robust MCP error handling?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — you need a tool wrapper agent between Claude and the MCP server because it can classify MCP errors, run retry logic, and only pass clean results or terminal errors to Claude. Domain-specific errors like DB_TIMEOUT with retry_after need programmatic handling, not Claude reasoning about them.
Full Explanation
A tool wrapper agent between Claude and the MCP server is architecturally superior for this problem. MCP errors have domain-specific semantics that require programmatic handling — DB_TIMEOUT with retry_after is a transient error requiring timed retry, not Claude reasoning about it. The wrapper agent receives all MCP responses, classifies errors deterministically (retryable vs. fatal, complete vs. partial), handles retry loops for transient errors without involving Claude, assembles partial results when available, and surfaces only clean, complete results or unrecoverable errors to the orchestrating Claude. This keeps Claude's context window free from retry mechanics and error handling logic. The middleware standardization approach, which translates domain-specific errors to a common {is_error: true, message: 'human-readable description'} format before they reach Claude, is good for normalizing error formats but doesn't implement retry logic — Claude still needs to be instructed on when and how to retry. The system-prompt instruction approach, which tells Claude to wait for retry_after and use partial_result, requires Claude to interpret domain-specific error semantics and implement retry timing — this is unreliable (Claude may not respect retry_after accurately) and consumes context. The schema-documentation approach, which extends MCP tool schemas with detailed error handling documentation, teaches Claude about expected errors but doesn't change Claude's behavior when it encounters them — Claude still needs to generate retry tool calls, which is fragile for time-sensitive retry_after fields.