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?

A tool wrapper agent implementing error classification and retry logic 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: (1) receives all MCP responses, (2) classifies errors deterministically (retryable vs. fatal, complete vs. partial), (3) handles retry loops for transient errors without involving Claude, (4) assembles partial results when available, (5) 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. Option A (middleware standardization) is good for normalizing error formats but doesn't implement retry logic — Claude still needs to be instructed on when and how to retry. Option B (system prompt instructions) 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. Option D (error documentation in schemas) 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.