stdio MCP server tools not loaded into session despite "Connected" status (still occurring in 2.1.209, see #51736)

Environment: Claude Code 2.1.209, Windows 10

Server config: user-scope stdio MCP server, added via claude mcp add <name> -s user -e ... -- uvx workspace-mcp --single-user --tool-tier core (this is taylorwilsdon/google_workspace_mcp, self-hosted for Gmail/Calendar/Drive/etc).

Symptom:

• claude mcp list and claude mcp get <name> both report ✔ Connected consistently.
• The server's own debug log confirms it resolves all 45 tools and responds to a ListToolsRequest on every session start/reconnect.
• Despite this, the tools never appear in the live session's tool registry — verified via repeated tool-discovery queries (including exact known tool names like search_gmail_messages, list_gmail_labels), which return zero matches every time.

Contrast: In the same session, multiple HTTP-transport MCP servers (Notion, Canva, Miro, Airtable, GitHub — all claude mcp add --transport http) load their tools into the registry without any issue. Only the stdio-transport server fails to surface tools, despite being the only one proven healthy at the process/protocol level (log-confirmed tools/list response).

Steps tried, no effect on any of them:

1. /mcp → select the server → reconnect
2. Full Claude Code app restart
3. claude mcp remove <name> -s user, then re-add from scratch with identical config
4. Another full restart
5. claude update (2.1.208 → 2.1.209), then a third full restart

Related issue: #51736 ("Custom MCP server tools not discovered after update to 2.1.116") reports what looks like the identical pattern — stdio server shows Connected, direct protocol probing confirms tools/list works, but tool-search/discovery finds nothing — and was closed not_planned. Filing this as a fresh report since it's still reproducible on a current version (2.1.209), in case it was never actually root-caused, or regressed again.

Expected: A stdio MCP server that successfully completes its handshake and responds to tools/list (as confirmed in its own logs) should have those tools available for discovery/use in the session, consistent with how HTTP-transport servers behave.