open-webui/mcpo
1
0
Fork 0
mirror of https://github.com/open-webui/mcpo.git synced 2026-07-19 23:14:20 -04:00
Code Issues 49 Packages Projects Releases 10 Wiki Activity

issue: HTTP-headers not forwarded to MCP/SSE-Server #83

New Issue
Open
opened 2026-02-15 20:17:54 -05:00 by yindo · 16 comments
yindo commented 2026-02-15 20:17:54 -05:00
Owner
Copy Link
Copy Source

Originally created by @MBueschelberger on GitHub (Jun 22, 2025).

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of mcpo.

mcpo Version

v0.0.15

Open WebUI Version (if applicable)

No response

Operating System

Latest Docker Image

Browser (if applicable)

cURL-command

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both MCPO and Open WebUI.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have listed steps to reproduce the bug in detail.

Expected Behavior

I have the setup of a MCPO-server (version 0.0.15) running on the latest Docker image from Github and a FastMCP (Version 2.6.1) server running in a separate container.

I would like to receive the headers in my FastMCP server, which were forwarded from the MCPO proxy. By doing so, I am passing a simple HTTP-request to the MCPO-server.

I am doing this, because I want to use the MCPO as an agent tool in OpenWebUI and I am using cURL commands in order to debug the header forwarding. The FastMCP will later use the token from the header in order to call a further external tool, since this Bearer-token comes from the same OAuth-session as the one faciliated for authentication in OpenWebUI.

The workflow then looks like this:

HTTP Request (with Auth-header) from cURL/OpenWebUI --sent-to--> MCPO server --is-forwarding-headers-to-> FastMCP-server --executes-with-JWT--> Third Party tool

The latest version (v0.0.15) of MCPO supports custom headers, but they only seem to enable static header information, which is not helpful in case when my FastAPI is calling a third-party tool, which is using a time-limited JWT for authorization.

Actual Behavior

I can not observe that the Auth-Header was not forwarded to the FastMCP-tool, despite the fact that the Middleware-object in the mcpo-package seems to allow header-forwarding of any client by default.

If I call my FastMCP-tool directly, I have no problems with the header forwarding, which indicates that the problem is related to the MCPO proxy (see steps-to-reproduce for code reference).

Steps to Reproduce

