[Enhancement]: Allow configuring a valid functionName for MCP service in librechat.yaml

[tzq84]

What features would you like to see added?

When using Azure OpenAI models with Tool Calling, the current implementation uses the MCP service name as the function name for tools. However, Azure requires function names to match the pattern: '^[a-zA-Z0-9_.-]+$'. If the MCP service name contains non-ASCII characters (e.g., Chinese), this leads to an error:

Invalid 'tools[0].function.name': string does not match pattern. Expected a string that matches the pattern '^[a-zA-Z0-9_\.-]+$'.

I would like to propose an enhancement to allow configuration of a specific 'functionName' for each MCP service in librechat.yaml. This 'functionName' would be used when passing tools to the model for Tool Calling. If 'functionName' is not explicitly set, it should default to the displayed service name (to maintain backward compatibility).

This feature would allow users to set a valid ASCII function name for Azure, while keeping the display name in any language.

More details

Steps to reproduce:

1. Configure an MCP service in librechat.yaml with a name containing Chinese characters.
2. Use an Azure OpenAI model with Tool Calling enabled.
3. Attempt to call the tool; the process fails with the error:
   Invalid 'tools[0].function.name': string does not match pattern. Expected a string that matches the pattern '^[a-zA-Z0-9_\.-]+$'.

Workaround:
Currently, the only workaround is to avoid non-ASCII characters in the MCP service name, which limits the ability to localize or display user-friendly names in other languages.

Expected behavior:
Support an additional 'functionName' property for each MCP service in librechat.yaml. Use this functionName as the function's identifier during Tool Calls. If functionName is not set, fall back to the service name as before.

Example config:

mcpServers:
  我的服务:
    functionName: "my_service"
    # ...other config...

### Which components are impacted by your request?

_No response_

### Pictures

![Image](https://github.com/user-attachments/assets/0d11c2e8-6eb6-468c-8319-e21c8bcfa123)

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

[danny-avila]

This should be done at the MCP server level, I am sure there are very few not following the pattern ^[a-zA-Z0-9_.-]+$

[tzq84]

Thank you for your reply. The MCP server name is actually in English and follows the pattern. The error only occurs because LibreChat uses the YAML service name as the function name, while other platforms like Cherry Studio have no such issue. Allowing a separate functionName config would solve this and improve compatibility.

[danny-avila]

the name is arbitrary, so you can already change this on your end.

[danny-avila]

I will add something that will help when using the server name as part of the tool name

[tzq84]

Thank you for your explanation. I am currently using an English name to avoid errors, but this is less user-friendly for our Chinese users. I would like to display the service name in Chinese for users, but still have a valid tool name for Azure. Looking forward to your improvement on this!

[danny-avila]

I understand. I think at the very least we can convert the Chinese to the ^[a-zA-Z0-9_.-]+$ pattern and still be unique.

[tzq84]

Thank you! That solution sounds great and would solve the problem. Looking forward to it!

[danny-avila]

Implemented here: #7421

[tzq84]

Thank you, I’ve tested the fix and it works well. However, I noticed that when using the Agent Endpoint and setting the MCP server as a tool, the same error still occurs. Could this fix also be applied to the Agent Endpoint use case? Thanks again for your help!

[danny-avila]

Yes, I will look into it, thanks for letting me know. There is also a similar issue for MCP tool names exceeding 64 characters, may need to handle that as well.

[danny-avila]

@tzq84 using Azure with Agents and the MCP server individual tools, there's no issue:

[danny-avila]

mcpServers:
  搜索互联网:
    command: uvx
    args:
      - duckduckgo-mcp-server

[tzq84]

Thank you for your reply. I have updated to the latest code, but I am still encountering the error when using Chinese names in the Agent Endpoint. I will attach a screenshot of the error for your reference.

Please let me know if there is anything else I should check on my side. Thank you for your continued help!

[danny-avila]

Can you share the MCP server you are using? This is a different case, where the tool name is in Chinese, not the server name.

[tzq84]

Thanks for your quick response. I’ve sent you the MCP server information via email for privacy reasons. Please let me know if you need anything else.

[tzq84]

Hi, I’ve sent the MCP server details to your email but haven’t received a response yet.

After updating to the latest code, I found that the error now appears again even in scenarios that were previously working after your fix (Chinese tool names are causing errors again). Could you please take another look? Thank you for your help!