What should I do when an MCP fetch fails?

When an MCP fetch fails, the agent should reason about the structured error and choose between retry, fallback, or surface to the user — not silently loop. AgentFetch returns typed errors: rate_limited (retry after retry_after_seconds), timeout (retry once with longer timeout), not_found (don't retry, return to user), forbidden (don't retry, suggest auth), anti_bot_detected (fall back to browser automation), js_required (fall back to Browserless/Playwright), dns_resolution_failed (check URL spelling), ssl_error (verify the cert chain, retry with explicit cert), and content_too_large (request smaller range or summary). Good agent prompts include explicit error-handling guidance: "if fetch_url returns anti_bot_detected, try the cached version on archive.org once; if that fails, summarize what you know without fetching." For LangChain agents, the langchain-mcp-adapters wrapper propagates these errors as ToolExceptions that the ReAct loop sees and can react to. For Claude Desktop and Cursor, the error JSON is shown to the model as the tool result; well-trained models (Sonnet 4, Opus 4) handle them gracefully without prompting. Production deployments should log persistent failures with the failing URL, error type, and timestamp — patterns reveal whether you need to upgrade tier (rate_limited), switch tool (js_required), or refactor the agent (looping on not_found).