open-webui/mcpo
1
0
Fork 0
mirror of https://github.com/open-webui/mcpo.git synced 2026-07-22 11:45:46 -04:00
Code Issues 49 Packages Projects Releases 10 Wiki Activity

feat: Implement data sanitization for field name compatibility #71

New Issue
Closed
opened 2026-02-15 20:17:49 -05:00 by yindo · 1 comment
yindo commented 2026-02-15 20:17:49 -05:00
Owner
Copy Link
Copy Source

Originally created by @carlosaln on GitHub (May 27, 2025).

Check Existing Issues

  • I have searched the existing issues and discussions.

Problem Description

mcpo currently fails when connecting to MCP servers that use field names with leading underscores (like __user_id__, __calendar_id__) due to Pydantic's built-in restriction against such field names. This creates compatibility issues with servers like MCP GSuite, which uses these naming conventions to distinguish system parameters from user data.

Note that the use of double underscore (__) prefixes for special or system fields is a common convention in many organizations and platforms (like Google APIs, which often use leading underscores or double underscores to denote internal or reserved fields...) also see MongoDB that uses them to clearly separate system-level parameters from user data.

As a result, mcpo's current incompatibility with these field names limits its ability to interact with some MCP servers.

As an example when I tried to use mcp-gsuite, I got:

NameError: Fields must not use names with leading underscores; e.g., use 'user_id__' instead of '__user_id__'.

Desired Solution you'd like

I propose adding some kind of field name sanitization module to mcpo that automatically handles incompatible field names while preserving the original semantics for MCP server communication.

It would:

  1. Identify problematic field names in MCP tool schemas
  2. Sanitize field names for Pydantic model creation (__user_id__ --> field__user_id__)+ restore original field names when calling MCP servers
  3. Let API users see clean, valid field names in OpenAPI documentation
  4. Leave existing functionality unchanged

I'm happy to do some work on this if the idea is accepted.

Alternatives Considered

  • Ignore the issue, but this would limit mcpo's goal of exposing any MCP tool as an OpenAPI-compatible HTTP server
  • Asking MCP servers to change their naming conventions, but this would break other existing integrations and they may just not want to
  • Manual field mapping in the configuration would be too complex, as it would require users to map every problematic field themselves.
  • Can't use a different Pydantic configuration is not possible because Pydantic's underscore restriction is hardcoded for safety.

Additional Context

Maybe we’ll want to handle cases where a field name is a reserved Python keyword, or where the field names start with special characters like $ or @. It could even be possible to let people set up their own rules for how field names get cleaned up, depending on the server?

I'm happy to do some work on this if the idea is accepted.

Originally created by @carlosaln on GitHub (May 27, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description mcpo currently fails when connecting to MCP servers that use field names with leading underscores (like `__user_id__`, `__calendar_id__`) due to Pydantic's built-in restriction against such field names. This creates compatibility issues with servers like [MCP GSuite](https://github.com/MarkusPfundstein/mcp-gsuite/tree/main), which uses these naming conventions to distinguish _system parameters_ from user data. Note that the use of double underscore (`__`) prefixes for special or system fields is a common convention in many organizations and platforms (like Google APIs, which often use leading underscores or double underscores to denote internal or reserved fields...) also see MongoDB that uses them to clearly separate system-level parameters from user data. As a result, mcpo's current incompatibility with these field names limits its ability to interact with some MCP servers. As an example when I tried to use mcp-gsuite, I got: ``` NameError: Fields must not use names with leading underscores; e.g., use 'user_id__' instead of '__user_id__'. ``` ### Desired Solution you'd like I propose adding some kind of field name sanitization module to mcpo that automatically handles incompatible field names while preserving the original semantics for MCP server communication. It would: 1. Identify problematic field names in MCP tool schemas 2. Sanitize field names for Pydantic model creation (`__user_id__` --> `field__user_id__`)+ restore original field names when calling MCP servers 3. Let API users see clean, valid field names in OpenAPI documentation 4. Leave existing functionality unchanged I'm happy to do some work on this if the idea is accepted. ### Alternatives Considered - Ignore the issue, but this would limit mcpo's goal of _exposing any MCP tool as an OpenAPI-compatible HTTP server_ - Asking MCP servers to change their naming conventions, but this would break other existing integrations and they may just not want to - Manual field mapping in the configuration would be too complex, as it would require users to map every problematic field themselves. - Can't use a different Pydantic configuration is not possible because Pydantic's underscore restriction is hardcoded for safety. ### Additional Context Maybe we’ll want to handle cases where a field name is a reserved Python keyword, or where the field names start with special characters like $ or @. It could even be possible to let people set up their own rules for how field names get cleaned up, depending on the server? I'm happy to do some work on this if the idea is accepted.
yindo closed this issue 2026-02-15 20:17:49 -05:00
yindo commented 2026-02-15 20:17:49 -05:00
Author
Owner
Copy Link
Copy Source

@2underscores commented on GitHub (Jun 4, 2025):

IMO this is more a bug than a feature, raised ^ for it.

Very basic and only handles specifically the leading _'s case (I think by far that will be most common), but could easily extend the field cleaning logic in PR beyond just _ strip to something more comprehensive as proposed in the feat req. Unsure exactly what other restrictions pydantic might place

@2underscores commented on GitHub (Jun 4, 2025): IMO this is more a bug than a feature, raised ^ for it. Very basic and only handles specifically the leading `_`'s case (I think by far that will be most common), but could easily extend the field cleaning logic in PR beyond just _ strip to something more comprehensive as proposed in the feat req. Unsure exactly what other restrictions pydantic might place
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
can't reproduce
enhancement
good first issue
help wanted
invalid
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: open-webui/mcpo#71
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?