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

issue: Application startup failed. Exiting. #96

New Issue
Closed
opened 2026-02-15 20:18:03 -05:00 by yindo · 2 comments
yindo commented 2026-02-15 20:18:03 -05:00
Owner
Copy Link
Copy Source

Originally created by @Pomfe on GitHub (Jul 15, 2025).

config.json

Check Existing Issues

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

mcpo Version

latest using "pip install mcpo"

Open WebUI Version (if applicable)

No response

Operating System

Windows 11 (system + docker)

Browser (if applicable)

No response

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

The mcpo server should start successfully and listen on the configured port (8000), even when all mcpServers are disabled in the config.json. In this state, it should ideally expose only its own internal API (e.g., /docs).

Actual Behavior

The mcpo server fails to start, and the console outputs the following error traceback consistently:

Steps to Reproduce

Create a new Python virtual environment using uv venv.

Activate the virtual environment.

Install mcpo: pip install mcpo

Use the attached config.json file (which has all mcpServers entries set to "disabled": true).

Attempt to start the mcpo server using the command:
mcpo --config "H:\browserui\MCPO config\config.json"

Logs & Screenshots

ERROR: + Exception Group Traceback (most recent call last):
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\starlette\routing.py", line 694, in lifespan
| async with self.lifespan_context(app) as maybe_state:
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\contextlib.py", line 210, in aenter
| return await anext(self.gen)
| ^^^^^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 101, in lifespan
| await stack.enter_async_context(
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\contextlib.py", line 659, in enter_async_context
| result = await enter(cm)
| ^^^^^^^^^^^^^^^^
| File "C:\Users\jonba\AppData\Local\Programs\Python\Python312\Lib\contextlib.py", line 210, in aenter
| return await anext(self.gen)
| ^^^^^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 113, in lifespan
| async with stdio_client(server_params) as (reader, writer):
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\contextlib.py", line 231, in aexit
| await self.gen.athrow(value)
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcp\client\stdio_init_.py", line 181, in stdio_client
| anyio.create_task_group() as tg,
| ^^^^^^^^^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\anyio_backends_asyncio.py", line 772, in aexit
| raise BaseExceptionGroup(
| ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
+-+---------------- 1 ----------------
| Exception Group Traceback (most recent call last):
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcp\client\stdio_init_.py", line 187, in stdio_client
| yield read_stream, write_stream
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 114, in lifespan
| async with ClientSession(reader, writer) as session:
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcp\shared\session.py", line 218, in aexit
| return await self.task_group.aexit(exc_type, exc_val, exc_tb)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba\AppData\Local\Programs\Python\Python312\Lib\site-packages\anyio_backends_asyncio.py", line 772, in aexit
| raise BaseExceptionGroup(
| ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
+-+---------------- 1 ----------------
| Traceback (most recent call last):
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 116, in lifespan
| await create_dynamic_endpoints(app, api_dependency=api_dependency)
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 52, in create_dynamic_endpoints
| form_model_fields = get_model_fields(
| ^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\utils\main.py", line 236, in get_model_fields
| python_type_hint, pydantic_field_info = process_schema_property(
| ^^^^^^^^^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\utils\main.py", line 166, in _process_schema_property
| nested_type_hint, nested_pydantic_field = process_schema_property(
| ^^^^^^^^^^^^^^^^^^^^^^^^^
| File "C:\Users\jonba\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\utils\main.py", line 112, in _process_schema_property
| assert ref in schema_defs, "Custom field not found"
| ^^^^^^^^^^^^^^^^^^
| AssertionError: Custom field not found
+------------------------------------

ERROR: Application startup failed. Exiting.

Additional Information

https://g.co/gemini/share/325fef6c8e88

I was going back and forth with Gemini for a bit, I hope this provides some insight

ps: I was also getting this same error both running it through my windows console (using Cmder) and Docker

Originally created by @Pomfe on GitHub (Jul 15, 2025). [config.json](https://github.com/user-attachments/files/21246847/config.json) ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of mcpo. ### mcpo Version latest using "pip install mcpo" ### Open WebUI Version (if applicable) _No response_ ### Operating System Windows 11 (system + docker) ### Browser (if applicable) _No response_ ### 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 The mcpo server should start successfully and listen on the configured port (8000), even when all mcpServers are disabled in the config.json. In this state, it should ideally expose only its own internal API (e.g., /docs). ### Actual Behavior The mcpo server fails to start, and the console outputs the following error traceback consistently: ### Steps to Reproduce Create a new Python virtual environment using uv venv. Activate the virtual environment. Install mcpo: pip install mcpo Use the attached config.json file (which has all mcpServers entries set to "disabled": true). Attempt to start the mcpo server using the command: mcpo --config "H:\browserui\MCPO config\config.json" ### Logs & Screenshots ERROR: + Exception Group Traceback (most recent call last): | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\starlette\routing.py", line 694, in lifespan | async with self.lifespan_context(app) as maybe_state: | ^^^^^^^^^^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\contextlib.py", line 210, in __aenter__ | return await anext(self.gen) | ^^^^^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 101, in lifespan | await stack.enter_async_context( | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\contextlib.py", line 659, in enter_async_context | result = await _enter(cm) | ^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\contextlib.py", line 210, in __aenter__ | return await anext(self.gen) | ^^^^^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 113, in lifespan | async with stdio_client(server_params) as (reader, writer): | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\contextlib.py", line 231, in __aexit__ | await self.gen.athrow(value) | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcp\client\stdio\__init__.py", line 181, in stdio_client | anyio.create_task_group() as tg, | ^^^^^^^^^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\anyio\_backends\_asyncio.py", line 772, in __aexit__ | raise BaseExceptionGroup( | ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception) +-+---------------- 1 ---------------- | Exception Group Traceback (most recent call last): | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcp\client\stdio\__init__.py", line 187, in stdio_client | yield read_stream, write_stream | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 114, in lifespan | async with ClientSession(reader, writer) as session: | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcp\shared\session.py", line 218, in __aexit__ | return await self._task_group.__aexit__(exc_type, exc_val, exc_tb) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\anyio\_backends\_asyncio.py", line 772, in __aexit__ | raise BaseExceptionGroup( | ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception) +-+---------------- 1 ---------------- | Traceback (most recent call last): | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 116, in lifespan | await create_dynamic_endpoints(app, api_dependency=api_dependency) | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\main.py", line 52, in create_dynamic_endpoints | form_model_fields = get_model_fields( | ^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\utils\main.py", line 236, in get_model_fields | python_type_hint, pydantic_field_info = _process_schema_property( | ^^^^^^^^^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\utils\main.py", line 166, in _process_schema_property | nested_type_hint, nested_pydantic_field = _process_schema_property( | ^^^^^^^^^^^^^^^^^^^^^^^^^ | File "C:\Users\jonba_\AppData\Local\Programs\Python\Python312\Lib\site-packages\mcpo\utils\main.py", line 112, in _process_schema_property | assert ref in schema_defs, "Custom field not found" | ^^^^^^^^^^^^^^^^^^ | AssertionError: Custom field not found +------------------------------------ ERROR: Application startup failed. Exiting. ### Additional Information https://g.co/gemini/share/325fef6c8e88 I was going back and forth with Gemini for a bit, I hope this provides some insight ps: I was also getting this same error both running it through my windows console (using Cmder) and Docker
yindo added the bug label 2026-02-15 20:18:03 -05:00
yindo closed this issue 2026-02-15 20:18:03 -05:00
yindo commented 2026-02-15 20:18:04 -05:00
Author
Owner
Copy Link
Copy Source

@trkjoy commented on GitHub (Jul 16, 2025):

I'm also having the same problem, the program won't start

@trkjoy commented on GitHub (Jul 16, 2025): I'm also having the same problem, the program won't start
yindo commented 2026-02-15 20:18:04 -05:00
Author
Owner
Copy Link
Copy Source

@Pomfe commented on GitHub (Jul 16, 2025):

Here’s your postmortem on the three MCP servers that failed to launch during MCPO startup. I’ll break down each one with detailed reasoning, based on your traces and environment:

❌ 1. windows-mcp

Config Entry:

"command": "C:\\Users\\jonba_\\.local\\bin\\uv.exe",
"args": ["--directory", "H:\\browserui\\CursorTouch\\Windows-MCP-main", "run", "server.py"]

Why It Failed:

  • Launch mechanism is Windows-specific: The command uses uv.exe, a binary that likely doesn’t execute properly inside MCPO’s async subprocess handler. MCPO expects stdio-compatible tools it can communicate with — uv.exe might not wire its output through stdin/stdout as needed.

  • Directory-based startup: The --directory flag suggests it's trying to set context before invoking server.py, but your logs didn’t show MCPO finding or invoking a Python server from that path.

  • Crash symptom: MCPO threw unhandled errors in a TaskGroup, which typically means the subprocess terminated before returning a usable schema. The chain of __aexit__ → stdio_client → read_stream/write_stream errors confirms no I/O was established.

❌ 2. anilist

Config Entry:

"command": "npx",
"args": ["-y", "anilist-mcp"]

Why It Failed:

  • Schema parsing bug: anilist-mcp is known to return a dynamic OpenAPI schema with $ref references to properties that aren't defined. That breaks MCPO’s schema processor, especially in create_dynamic_endpoints() where it calls _process_schema_property().

  • Assertion error: Your original Docker trace included AssertionError: Custom field not found, confirming this exact issue. The schema references a field it doesn’t define, which causes a cascade of nested ExceptionGroup errors.

  • Result: MCPO aborts startup while trying to expose API docs for this tool.

❌ 3. github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking

Config Entry:

"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]

Why It Failed:

  • Nested schema complexity: Like anilist, this tool likely returns a schema with deep object nesting or unresolved $ref fields. MCPO tries to parse it for endpoint generation and stumbles when expected definitions are missing.

  • Failure mode: You saw the same TaskGroup crash pattern as with anilist, which implies MCPO couldn’t negotiate startup with the MCP process cleanly.

  • Lack of internal logging: There wasn’t a helpful trace from the MCP tool itself, which usually indicates it exited silently before MCPO could bind I/O.

💡 General Pattern: Why These Break MCPO

These three MCP servers share traits that trip MCPO:

  • They generate dynamic schemas at runtime, rather than static, simple ones.
  • Their schemas contain $ref links or deep nesting MCPO can't resolve without full internal schema definitions.
  • They may exit early or lack stdio-compatible communication, which MCPO relies on for initialization.

MCPO parses every tool’s schema to autogenerate API endpoints — if that schema is broken, incomplete, or unreachable, it halts startup completely.

I'm going to close this because Microsoft's Copilot app led me to this conclusion and I have successfully been able to run the server without these 3 entries. What you see above is verbatim from Copilot and nothing was changed by me.

@Pomfe commented on GitHub (Jul 16, 2025): Here’s your postmortem on the three MCP servers that failed to launch during MCPO startup. I’ll break down each one with detailed reasoning, based on your traces and environment: --- ### ❌ 1. `windows-mcp` **Config Entry:** ```json "command": "C:\\Users\\jonba_\\.local\\bin\\uv.exe", "args": ["--directory", "H:\\browserui\\CursorTouch\\Windows-MCP-main", "run", "server.py"] ``` **Why It Failed:** - **Launch mechanism is Windows-specific**: The command uses `uv.exe`, a binary that likely doesn’t execute properly inside MCPO’s async subprocess handler. MCPO expects `stdio`-compatible tools it can communicate with — `uv.exe` might not wire its output through `stdin/stdout` as needed. - **Directory-based startup**: The `--directory` flag suggests it's trying to set context before invoking `server.py`, but your logs didn’t show MCPO finding or invoking a Python server from that path. - **Crash symptom**: MCPO threw `unhandled errors in a TaskGroup`, which typically means the subprocess terminated before returning a usable schema. The chain of `__aexit__ → stdio_client → read_stream/write_stream` errors confirms no I/O was established. --- ### ❌ 2. `anilist` **Config Entry:** ```json "command": "npx", "args": ["-y", "anilist-mcp"] ``` **Why It Failed:** - **Schema parsing bug**: `anilist-mcp` is known to return a dynamic OpenAPI schema with `$ref` references to properties that aren't defined. That breaks MCPO’s schema processor, especially in `create_dynamic_endpoints()` where it calls `_process_schema_property()`. - **Assertion error**: Your original Docker trace included `AssertionError: Custom field not found`, confirming this exact issue. The schema references a field it doesn’t define, which causes a cascade of nested `ExceptionGroup` errors. - **Result**: MCPO aborts startup while trying to expose API docs for this tool. --- ### ❌ 3. `github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking` **Config Entry:** ```json "command": "npx", "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"] ``` **Why It Failed:** - **Nested schema complexity**: Like `anilist`, this tool likely returns a schema with deep object nesting or unresolved `$ref` fields. MCPO tries to parse it for endpoint generation and stumbles when expected definitions are missing. - **Failure mode**: You saw the same `TaskGroup` crash pattern as with `anilist`, which implies MCPO couldn’t negotiate startup with the MCP process cleanly. - **Lack of internal logging**: There wasn’t a helpful trace from the MCP tool itself, which usually indicates it exited silently before MCPO could bind I/O. --- ### 💡 General Pattern: Why These Break MCPO These three MCP servers share traits that trip MCPO: - They generate **dynamic schemas at runtime**, rather than static, simple ones. - Their schemas contain `$ref` links or deep nesting MCPO can't resolve without full internal schema definitions. - They may exit early or lack `stdio`-compatible communication, which MCPO relies on for initialization. MCPO parses every tool’s schema to autogenerate API endpoints — if that schema is broken, incomplete, or unreachable, it halts startup completely. --- I'm going to close this because Microsoft's Copilot app led me to this conclusion and I have successfully been able to run the server without these 3 entries. What you see above is verbatim from Copilot and nothing was changed by me.
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#96
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?