My MCP-Server (version is:

from fastmcp import FastMCP
from fastmcp.server.dependencies import get_http_headers, get_access_token
from src import my_third_party_tool

logger = logging.getLogger(__name__)

server = FastMCP('My FastMCP Server', host="0.0.0.0", port=8001, log_level="INFO")

@server.tool()
async def my_tool(some_input: str) -> dict:
    """MCP-tool for a third party service"""

    headers = get_http_headers()
    token = get_access_token()
    print("headers:", headers)
    print("token:",token)
    return my_third_party_tool(some_input, token or headers.get("Authorization")

if __name__ == "__main__":
    server.run(transport="sse")

My MCPO-command (v0.0.15) is:

mcpo --port 8000 --server-type sse -- http://fastmcp:8001/sse

My cURL command for debugging the header forwarding is:

curl -X 'POST' \
  'http://localhost:8000/my_tool' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer xyz \
  -d '{
  "timezone": "string"
}'

The header forwarding works propery when calling the FastMCP directly:

from fastmcp import Client
from fastmcp.client.auth import BearerAuth
import asyncio

client = Client("http://0.0.0.0:8001/sse", auth=BearerAuth(token="my-token"))

async def main():
    async with client:

        res = await client.call_tool("my_tool", {"some_input": "foo bar"})
        print(res)
    
if __name__ == "__main__":
    asyncio.run(main())

Logs & Screenshots

FastMCP logs when calling via HTTP through MCPO:

INFO:     172.28.0.17:33418 - "POST /messages/?session_id=d331b81ee05142cc931e3b0b4d8f4fc9 HTTP/1.1" 202 Accepted
headers: {'accept-encoding': 'gzip, deflate', 'user-agent': 'python-httpx/0.28.1', 'accept': 'text/event-stream', 'cache-control': 'no-store'}

FastMCP logs when calling directly:

INFO:     127.0.0.1:56630 - "POST /messages/?session_id=8331b0fc679e4d8baa17df65fd19c25a HTTP/1.1" 202 Accepted
headers: {'accept-encoding': 'gzip, deflate', 'user-agent': 'python-httpx/0.28.1', 'accept': 'text/event-stream', 'cache-control': 'no-store', 'authorization': 'Bearer my-token'}

Additional Information

Is the MCPO configured wrong or is it a bug in the FastAPI implementation of MCPO?

Originally created by @MBueschelberger on GitHub (Jun 22, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of mcpo. ### mcpo Version v0.0.15 ### Open WebUI Version (if applicable) _No response_ ### Operating System Latest Docker Image ### Browser (if applicable) cURL-command ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** MCPO and Open WebUI. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have listed steps to reproduce the bug in detail. ### Expected Behavior I have the setup of a MCPO-server (version 0.0.15) running on the latest Docker image from Github and a FastMCP (Version 2.6.1) server running in a separate container. I would like to receive the headers in my FastMCP server, which were forwarded from the MCPO proxy. By doing so, I am passing a simple HTTP-request to the MCPO-server. I am doing this, because I want to use the MCPO as an agent tool in OpenWebUI and I am using cURL commands in order to debug the header forwarding. The FastMCP will later use the token from the header in order to call a further external tool, since this Bearer-token comes from the same OAuth-session as the one faciliated for authentication in OpenWebUI. The workflow then looks like this: `HTTP Request (with Auth-header) from cURL/OpenWebUI --sent-to--> MCPO server --is-forwarding-headers-to-> FastMCP-server --executes-with-JWT--> Third Party tool` The latest version (v0.0.15) of MCPO supports custom headers, but they only seem to enable static header information, which is not helpful in case when my FastAPI is calling a third-party tool, which is using a time-limited JWT for authorization. ### Actual Behavior I can not observe that the Auth-Header was not forwarded to the FastMCP-tool, despite the fact that the `Middleware`-object in the `mcpo`-package seems to allow [header-forwarding of any client by default.](https://github.com/open-webui/mcpo/blob/4758d30f6cb921658c10cb9675320a598b31addb/src/mcpo/main.py#L306) If I call my FastMCP-tool directly, I have no problems with the header forwarding, which indicates that the problem is related to the MCPO proxy (see steps-to-reproduce for code reference). ### Steps to Reproduce My MCP-Server (version is: ```{python} from fastmcp import FastMCP from fastmcp.server.dependencies import get_http_headers, get_access_token from src import my_third_party_tool logger = logging.getLogger(__name__) server = FastMCP('My FastMCP Server', host="0.0.0.0", port=8001, log_level="INFO") @server.tool() async def my_tool(some_input: str) -> dict: """MCP-tool for a third party service""" headers = get_http_headers() token = get_access_token() print("headers:", headers) print("token:",token) return my_third_party_tool(some_input, token or headers.get("Authorization") if __name__ == "__main__": server.run(transport="sse") ``` My MCPO-command (`v0.0.15`) is: ```{bash} mcpo --port 8000 --server-type sse -- http://fastmcp:8001/sse ``` My cURL command for debugging the header forwarding is: ```{bash} curl -X 'POST' \ 'http://localhost:8000/my_tool' \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer xyz \ -d '{ "timezone": "string" }' ``` The header forwarding works propery when calling the FastMCP directly: ```{python} from fastmcp import Client from fastmcp.client.auth import BearerAuth import asyncio client = Client("http://0.0.0.0:8001/sse", auth=BearerAuth(token="my-token")) async def main(): async with client: res = await client.call_tool("my_tool", {"some_input": "foo bar"}) print(res) if __name__ == "__main__": asyncio.run(main()) ``` ### Logs & Screenshots FastMCP logs when calling via HTTP through MCPO: ``` INFO: 172.28.0.17:33418 - "POST /messages/?session_id=d331b81ee05142cc931e3b0b4d8f4fc9 HTTP/1.1" 202 Accepted headers: {'accept-encoding': 'gzip, deflate', 'user-agent': 'python-httpx/0.28.1', 'accept': 'text/event-stream', 'cache-control': 'no-store'} ``` FastMCP logs when calling directly: ``` INFO: 127.0.0.1:56630 - "POST /messages/?session_id=8331b0fc679e4d8baa17df65fd19c25a HTTP/1.1" 202 Accepted headers: {'accept-encoding': 'gzip, deflate', 'user-agent': 'python-httpx/0.28.1', 'accept': 'text/event-stream', 'cache-control': 'no-store', 'authorization': 'Bearer my-token'} ``` ### Additional Information Is the MCPO configured wrong or is it a bug in the FastAPI implementation of MCPO?
yindo added the bug label 2026-02-15 20:17:54 -05:00
yindo commented 2026-02-15 20:17:55 -05:00
Author
Owner
Copy Link
Copy Source

@aklowther commented on GitHub (Jul 8, 2025):

I'm also experiencing this issue

@aklowther commented on GitHub (Jul 8, 2025): I'm also experiencing this issue
yindo commented 2026-02-15 20:17:55 -05:00
Author
Owner
Copy Link
Copy Source

@Manyfaces860 commented on GitHub (Aug 1, 2025):

were you able to solve this issue?

@Manyfaces860 commented on GitHub (Aug 1, 2025): were you able to solve this issue?
yindo commented 2026-02-15 20:17:55 -05:00
Author
Owner
Copy Link
Copy Source

@Manyfaces860 commented on GitHub (Aug 1, 2025):

@MBueschelberger in case if anyone is still stuck on the header problem, here is the correct example command for solving this issue
uv run mcpo --port 8000 --server-type sse --header "{\"Authorization\" :\"Bearer my-secret-access-token\"}" -- http://localhost:8001/sse

@Manyfaces860 commented on GitHub (Aug 1, 2025): @MBueschelberger in case if anyone is still stuck on the header problem, here is the correct example command for solving this issue ` uv run mcpo --port 8000 --server-type sse --header "{\"Authorization\" :\"Bearer my-secret-access-token\"}" -- http://localhost:8001/sse `
yindo commented 2026-02-15 20:17:55 -05:00
Author
Owner
Copy Link
Copy Source

@MBueschelberger commented on GitHub (Aug 4, 2025):

@MBueschelberger in case if anyone is still stuck on the header problem, here is the correct example command for solving this issue uv run mcpo --port 8000 --server-type sse --header "{\"Authorization\" :\"Bearer my-secret-access-token\"}" -- http://localhost:8001/sse

@Manyfaces860, this does not solve the issue since it is a static access token. The use case mentioned above is picturing the sceanario, that we have a JWT token, which is valid only for an OAuth2-session opened by the user in OpenWebUI, e.g. by Keycloak. This token expires when the session is closed, e.g. after the timeout and the user needs to re-login.

This is why a static header does not make sense here, since the auth-Header needs to be dynamic - due to the nature of the expiration of web tokens. It can be simply solved by allowing the headers from any incoming request towards the MCPO-server.

This usually should be covered by the allow_headers-wildcard in the FastAPI-Middleware registration in the mcpo.main.py, but it somehow still blocks the incoming headers. This is why it needs to be debugged and investigated in detail.

@MBueschelberger commented on GitHub (Aug 4, 2025): > [@MBueschelberger](https://github.com/MBueschelberger) in case if anyone is still stuck on the header problem, here is the correct example command for solving this issue `uv run mcpo --port 8000 --server-type sse --header "{\"Authorization\" :\"Bearer my-secret-access-token\"}" -- http://localhost:8001/sse` @Manyfaces860, this does **_not_** solve the issue since it is a static access token. The use case mentioned above is picturing the sceanario, that we have a JWT token, which is valid only for an OAuth2-session opened by the user in OpenWebUI, e.g. by Keycloak. This token expires when the session is closed, e.g. after the timeout and the user needs to re-login. This is why a static header does not make sense here, since the auth-Header needs to be dynamic - due to the nature of the expiration of web tokens. It can be simply solved by allowing the headers from any incoming request towards the MCPO-server. This usually should be covered by the [`allow_headers`](https://github.com/open-webui/mcpo/blob/44ce6d05b0392231c359c2d86228835001942851/src/mcpo/main.py#L116)-wildcard in the `FastAPI`-Middleware registration in the `mcpo.main.py`, but it somehow still blocks the incoming headers. This is why it needs to be debugged and investigated in detail.
yindo commented 2026-02-15 20:17:55 -05:00
Author
Owner
Copy Link
Copy Source

@Manyfaces860 commented on GitHub (Aug 4, 2025):

@MBueschelberger
I forgot to consider the jwt token expiration issue, thanks for reminding me!

I actually debugged the flow of headers and found that it only sends those headers which are given to it when the mcpo Proxy is initialized, it does not have a mechanism for dynamic header forwarding yet, it uses session.calltool method for invoking tools on the mcp server and it does not have any argument for headers , only tool_name and args, so one way is that the header can be sent in the args argument but then your server will have to make sure it checks the token in the arguments.

I will also try to find another way.

@Manyfaces860 commented on GitHub (Aug 4, 2025): @MBueschelberger I forgot to consider the jwt token expiration issue, thanks for reminding me! I actually debugged the flow of headers and found that it only sends those headers which are given to it when the mcpo Proxy is initialized, it does not have a mechanism for dynamic header forwarding yet, it uses `session.calltool` method for invoking tools on the mcp server and it does not have any argument for headers , only tool_name and args, so one way is that the header can be sent in the args argument but then your server will have to make sure it checks the token in the arguments. I will also try to find another way.
yindo commented 2026-02-15 20:17:56 -05:00
Author
Owner
Copy Link
Copy Source

@alevsh commented on GitHub (Aug 15, 2025):

Have the same issue, any updates?

@alevsh commented on GitHub (Aug 15, 2025): Have the same issue, any updates?
yindo commented 2026-02-15 20:17:56 -05:00
Author
Owner
Copy Link
Copy Source

@Baronco commented on GitHub (Sep 7, 2025):

Have the same issue, any updates? x2

@Baronco commented on GitHub (Sep 7, 2025): Have the same issue, any updates? x2
yindo commented 2026-02-15 20:17:56 -05:00
Author
Owner
Copy Link
Copy Source

@scriptbotprime commented on GitHub (Sep 17, 2025):

I'd be interested in passing the token from OpenWebUI to the MCP server as well.

@scriptbotprime commented on GitHub (Sep 17, 2025): I'd be interested in passing the token from OpenWebUI to the MCP server as well.
yindo commented 2026-02-15 20:17:56 -05:00
Author
Owner
Copy Link
Copy Source

@rkconsulting commented on GitHub (Sep 18, 2025):

@MBueschelberger @aklowther @Baronco @alevsh @scriptbotprime

implemented tool-call level client header forwarding in this PR: https://github.com/open-webui/mcpo/pull/251

@rkconsulting commented on GitHub (Sep 18, 2025): @MBueschelberger @aklowther @Baronco @alevsh @scriptbotprime implemented tool-call level client header forwarding in this PR: https://github.com/open-webui/mcpo/pull/251
yindo commented 2026-02-15 20:17:57 -05:00
Author
Owner
Copy Link
Copy Source

@varunkhanna96 commented on GitHub (Oct 9, 2025):

@MBueschelberger @aklowther @Baronco @alevsh @scriptbotprime

implemented tool-call level client header forwarding in this PR: #251

tried this branch and dev branch of mcpo repo as well. facing issue
2025-10-09 20:49:21,127 - INFO - Unexpected error calling XXXXX: Traceback (most recent call last): File "XXXX/venv/lib/python3.11/site-packages/mcpo/utils/main.py", line 303, in tool result = await session.call_tool(endpoint_name, arguments=args, _meta=meta if meta else None) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: ClientSession.call_tool() got an unexpected keyword argument '_meta'

do we need to upgrade downgrade mcp package as well? as clearly FastMCP class does not support any _meta input variable. I'm on the latest version of mcp package.

async def call_tool( self, name: str, arguments: dict[str, Any] | None = None, read_timeout_seconds: timedelta | None = None, progress_callback: ProgressFnT | None = None, )

@varunkhanna96 commented on GitHub (Oct 9, 2025): > [@MBueschelberger](https://github.com/MBueschelberger) [@aklowther](https://github.com/aklowther) [@Baronco](https://github.com/Baronco) [@alevsh](https://github.com/alevsh) [@scriptbotprime](https://github.com/scriptbotprime) > > implemented tool-call level client header forwarding in this PR: [#251](https://github.com/open-webui/mcpo/pull/251) tried this branch and dev branch of mcpo repo as well. facing issue `2025-10-09 20:49:21,127 - INFO - Unexpected error calling XXXXX: Traceback (most recent call last): File "XXXX/venv/lib/python3.11/site-packages/mcpo/utils/main.py", line 303, in tool result = await session.call_tool(endpoint_name, arguments=args, _meta=meta if meta else None) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: ClientSession.call_tool() got an unexpected keyword argument '_meta'` do we need to upgrade downgrade mcp package as well? as clearly FastMCP class does not support any _meta input variable. I'm on the latest version of mcp package. `async def call_tool( self, name: str, arguments: dict[str, Any] | None = None, read_timeout_seconds: timedelta | None = None, progress_callback: ProgressFnT | None = None, )`
yindo commented 2026-02-15 20:17:57 -05:00
Author
Owner
Copy Link
Copy Source

@MBueschelberger commented on GitHub (Oct 20, 2025):

@MBueschelberger @aklowther @Baronco @alevsh @scriptbotprime
implemented tool-call level client header forwarding in this PR: #251

tried this branch and dev branch of mcpo repo as well. facing issue 2025-10-09 20:49:21,127 - INFO - Unexpected error calling XXXXX: Traceback (most recent call last): File "XXXX/venv/lib/python3.11/site-packages/mcpo/utils/main.py", line 303, in tool result = await session.call_tool(endpoint_name, arguments=args, _meta=meta if meta else None) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: ClientSession.call_tool() got an unexpected keyword argument '_meta'

do we need to upgrade downgrade mcp package as well? as clearly FastMCP class does not support any _meta input variable. I'm on the latest version of mcp package.

async def call_tool( self, name: str, arguments: dict[str, Any] | None = None, read_timeout_seconds: timedelta | None = None, progress_callback: ProgressFnT | None = None, )

This seems to be resolved with version 0.0.19 since the _meta kwarg got removed there.

@MBueschelberger commented on GitHub (Oct 20, 2025): > > [@MBueschelberger](https://github.com/MBueschelberger) [@aklowther](https://github.com/aklowther) [@Baronco](https://github.com/Baronco) [@alevsh](https://github.com/alevsh) [@scriptbotprime](https://github.com/scriptbotprime) > > implemented tool-call level client header forwarding in this PR: [#251](https://github.com/open-webui/mcpo/pull/251) > > tried this branch and dev branch of mcpo repo as well. facing issue `2025-10-09 20:49:21,127 - INFO - Unexpected error calling XXXXX: Traceback (most recent call last): File "XXXX/venv/lib/python3.11/site-packages/mcpo/utils/main.py", line 303, in tool result = await session.call_tool(endpoint_name, arguments=args, _meta=meta if meta else None) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: ClientSession.call_tool() got an unexpected keyword argument '_meta'` > > do we need to upgrade downgrade mcp package as well? as clearly FastMCP class does not support any _meta input variable. I'm on the latest version of mcp package. > > `async def call_tool( self, name: str, arguments: dict[str, Any] | None = None, read_timeout_seconds: timedelta | None = None, progress_callback: ProgressFnT | None = None, )` This seems to be resolved with version 0.0.19 since the [`_meta` kwarg got removed there](https://github.com/open-webui/mcpo/commit/25b219a99258a356a0fcb2421eb60e3ec4798d70#diff-1164f11cb2a2debf8533a7df9c65b83b7706c39a2edb87ce49063e2aaad4b31eR317).
yindo commented 2026-02-15 20:17:57 -05:00
Author
Owner
Copy Link
Copy Source

@MBueschelberger commented on GitHub (Oct 20, 2025):

However, even though I followed this guide for the configuration, I still encounter the same issue when using version 0.0.19.

It is probably due to the case, that the meta-variable is assigned but never used in version 0.0.19. This is a reverted change from version 0.0.18 (see release notes here)

@MBueschelberger commented on GitHub (Oct 20, 2025): However, even though I followed [this guide](https://github.com/open-webui/mcpo/blob/94e1dcd4752ca3b5b8020d62fdfb5d9afe6065a6/CLIENT_HEADER_FORWARDING.md) for the configuration, I still encounter the same issue when using version 0.0.19. It is probably due to the case, that the [`meta`-variable is assigned but never used in version 0.0.19](https://github.com/open-webui/mcpo/blob/25b219a99258a356a0fcb2421eb60e3ec4798d70/src/mcpo/utils/main.py#L313). This is a reverted change from version 0.0.18 (see release notes [here](https://github.com/open-webui/mcpo/releases/tag/v0.0.19))
yindo commented 2026-02-15 20:17:57 -05:00
Author
Owner
Copy Link
Copy Source

@GlisseManTV commented on GitHub (Dec 18, 2025):

Should be solved by #273

@GlisseManTV commented on GitHub (Dec 18, 2025): Should be solved by #273
yindo commented 2026-02-15 20:17:57 -05:00
Author
Owner
Copy Link
Copy Source

@Baronco commented on GitHub (Dec 20, 2025):

any news about this bug? I would like to be able to pass the user session authorization bearer token to my MCP

@Baronco commented on GitHub (Dec 20, 2025): any news about this bug? I would like to be able to pass the user session authorization bearer token to my MCP
yindo commented 2026-02-15 20:17:57 -05:00
Author
Owner
Copy Link
Copy Source

@rlaneth commented on GitHub (Jan 19, 2026):

I'm having this issue, too.

While recent versions of Open WebUI have implemented native MCP support, I've found it almost impossible to make it work properly with industry-standard libraries such as Laravel MCP. This matches the warning presented on the web interface itself:

Warning: MCP support is experimental and its specification changes often, which can lead to incompatibilities. OpenAPI specification support is directly maintained by the Open WebUI team, making it the more reliable option for compatibility.

I love Open WebUI, but there's a point to be made about how bad it is currently for integration with external tools. The developers may bring in grandiose claims about how MCP is supposedly "missing standard features" and "is experimental and changes often," but it's very clear that the real reason is NIH.

MCP is an industry-standard that should've been supported to the get-go. It's a consensus in the industry, including Anthropic, Google, even OpenAI. The only ones who seem to find it "not good enough" are the OWU developers who went for the mcpo hack.

As things stand now, we'll have to fork mcpo for internal use so we can work around the problems.

@rlaneth commented on GitHub (Jan 19, 2026): I'm having this issue, too. While recent versions of Open WebUI have implemented native MCP support, I've found it almost impossible to make it work properly with industry-standard libraries such as Laravel MCP. This matches the warning presented on the web interface itself: > Warning: MCP support is experimental and its specification changes often, which can lead to incompatibilities. OpenAPI specification support is directly maintained by the Open WebUI team, making it the more reliable option for compatibility. I love Open WebUI, but there's a point to be made about how bad it is currently for integration with external tools. The developers may bring in grandiose claims about how MCP is supposedly "missing standard features" and "is experimental and changes often," but it's very clear that the real reason is NIH. MCP is an industry-standard that should've been supported to the get-go. It's a consensus in the industry, including Anthropic, Google, even OpenAI. The only ones who seem to find it "not good enough" are the OWU developers who went for the mcpo hack. As things stand now, we'll have to fork mcpo for internal use so we can work around the problems.
yindo commented 2026-02-15 20:17:57 -05:00
Author
Owner
Copy Link
Copy Source

@GlisseManTV commented on GitHub (Jan 19, 2026):

I'm having this issue, too.

While recent versions of Open WebUI have implemented native MCP support, I've found it almost impossible to make it work properly with industry-standard libraries such as Laravel MCP. This matches the warning presented on the web interface itself:

Warning: MCP support is experimental and its specification changes often, which can lead to incompatibilities. OpenAPI specification support is directly maintained by the Open WebUI team, making it the more reliable option for compatibility.

I love Open WebUI, but there's a point to be made about how bad it is currently for integration with external tools. The developers may bring in grandiose claims about how MCP is supposedly "missing standard features" and "is experimental and changes often," but it's very clear that the real reason is NIH.

MCP is an industry-standard that should've been supported to the get-go. It's a consensus in the industry, including Anthropic, Google, even OpenAI. The only ones who seem to find it "not good enough" are the OWU developers who went for the mcpo hack.

As things stand now, we'll have to fork mcpo for internal use so we can work around the problems.

Hi !

that's why for my AIO tool (I have both version streamable Http & builtin mcpo) I forked their integration to implement http headers fw.

Finally, maybe they are waiting from us to avoid using their tool.

@GlisseManTV commented on GitHub (Jan 19, 2026): > I'm having this issue, too. > > While recent versions of Open WebUI have implemented native MCP support, I've found it almost impossible to make it work properly with industry-standard libraries such as Laravel MCP. This matches the warning presented on the web interface itself: > > > Warning: MCP support is experimental and its specification changes often, which can lead to incompatibilities. OpenAPI specification support is directly maintained by the Open WebUI team, making it the more reliable option for compatibility. > > I love Open WebUI, but there's a point to be made about how bad it is currently for integration with external tools. The developers may bring in grandiose claims about how MCP is supposedly "missing standard features" and "is experimental and changes often," but it's very clear that the real reason is NIH. > > MCP is an industry-standard that should've been supported to the get-go. It's a consensus in the industry, including Anthropic, Google, even OpenAI. The only ones who seem to find it "not good enough" are the OWU developers who went for the mcpo hack. > > As things stand now, we'll have to fork mcpo for internal use so we can work around the problems. Hi ! that's why for my AIO tool (I have both version streamable Http & builtin mcpo) I forked their integration to implement http headers fw. Finally, maybe they are waiting from us to avoid using their tool.
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 bug
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#83
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?