A network blip takes out two MCP servers at once: a hosted one reached over HTTP and a local one started as a process on your machine. A few seconds later the hosted server is working again and the local one is still gone. A colleague concludes the local server is unreliable and suggests raising its timeout. What is really going on?

The principle — When two things fail together and only one comes back, the useful question is what differs between them structurally, not which one is better behaved.

Why the key is correct — If an HTTP or SSE server disconnects mid-session, Claude Code automatically reconnects with exponential backoff, up to five attempts starting at a one-second delay and doubling each time. Stdio servers are local processes and are not reconnected automatically. The hosted server therefore healed itself while the blip was still passing, and the local one was never going to, because nothing was ever going to try. The asymmetry is designed, and it says nothing at all about the quality of either server.

Why the others are wrong — Load explains slow recovery rather than absent recovery, and this server has not come back at all, so the two are not the same symptom being described more or less charitably. Identical configuration is beside the point, because reconnection is a property of the transport rather than something either entry declares. And a timeout bounds how long a call may run; it has no bearing on whether a process that has exited is started again.

Remember this — Ask which transport a server uses before you judge how it recovered. Two servers can be configured identically, fail identically, and still behave completely differently afterwards, and the only thing that predicts which is whether the process runs on your machine or somewhere else.

Sources — Anthropic's Claude Code MCP reference.