Issue Station
Sign In
Tools hereToolbox

litellm - 💡(How to fix) Fix [Bug]: Multiple MCP integration issues: tool registry lookup, OpenAPI spec_path fallback, and MCPServerTable diagnostics [1 participants]

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…
GitHub stats
BerriAI/litellm#23348•Fetched 2026-04-08 00:37:17
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
stiven-duquestiven-duque
Participants
stiven-duquestiven-duque
Timeline (top)
labeled ×2cross-referenced ×1

Error Message

  1. Double-prefix error in MCP tool registry lookup Error message: "OpenAPI tool ... not found in registry"
  2. Double-prefix error in MCP tool registry lookup No specific error log, but the UI fails to display available tools for the server.

Code Example

OpenAPI tool catfacts_mcp-getrandomfact not found in registry
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

While integrating and using MCP features in litellm, we have encountered three issues that impact usability and robustness:

  1. Double-prefix error in MCP tool registry lookup Problem: When requesting a tool from the MCP registry, the code always prefixes the tool name with the server name. However, sometimes the tool name is already prefixed (for example, when called from the MCP inspector UI). This causes the lookup to fail, as the registry searches for a double-prefixed name that does not exist. Impact: Tools registered with a single prefix cannot be found if the request already includes the prefix. Error message: "OpenAPI tool ... not found in registry"

  2. OpenAPI tool preview fails if spec_path is missing in the request Problem: When adding or editing an MCP server via the UI, sometimes the request sent to the backend does not include the spec_path (the path to the OpenAPI spec), but does include the server_id. The backend currently only checks for spec_path in the request, so if it is missing, the preview of available tools does not work. Impact: The UI does not show any tools for preview if spec_path is missing, even though the server is already registered and has a spec_path stored. This is especially common when editing a server from the UI, due to how the frontend sends the data.

  3. MCPServerTable does not include spec_path, making diagnostics harder Problem: The MCPServerTable structure, used for diagnostics and UI display, does not include the spec_path field. This makes it difficult to debug or inspect which OpenAPI spec is associated with each server. Impact: When inspecting the table, there is no way to see the spec_path for each server. This complicates troubleshooting and support.

Steps to Reproduce

  1. Double-prefix error in MCP tool registry lookup Steps to reproduce: Register a tool in MCP with a single-prefixed name (e.g., catfacts_mcp-getrandomfact). Trigger a request from the MCP inspector UI or another source that sends a tool_name already prefixed (e.g., catfacts_mcp-getrandomfact). Observe that the backend tries to look up catfacts_mcp-catfacts_mcp-getrandomfact and fails. Log example: OpenAPI tool catfacts_mcp-getrandomfact not found in registry

  2. OpenAPI tool preview fails if spec_path is missing in the request Steps to reproduce: Register an MCP server with a valid spec_path. Edit the server via the UI; the request sent to the backend may not include spec_path, but does include server_id. Try to preview tools for that server in the UI. Notice that no tools are shown, even though the server has a spec_path stored. Log example: No specific error log, but the UI fails to display available tools for the server.

  3. MCPServerTable does not include spec_path, making diagnostics harder Steps to reproduce: Inspect the MCPServerTable output (e.g., via API or UI). Look for the spec_path field for each server. Notice that spec_path is missing, making it hard to know which OpenAPI spec is associated with each server.

Relevant log output

OpenAPI tool catfacts_mcp-getrandomfact not found in registry

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

v1.81.14

Twitter / LinkedIn details

No response

extent analysis

Fix Plan

To address the issues, we will implement the following fixes:

Double-prefix error in MCP tool registry lookup

  • Check if the tool name is already prefixed before adding the server name prefix
  • Use a conditional statement to handle both cases

Example code:

def get_tool_from_registry(tool_name, server_name):
    if tool_name.startswith(server_name):
        # Tool name is already prefixed, use as is
        lookup_name = tool_name
    else:
        # Tool name is not prefixed, add server name prefix
        lookup_name = f"{server_name}_{tool_name}"
    # Perform registry lookup using the constructed lookup name
    return registry_lookup(lookup_name)

OpenAPI tool preview fails if spec_path is missing in the request

  • Modify the backend to check for both spec_path and server_id in the request
  • If spec_path is missing, retrieve it from the stored server information using server_id

Example code:

def get_tool_preview(request):
    if 'spec_path' in request:
        spec_path = request['spec_path']
    elif 'server_id' in request:
        # Retrieve spec_path from stored server information
        server_info = get_server_info(request['server_id'])
        spec_path = server_info['spec_path']
    else:
        # Handle error case where neither spec_path nor server_id is provided
        return error_response
    # Perform tool preview using the retrieved spec_path
    return tool_preview(spec_path)

MCPServerTable does not include spec_path, making diagnostics harder

  • Modify the MCPServerTable structure to include the spec_path field
  • Update the code that generates the MCPServerTable output to include the spec_path field

Example code:

class MCPServerTable:
    def __init__(self, server_info):
        self.server_id = server_info['server_id']
        self.server_name = server_info['server_name']
        self.spec_path = server_info['spec_path']  # Added spec_path field

def generate_server_table(server_info):
    table = MCPServerTable(server_info)
    # Include spec_path in the table output
    return {
        'server_id': table.server_id,
        'server_name': table.server_name,
        'spec_path': table.spec_path
    }

Verification

To verify that the fixes work, test the following scenarios:

  • Register a tool with a single-prefixed name and trigger a request from the MCP inspector UI to ensure the lookup succeeds.
  • Edit a server via the UI and verify that the tool preview works even if spec_path is missing from the request.
  • Inspect the MCPServerTable output and verify that the spec_path field is included for each server.

Extra Tips

  • Ensure that the `spec_path

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…
#api#ssr#installation#tensor shape#autograd error#file not found#serialization error#model compatibility#GPU setup

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]: Multiple MCP integration issues: tool registry lookup, OpenAPI spec_path fallback, and MCPServerTable diagnostics [1 participants]