LiteLLM MCP Gateway — bug report draft

Paste this into a new issue at https://github.com/BerriAI/litellm/issues.

Title

MCP Gateway: tools/list crashes with RuntimeError: Attempted to exit cancel scope in a different task when consuming a spec-compliant Streamable HTTP server, and schema columns drop on every container restart

Environment

• LiteLLM image: ghcr.io/berriai/litellm:main-latest (pulled 2026-05-20)
• Backend MCP server: Python mcp==1.16.0, FastMCP via streamable_http_app(), FastAPI mount, bearer auth on /mcp
• Backend MCP client used for verification: Claude Code MCP client — handshake + tools/list + tools/call all succeed cleanly against the same server

Bug 1 — RuntimeError during tools/list against Streamable HTTP server

LiteLLM's MCP client successfully completes initialize + notifications/initialized against a spec-compliant Streamable HTTP server, but the follow-up tools/list cancels with the following stack trace in the LiteLLM container logs:

RuntimeError: Attempted to exit cancel scope in a different task than it was entered in
ERROR:asyncio:an error occurred during closing of asynchronous generator <async_generator object StreamableHTTPSessionManager.run at 0x...>
BaseExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
File "/usr/lib/python3.13/site-packages/mcp/server/streamable_http_manager.py", line 117, in run
File "/usr/lib/python3.13/site-packages/mcp/server/streamable_http_manager.py", line 112, in run
    async with anyio.create_task_group() as tg:

Visible LiteLLM-side log lines:

WARNING:LiteLLM:MCP client list_tools was cancelled
WARNING:LiteLLM:Task cancelled while listing tools from gitea_mirror

The server logs (from the FastMCP-served /mcp endpoint) confirm proper protocol sequence:

Created new transport with session ID: <uuid>
POST /mcp HTTP/1.0  200 OK     (initialize)
POST /mcp HTTP/1.0  202 Accepted  (notifications/initialized)
GET  /mcp HTTP/1.0  200 OK     (SSE stream opens)
POST /mcp HTTP/1.0  401 Unauthorized   (LiteLLM re-attempt without Mcp-Session-Id)

The 401 is from the server because LiteLLM's retry doesn't carry the session ID. The root error appears to be the cancel-scope mismatch during task group teardown.

Reproduction

1. Deploy a minimal FastMCP-based Streamable HTTP server with bearer auth (e.g. https://gitea.gnumetry.com/gnumetry/mirror-helper/raw/branch/main/app.py — works against Claude Code's MCP client).
2. Register via POST /v1/mcp/server with transport=http, auth_type=bearer_token, extra_headers=["Authorization: Bearer <key>"].
3. Call GET /v1/mcp/tools or POST /mcp-rest/test/tools/list.
4. Server-side logs show successful initialize + notifications/initialized, then the cancel-scope error appears in LiteLLM logs and the response returns 0 tools.

Bug 2 — schema columns dropped on every container restart

After successfully registering MCP servers, restarting the LiteLLM container (e.g. docker service update --force) drops newly-added columns on LiteLLM_MCPServerTable because the bundled Prisma schema at /usr/lib/python3.13/site-packages/litellm_proxy_extras/schema.prisma lacks columns that the app code at /app/litellm/proxy/_types.py references:

• source_url
• approval_status
• submitted_by
• submitted_at
• reviewed_at
• review_notes

Subsequent POST /v1/mcp/server returns:

"error": "Error creating mcp server: The column LiteLLM_MCPServerTable.source_url does not exist in the current database."

Workaround used: manually ALTER TABLE "LiteLLM_MCPServerTable" ADD COLUMN IF NOT EXISTS ... after each container restart. The columns are present in /app/litellm/proxy/schema.prisma (newer) but the proxy-extras one (older) wins on startup.

Suggested fix

• Sync /usr/lib/python3.13/site-packages/litellm_proxy_extras/schema.prisma with /app/litellm/proxy/schema.prisma in the build pipeline so the bundled Prisma schema and runtime app code reference the same columns.
• For bug 1, the cancel-scope ownership issue is likely a fix in mcp_server_manager.py around how it awaits the streamable-http client lifecycle. The MCP Python SDK >=1.16 made cancel-scope handling stricter; the LiteLLM caller code may need to keep the client inside one task throughout the request lifecycle.

What works

• The same MCP server consumed via Claude Code's MCP client works perfectly: initialize, tools/list, tools/call all succeed.
• POST /v1/mcp/server registration works once the missing columns are added manually.
• Other LiteLLM endpoints (/v1/chat/completions, /v1/embeddings, etc.) are unaffected.