Make the CLI wait for the MCP tool shim; bump to 0.99.87
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>
Showing
Please
register
or
sign in
to comment