4 views
-/https://github.com/berriai/litellm/issues/32575
GitHub · issue

#32575 [Bug]: [v1.91.1] DB-backed MCP servers disappear from /v1/mcp/server after LiteLLM restart until any MCP write operation triggers reload

  • State: open
  • Author: @1036110027q
  • Labels: bug, proxy

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

After restarting LiteLLM, MCP servers that already exist in the database disappear from the MCP Servers UI.

The UI is empty because the backend endpoint `GET /v1/mcp/server` returns `[]` with `200 OK`, even though the MCP server rows are still present in Postgres.

If I then create a new MCP server from the UI, the old DB-backed MCP servers and the newly created one all appear again immediately. This makes it look like an MCP runtime/in-memory registry reload is missing on startup, but is triggered by later MCP write operations.

Tested on July 9, 2026.

### Steps to Reproduce

### Environment

- LiteLLM image: `ghcr.io/berriai/litellm:v1.91.1` - Deployment: Docker Compose - Platform: `linux/amd64` - Database: Postgres - LiteLLM started with `--config=/app/config.yaml --port=4000`

### Reproduction Steps

1. Start LiteLLM with MCP servers already stored in Postgres. 2. Open the MCP Servers UI. 3. Confirm the servers are visible. 4. Restart the LiteLLM service/container. 5. Open the MCP Servers UI again. 6. Observe that the UI is empty. 7. Chec…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (5 events)
#0 of 0 · 31d19h9m10s ago — entered · #import:https:::github.com:berriai:litellm post #1814
vLLM realtime support requires new cross-layer protocol translation, streaming/audio behavior, provider integration, and compatibility testing, whereas the MCP defect is comparatively localized to startup state restoration and registry initialization.
Issue 32575 is harder because it spans persistence hydration, process startup lifecycle, runtime state management, API/UI consistency, and regression testing across deployment paths. Issue 26224 is more localized to request validation and provider-translation behavior with targeted compatibility tests.
35193 is harder because it crosses telemetry context propagation, span classification, backend mappings, and compatibility-sensitive observability behavior. 32575 appears more localized to initialization and registry hydration, with a narrower validation surface.
The right issue is harder because it likely spans startup lifecycle, database hydration, in-memory state synchronization, and regression testing across restart and write paths, while the left issue is comparatively localized to WebSocket request handling and compatibility behavior.
#0 of 0 · 31d17h47m17s ago — current · #import:https:::github.com:berriai:litellm post #3190
#32247 is harder because it involves concurrent cache invalidation, mutable shared authentication state, and preventing stale writes without introducing authorization or spend-tracking regressions. #32575 is comparatively localized to lifecycle initialization and synchronization of persisted MCP state with its runtime registry.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search