A claude_think request with tools registered none: the CLI reported tools:[] at
init with the shim still "pending", so the model had nothing to call and instead
described the calls in prose ("[Tool: list_dir]") with stop_reason=end_turn. The
turn looked successful, so this surfaced as a wrong answer rather than an error.

The CLI connects --mcp-config servers "fully async (nonblocking)" and starts the
turn without waiting, so whether any tools exist is a race between the shim's
handshake and the first API request. Marking the server alwaysLoad puts it on
the CLI's blocking path instead (its own two code paths: alwaysLoad servers are
awaited, the rest are fire-and-forget).

The race is host-dependent, which is why local testing never caught it — my box
won it every time and registered the tools. Confirmed on the box that loses it,
with identical CLI versions:

  without alwaysLoad -> tools=[],                        mcp=pending
  with    alwaysLoad -> tools=['mcp__aisbf__get_weather'], mcp=connected

Ruled out first: the shim is deployed there, both interpreters run it in ~20ms,
and it answers initialize/tools-list correctly under production's python.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>