[GH-ISSUE #14603] feat: Native MCP support (without mcpo) #55981

New Issue

GiteaMirror · 2026-05-05T18:25:45-05:00

GiteaMirror commented

2026-05-05 18:25:45 -05:00

Originally created by @msabramo on GitHub (Jun 2, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14603

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

I've read the reasoning for using mcpo instead of having Open WebUI natively support MCP:

and I think these are well-reasoned arguments, given the state of how things were not very long ago, but I think the landscape has changed and I wonder if you'd consider reconsidering.

I think it's still true that most MCP servers are STDIO. I think this is because SSE was hard to implement and there was no auth and running a server adds the hurdle of having to deploy it and a lot of people didn't want to think about that, especially when creating open-source MCP servers.

But nowadays, the MCP server spec supports a Streamable HTTP transport which is easier to deal with and this supports authorization via OAuth 2.1.

This authorization mechanism is based on established specifications listed below, but implements a selected subset of their features to ensure security and interoperability while maintaining simplicity:

OAuth 2.1 IETF DRAFT
OAuth 2.0 Authorization Server Metadata (RFC8414)
OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)

Now I feel like I should mention that I haven't seen many MCP servers that implement this and I also haven't seen many MCP clients that implement this (which is why I'm wanting Open WebUI to support it, so that there is an easy to use client that isn't as developer-focused as IDEs like Cursor, GitHub Copilot, Windsurf, etc.) but I think there are some reasons for this:

A lot of MCP servers were built before things changed and a lot of people won't go back and update something that works
People creating open-source MCP servers are largely doing things that don't require auth. The folks who are writing MCP servers that use auth are more likely to be working for enterprises and they are not open-sourcing their MCP servers, so even if people are writing these servers, it may not be apparent.
The lack of clients that support Streamable HTTP and auth means that people don't have much incentive to invest time in these things if there's nothing that can use them. To this point if clients like Open WebUI add support, it will help with adoption - i.e.: "If you build it, they will come".

Now I haven't messed too much with 3rd party tools for Open WebUI, but the ones I've seen don't require authentication. So I don't know if the lack of authentication in MCP servers is a big deal. OTOH, MCP servers now have the potential to support OAuth so I think this has the potential to be solved.

I'm a developer in an enterprise that is interested in having a lot of internal MCP servers for using internal enterprise resources. At this point in time, MCP seems to be way more popular than OpenAPI because there are lots of tools that people like that support MCP. If I am going to expose internal resources in my enterprise I am most likely going to write MCP servers and not OpenAPI. Now I can run an mcpo server so that Open WebUI can use these, but it just seems like extra work and extra complexity that I have to explain to people and maintain. Every time someone creates a new MCP and wants it to be usable in Open WebUI, I need to update the mcpo config to support it. In other words, it's doable but it has extra friction, probably to the point that it would hurt Open WebUI adoption. I feel like Open WebUI is much more likely to get used at my company if it can super easily consume from MCP servers.

I am currently looking at taking a bunch of STDIO-based MCP servers in use at my company and creating versions of them that are served over Streamable HTTP and supporting OAuth for authorization. The main obstacle is the lack of clients that can actually consume such servers. If Open WebUI were to support this kind of server, then I'd have a way to demonstrate the value of these servers and then I'd be able to advocate for creating more of these servers and using Open WebUI as the recommended way to access them.

I love Open WebUI and have promoted it within my company and have had limited success for whatever reason. I think with MCP there might be an opportunity for Open WebUI to become a popular way to interact with MCP servers (because most of the other MCP clients are IDEs that non-technical people would prefer to not deal with), but I feel that the need for mcpo is creating too much friction for it to achieve its full potential as the de-facto chat client (and MCP client).

I respect your reasoning and will respect your decision if you don't want to support MCP (heck, dealing with MCP is a little bit exhausting because it's new and changing rapidly), but I do feel like Open WebUI will benefit from a tighter integration with MCP.

Desired Solution you'd like

Ability to add an MCP server directly to Open WebUI without having to use mcpo

Alternatives Considered

No response

Additional Context

No response

