## Description

`GET /v1/mcp/server/health` returns entries with only an opaque SHA-256 hash as `server_id` and no human-readable `server_name`. There is no way to know which hash corresponds to which server without recomputing the hash manually.

## Steps to reproduce

```bash curl https://<proxy>/v1/mcp/server/health

Actual response: [ {"server_id": "a3f1bc29d74e8012...", "status": "healthy"}, {"server_id": "9e2d4c71a0f38b56...", "status": "unknown"} ]

Expected response: [ {"server_id": "a3f1bc29d74e8012...", "server_name": "github_onprem", "status": "healthy"}, {"server_id": "9e2d4c71a0f38b56...", "server_name": "cit", "status": "unknown"} ]

Root cause

server_id is generated by _generate_stable_server_id() which hashes name|url|transport|auth_type|alias with SHA-256 (first 32 chars). The health response only includes server_id — the original name is never surfaced.

File: litellm/proxy/_experimental/mcp_server/mcp_server_manager.py

Impact

- Health checks cannot be used for monitoring or alerting without reverse-engineering hashes - Operators cannot identify which server is unhealthy from the API response alone - Forces proxy-side workarounds (wrapping the…