fetch: no retry/backoff on transient 429/5xx or network errors

Bug: fetch MCP server has no retry or backoff on transient 429/5xx errors

Problem

The fetch MCP server (src/fetch/) proxies HTTP requests on behalf of agents. When the target URL returns a transient error — 429 Too Many Requests, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout — the server returns the error immediately to the agent with no retry.

Agents (Claude Code, Kilo Code, OpenCode) that call fetch for documentation lookups, API calls, or web scraping then receive an error result and either halt or waste a full LLM turn handling the error, when a 1-2 second retry would have succeeded.

Expected behavior

For idempotent fetches (GET, HEAD), the fetch server should retry transient errors with exponential backoff:

• Retryable: 429, 500, 502, 503, 504, and network errors (ECONNRESET, ETIMEDOUT, ENOTFOUND with a short TTL)
• Non-retryable: 400, 401, 403, 404, 405, 409, 410, 422
• Default retry policy: 3 attempts, initial delay 1s, backoff factor 2x, max delay 10s
• Configurable via env: FETCH_MAX_RETRIES, FETCH_RETRY_DELAY_MS
• Respect Retry-After header when present on 429 responses

POST/PUT/DELETE should NOT be retried by default (not idempotent); opt-in via config.

Why

Transient errors are the norm for public APIs and documentation sites under load. A retry layer in the MCP server is more efficient than having every agent implement its own retry logic, and it keeps agent prompts clean (agents describe what they need, not how to handle HTTP transience).

Environment

• MCP servers: @modelcontextprotocol/server-fetch (latest)
• Runtime: Node.js v24.18.0, Windows 11 Enterprise
• Use case: agents fetching npm docs, GitHub raw content, and public APIs through fetch MCP tool

Start by reading the fetch MCP server implementation under src/fetch/ and trace how HTTP status and network errors become tool results. Define the retry policy for idempotent methods, environment configuration, exponential delays, and Retry-After handling; done means transient failures follow the stated policy while non-idempotent methods and non-retryable statuses do not retry by default.