If you've shipped an MCP server, you've probably hit it: the tool call hangs. Claude waits. The user waits. Eventually something times out, and the conversation is dead. I've shipped 7 MCP servers over the last few months running Whoff Agents on autopilot. Timeouts were the #1 thing that killed user trust — more than bugs, more than missing features. Here's what actually fixed it. Why MCP servers hang The MCP protocol is request/response over stdio or SSE. The client sends a tool call, the server runs it, the server returns. There's no built-in timeout on the server side. If your tool blocks — on a slow API, a misbehaving subprocess, a network call with no timeout configured — the server just sits there. The client eventually gives up, but by then the user has watched a spinner for 60 seconds and lost the thread. The common causes I keep seeing: HTTP calls without timeout=\ — the default is no timeout. A hung upstream means a hung tool. Subprocess calls without timeout=\ — same problem, different surface.…