Issue Station
Sign In
Tools hereToolbox

litellm - 💡(How to fix) Fix [Feature]: Request for Configuration Option to Disable/Opt-Out of SEP-986 MCP Tool Name Prefixes

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…

Fix Action

Fix / Workaround

Currently, the only workaround to achieve unprefixed tool names in clients is to use tool_name_to_display_name through the LiteLLM management API, which involves extra setup (as the tool_name_to_display_name field is currently ignored in config.yaml as per issue #24102).

RAW_BUFFERClick to expand / collapse

Check for existing issues

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

The Feature

Dear LiteLLM Team,

I am writing to request a configuration option (e.g., an environment variable or config.yaml setting) to disable or opt-out of the SEP-986 mandated MCP tool name prefixing, which was introduced in LiteLLM v1.80.18 (protocol version 2025-11-25).

While I understand the rationale behind SEP-986 for preventing tool name collisions in multi-server environments, the current implementation hardcodes add_prefix=True when listing tools via the /mcp/ endpoint, even for single-server setups or when an alias already provides sufficient disambiguation.

This mandatory prefixing (e.g., server_alias-tool_name) is disruptive for existing clients (like Cursor and Claude Code) that expect tools to be listed with their original, unprefixed names. Although MCP_TOOL_PREFIX_SEPARATOR can be configured, this only changes the separator character and does not disable the prefix entirely.

Currently, the only workaround to achieve unprefixed tool names in clients is to use tool_name_to_display_name through the LiteLLM management API, which involves extra setup (as the tool_name_to_display_name field is currently ignored in config.yaml as per issue #24102).

<img width="573" height="273" alt="Image" src="https://github.com/user-attachments/assets/7a58b51f-a8a9-4cac-aaa9-088fac7189fc" />

Motivation, pitch

A direct configuration option to disable the automatic server prefixing would significantly simplify integration for users who prefer or require unprefixed tool names, especially in scenarios where:

  1. Only one MCP server is exposed through the LiteLLM proxy.
  2. The server alias itself is already descriptive and unique.
  3. Client applications are not designed to handle prefixed tool names.

Thank you for considering this feature request. I am using v1.83.0-nightly@sha256:c9487776ba1b69c363dca49c2718903f0c7719c0f7ea7d7ac396f523d6c64f91

What part of LiteLLM is this about?

Proxy

LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users?

No

Twitter / LinkedIn details

No response

extent analysis

TL;DR

Consider adding a configuration option to disable the automatic server prefixing for tool names in the LiteLLM proxy.

Guidance

  • Review the current implementation of the /mcp/ endpoint to understand how the add_prefix=True parameter is being used and consider modifying it to accept a configurable option.
  • Investigate the feasibility of introducing a new environment variable or config.yaml setting to control the prefixing behavior.
  • Evaluate the impact of disabling the prefixing on existing clients and potential workarounds, such as using the tool_name_to_display_name field through the LiteLLM management API.
  • Assess the trade-offs between simplicity and flexibility in integrating with clients that expect unprefixed tool names.

Example

No code snippet is provided as the issue does not contain sufficient technical details to generate a concrete example.

Notes

The solution may require changes to the LiteLLM proxy code and configuration, and careful consideration of the implications for existing clients and use cases.

Recommendation

Apply a workaround, such as using the tool_name_to_display_name field through the LiteLLM management API, until a configuration option to disable the automatic server prefixing is available, as it allows for more flexibility in handling tool names.

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#installation#tensor shape#autograd error#environment variable

Still need to ship something?

×6

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

Back to top recommendations

TRENDING