### What we need

When a client calls a tool **through** the LiteLLM MCP gateway, custom response metadata that the downstream MCP server attaches to its `tools/call` HTTP response needs to reach the caller. Today that metadata is dropped on the gateway hop, and there is no config or documented mechanism to preserve it.

### Environment

- `litellm v1.93.0-rc.1` - MCP python-sdk `mcp==1.26.0` (LiteLLM's pinned dependency) - Downstream MCP servers use the **streamable-HTTP** transport.

### Reproduction

1. Run a streamable-HTTP MCP server whose `tools/call` handler sets a custom HTTP response header, e.g. `X-Example-Header: hello`. 2. Register it in the LiteLLM proxy under `mcp_servers`. 3. Call the tool **directly** against that server (bypassing LiteLLM): `curl -i` shows `X-Example-Header: hello`. 4. Call the **same** tool **through** the LiteLLM MCP gateway.

### Expected vs actual

- **Expected:** the caller (or infrastructure between the gateway and the caller, e.g. an API gateway reading response headers for billing/observability) can obtain `X-Example-Header`. - **Actual:** the MCP result body returns correctly, but the custom header is gone. It is lost specifically on the L…