Originally created by @msabramo on GitHub (Jun 2, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/14603 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description I've read the reasoning for using mcpo instead of having Open WebUI natively support MCP: - https://github.com/open-webui/mcpo - https://docs.openwebui.com/openapi-servers/mcp/#%EF%B8%8F-why-is-the-mcp-to-openapi-proxy-superior and I think these are well-reasoned arguments, given the state of how things were not very long ago, but I think the landscape has changed and I wonder if you'd consider reconsidering. I think it's still true that most MCP servers are STDIO. I think this is because SSE was hard to implement and there was no auth and running a server adds the hurdle of having to deploy it and a lot of people didn't want to think about that, especially when creating open-source MCP servers. But nowadays, the MCP server spec supports a [Streamable HTTP transport](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http) which is easier to deal with and this supports [authorization](https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization#2-1-1-oauth-grant-types) via OAuth 2.1. > This authorization mechanism is based on established specifications listed below, but implements a selected subset of their features to ensure security and interoperability while maintaining simplicity: > > [OAuth 2.1 IETF DRAFT](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12) > OAuth 2.0 Authorization Server Metadata ([RFC8414](https://datatracker.ietf.org/doc/html/rfc8414)) > OAuth 2.0 Dynamic Client Registration Protocol ([RFC7591](https://datatracker.ietf.org/doc/html/rfc7591)) Now I feel like I should mention that I haven't seen many MCP servers that implement this and I also haven't seen many MCP clients that implement this (which is why I'm wanting Open WebUI to support it, so that there is an easy to use client that isn't as developer-focused as IDEs like Cursor, GitHub Copilot, Windsurf, etc.) but I think there are some reasons for this: - A lot of MCP servers were built before things changed and a lot of people won't go back and update something that works - People creating open-source MCP servers are largely doing things that don't require auth. The folks who are writing MCP servers that use auth are more likely to be working for enterprises and they are not open-sourcing their MCP servers, so even if people are writing these servers, it may not be apparent. - The lack of clients that support Streamable HTTP and auth means that people don't have much incentive to invest time in these things if there's nothing that can use them. To this point if clients like Open WebUI add support, it will help with adoption - i.e.: "If you build it, they will come". Now I haven't messed too much with 3rd party tools for Open WebUI, but the ones I've seen don't require authentication. So I don't know if the lack of authentication in MCP servers is a big deal. OTOH, MCP servers now have the potential to support OAuth so I think this has the potential to be solved. I'm a developer in an enterprise that is interested in having a lot of internal MCP servers for using internal enterprise resources. At this point in time, MCP seems to be way more popular than OpenAPI because there are lots of tools that people like that support MCP. If I am going to expose internal resources in my enterprise I am most likely going to write MCP servers and not OpenAPI. Now I can run an mcpo server so that Open WebUI can use these, but it just seems like extra work and extra complexity that I have to explain to people and maintain. Every time someone creates a new MCP and wants it to be usable in Open WebUI, I need to update the mcpo config to support it. In other words, it's doable but it has extra friction, probably to the point that it would hurt Open WebUI adoption. I feel like Open WebUI is much more likely to get used at my company if it can super easily consume from MCP servers. I am currently looking at taking a bunch of STDIO-based MCP servers in use at my company and creating versions of them that are served over Streamable HTTP and supporting OAuth for authorization. The main obstacle is the lack of clients that can actually consume such servers. If Open WebUI were to support this kind of server, then I'd have a way to demonstrate the value of these servers and then I'd be able to advocate for creating more of these servers and using Open WebUI as the recommended way to access them. I love Open WebUI and have promoted it within my company and have had limited success for whatever reason. I think with MCP there might be an opportunity for Open WebUI to become a popular way to interact with MCP servers (because most of the other MCP clients are IDEs that non-technical people would prefer to not deal with), but I feel that the need for mcpo is creating too much friction for it to achieve its full potential as the de-facto chat client (and MCP client). I respect your reasoning and will respect your decision if you don't want to support MCP (heck, dealing with MCP is a little bit exhausting because it's new and changing rapidly), but I do feel like Open WebUI will benefit from a tighter integration with MCP. ### Desired Solution you'd like Ability to add an MCP server directly to Open WebUI without having to use mcpo ### Alternatives Considered _No response_ ### Additional Context _No response_

GiteaMirror closed this issue

2026-05-05 18:25:45 -05:00

GiteaMirror commented

2026-05-05 18:25:47 -05:00

@tjbck commented on GitHub (Jun 2, 2025):

We'll consider supporting streamable http only.

@tjbck commented on GitHub (Jun 2, 2025): We'll consider supporting `streamable http` only.

GiteaMirror commented

2026-05-05 18:25:48 -05:00

@SheldonGrant commented on GitHub (Jun 5, 2025):

We'll consider supporting streamable http only.

This makes a log of sense. is there somewhere this dicussion is being had. Would really love to contribute to the discussion.

@SheldonGrant commented on GitHub (Jun 5, 2025): > We'll consider supporting `streamable http` only. This makes a log of sense. is there somewhere this dicussion is being had. Would really love to contribute to the discussion.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#55981