## What

When the proxy lists tools for an MCP egress server that resolves its upstream credential from the caller's identity (the per-user OBO grants: `oauth2_id_jag`, and `oauth2_token_exchange` when no machine fallback is configured), the tool list comes back empty, so the client never discovers the tools and a subsequent `tools/call` is rejected with "tool not found" before the credential exchange ever runs. The server is effectively unusable end to end through the proxy MCP gateway.

## Why

The tool-listing path (`MCPServerManager._get_tools_from_server` in `litellm/proxy/_experimental/mcp_server/mcp_server_manager.py`) calls `_create_mcp_client` without a `subject_token`, by long-standing design ("tool listing must not be blocked by missing per-user env vars"). The tool-call path (`_call_regular_mcp_tool`) does extract the caller's bearer and thread it through. For an `oauth2_id_jag` server there is no static credential to fall back on, so listing fails closed (the resolver returns `precondition_required`), `get_tools` swallows it and returns `[]`, the registry stays empty, and the call is then refused against that empty registry.

This is not introduced by the v2-native ID-…