MCP support #58
Replies: 6 comments
-
I agree. Even more, most of the mentioned critics on MCP are invalid. MCP supports streamable HTTP as transport mechanism, so its not a "custom protocol", and it is secure out-of-the-box (if using HTTPS). And it is REST. Apart from that - MCP is more than just tools. Although tools are the most important feature, MCP also supports prompts and resources. |
Beta Was this translation helpful? Give feedback.
-
Yeah the signal loss for the openapi servers (sampling, resources, progress) becomes a non-starter beyond the most trivial of use cases where you are not starting with a REST api. That being said complaining here is not productive to anyones time. The OpenWebUI core has a Tool api that would facilitate these features. |
Beta Was this translation helpful? Give feedback.
-
MCP still has issues but evolving rapidly. It stinks OI will not support. MCPO is silly in my use cases, I'm going to wrap my apis in MCP only to convert them back to OpenAPI again? Also if my upstream used Oauth (ex Jira) then MCPO can't even be used. This doesn't help us scale, and the resource and prompt features of Mcp are very useful in a large environment. Can this be built in Open WebUI with tools and templates? Sure, but then we still need to have a MCP version for users using code tools or direct llm access. UTCP is promising and gaining popularity but still not the level of MCP. |
Beta Was this translation helpful? Give feedback.
-
I cant help but feel this is outside of the problem domain Open-WebUI is operating within. I'd be 100% fine if MCPO was released as a stand alone project/proposal that Open-WebUI supported -- but instead it had been mandated. Right now it's being presented as a "We know best; Here's a white paper worth of arguments proving it" ... but in practice it's anything but clear or desirable. If the goal is to create a new unified and popular standard the current approach is not how one gains critical support and adoption. At this point, VSCode has full support for MCP via stdio, sse, and streamable-http transports. They support all features of FastMCP tooling including elicitation, progress reporting, sampling, and more. As a previous power user of Open-WebUI I don't want to have to spin up a separate -- largely manually configured -- process just to use a tool that I already have proxied via a more complete tool. |
Beta Was this translation helpful? Give feedback.
-
I'm going to contribute here by saying that a lot of enterprise tools opening up to AI use are now provided via MCP - take for example Atlassian's Remote MCP, GitHub's own tooling at I do love that OpenAPI in general is provided as a possibility to provide tools to the AI, it's a very nice way of describing an API by involving JSON schemas for clear definitions coming from a developer's/API user's perspective. I can see some of my own code which already exposes APIs with OpenAPI specs and more specific APIs integrating this way pre-optimizing for AI. And maybe one day it will be well supported alongside MCP. But the reality right now is the tools that are already optimized for AI follow the MCP standard. MCPO is currently not gaining significant traction. The proxying is cumbersome and adds another layer of headaches around things like authorization. The effect of mandating MCPO is that it is made unnecessarily complicated to even get a jumpstart with tooling, and an artificial delay in adopting tooling for OpenWebUI is set up that way. It nukes the point of running OpenWebUI to make AI easier to use for me. I would like for this to just work and not cause more trouble than is worth it. A strong opinion, while well reasoned for, shouldn't make a product less usable when it's supposed to be part of an evolving ecosystem. |
Beta Was this translation helpful? Give feedback.
-
why cant it just be a list of mcp servers, click checkbox, and BAM....done anything that involves copying and pasting from anything to anything, in my view, isnt ready |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I completely understand the dev having strong opinions about what they want to support, but you can't swim against the current. You can write a thousand pages saying why MCPO is superior, but the whole point of having a standard is not to have to deal with all different kinds of extra layers proxying things and adding complexity. Refusing to support MCP natively because they like REST APIs and want to push cloud support is, I can't help but think, short sighted. Hopefully they change their mind soon. Just my 2 cents.
Beta Was this translation helpful? Give feedback.
All reactions