MCP server tools not indexed by tool discovery despite server showing "Connected"

Summary
An MCP server (stdio transport) shows as ✔ Connected in claude mcp list, but its tools never appear via the model's tool search/discovery — in both a long-running session and a fresh new session. The server itself is healthy and responds correctly to a manual tools/list call when the same JSON-RPC traffic is piped directly into the same script over stdio, outside of Claude Code.

Steps to reproduce

1. Register a stdio MCP server that proxies to a remote HTTP MCP endpoint (in our case, a Python bridge signing requests with AWS SigV4 and forwarding to a remote MCP server over HTTPS).
2. claude mcp add <name> -- <command>, confirm claude mcp list shows ✔ Connected.
3. Ask Claude to use a tool from that server. Tool search finds nothing for it — not even an exact-name lookup for the known tool names (e.g. mcp__<name>__<toolName>).
4. Independently verify the server itself works: pipe initialize followed by tools/list JSON-RPC requests directly into the bridge script's stdin (bypassing Claude Code) — it returns a correct tools/list result with full schemas on the first try.
5. Start a brand-new Claude Code conversation in the same project — same result: claude mcp list shows Connected, but tool discovery still returns nothing for that server.

Expected
If claude mcp list reports a server as Connected, its tools should be discoverable by the model (or the status should reflect that tool cataloging failed, e.g. "Connected, 0 tools" / a distinct error state).

Actual
Server shows "Connected" with an empty/never-populated tool catalog, with no way from inside the session to force a re-fetch of tools/list, and no diagnostic signal explaining that this is what happened (as opposed to a throttled/failed request, which is a separate, distinguishable failure mode we also hit and worked around with retries).

Environment

• Claude Code CLI, Linux (WSL2), Ubuntu 26.04
• MCP transport: stdio, wrapping a Python script that forwards to a remote HTTPS MCP endpoint
• Server: custom bridge script (not a public/well-known MCP server)

Impact
Makes it impossible to rely on claude mcp list's "Connected" status as a signal that a server's tools are actually usable, and provides no in-session recovery path other than falling back to shelling out to the underlying client library directly (bypassing MCP tool discovery entirely).