The connection turns green. The client says it's connected. And then the tool list is empty — the agent has nothing to call, the palette is blank, and nothing you wrote is reachable. This is one of the most disorienting MCP failures precisely because it doesn't look like a failure. A refused connection or a 401 at least tells you where to look. An empty tool list says everything worked, which is the one thing that isn't true.
It's worth being precise about what this state actually is. The transport connected, the initialize handshake completed and parsed, and the client asked the server what it can do — and the answer was "nothing," or close to it. That is a different bug from a server that never finishes initialize and a different bug from a server sitting behind auth. Here the handshake is healthy; the tool inventory is empty or unreadable. The fix is almost never "restart it," and it's rarely on the client. It's usually one specific thing the server did or didn't say.
An Empty Tool List Is a Successful Response
Start from the reframing, because it changes where you look. When a client shows no tools, it has almost always received a perfectly valid tools/list response — one whose tools array happens to be empty, or whose entries the client discarded. The server said "here are my tools: none." That is a 200. Nothing in the transport or the protocol is broken. So the debugging question is not "why did the request fail," it's "why is the correct answer empty — and is that empty coming from the server, or from the client throwing entries away?"
