Issue Station
Sign In
Tools hereToolbox

litellm - 💡(How to fix) Fix [Bug] /key/update fails with 403 when a previously-assigned MCP server has been deleted

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

handle_update_object_permission_common in litellm/proxy/management_helpers/object_permission_utils.py does a plain dict.update to merge the stored mcp_servers list with the incoming request data, then writes the merged result back via upsert. If the DB record contains the UUID of a server that was deleted from LiteLLM_MCPServerTable, that UUID is never cleaned out. The re-validation step on every subsequent /key/update call produces the 403.

The same applies to server UUIDs stored as keys in mcp_tool_permissions.

Fix Action

Fix

Branch fix/stale-mcp-server-key-update in fork https://github.com/sumirjha/litellm.

Files:

  • litellm/proxy/management_helpers/object_permission_utils.py — prune orphaned server IDs on upsert
  • tests/test_litellm/proxy/management_helpers/test_object_permission_utils.py — regression tests

Code Example

403 Forbidden — "Key is not in a team / allowed servers"
RAW_BUFFERClick to expand / collapse

Bug description

POST /key/update on any key whose object_permission row contains a stale reference to a deleted MCP server fails with:

403 Forbidden — "Key is not in a team / allowed servers"

Root cause

handle_update_object_permission_common in litellm/proxy/management_helpers/object_permission_utils.py does a plain dict.update to merge the stored mcp_servers list with the incoming request data, then writes the merged result back via upsert. If the DB record contains the UUID of a server that was deleted from LiteLLM_MCPServerTable, that UUID is never cleaned out. The re-validation step on every subsequent /key/update call produces the 403.

The same applies to server UUIDs stored as keys in mcp_tool_permissions.

Steps to reproduce

  1. Register an MCP server — note its UUID.
  2. Assign it to a key via object_permission.mcp_servers.
  3. Delete the MCP server from the LiteLLM database.
  4. Call POST /key/update with any field change.
  5. Observe: 403 — Key is not in a team / allowed servers.

Fix

Branch fix/stale-mcp-server-key-update in fork https://github.com/sumirjha/litellm.

Files:

  • litellm/proxy/management_helpers/object_permission_utils.py — prune orphaned server IDs on upsert
  • tests/test_litellm/proxy/management_helpers/test_object_permission_utils.py — regression tests

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - 💡(How to fix) Fix [Bug] /key/update fails with 403 when a previously-assigned MCP server has been deleted