open-webui/computer

Fork 0

mirror of https://github.com/open-webui/computer.git synced 2026-11-05 01:17:24 +00:00

[GH-ISSUE #201] feat: stdio MCP tool servers need an env variables field in the UI (branch with fix available) #120

New issue

Closed

opened 2026-10-18 14:03:07 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-18 14:03:07 +00:00

Owner

Originally created by @paoloviviani on GitHub (Jul 29, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/201

Description

Stdio MCP tool servers typically need environment variables for
authentication (e.g. MAIL_TOKEN for @infomaniak/mcp-server-mail,
GITHUB_TOKEN for the GitHub MCP server). The backend already supports a
per-server env dict end-to-end (CreateToolServerRequest.env,
update_tool_server, MCPClient.connect_stdio(..., env, cwd)), but the
Admin → Tool Servers dialog only renders Command / Arguments / Working
Directory for mcp_stdio servers — there is no way to enter env vars
from the UI.

Environment

CPTR version: 0.9.15, running as a user systemd service
Host: Linux (Ubuntu, headless)
MCP server: npx -y @infomaniak/mcp-server-mail (needs MAIL_TOKEN)

Steps to reproduce

Admin → Tool Servers → Add Server, type MCP (Stdio).
Fill in: id ikmail, command npx, arguments
-y @infomaniak/mcp-server-mail. Note there is no env field.
Save, then Verify → generic HTTP 400 (“Bad Request”).

The server's own stderr (Please set MAIL_TOKEN environment variable)
never reaches the log or the response, so the failure is opaque.

Workarounds that do NOT work

Setting the variable on the cptr process itself
(Environment=MAIL_TOKEN=... in the systemd unit): the MCP Python SDK
deliberately restricts the environment a stdio child inherits to
HOME LOGNAME PATH SHELL TERM USER plus whatever is in
server.env (see mcp/client/stdio/__init__.py,
get_default_environment() / env={**get_default_environment(), **server.env}).
cptr's own process env is discarded, so the child never sees it.
Writing env directly into the config store: works until you open
the server again in the UI and hit Save — the form always submits the
full record and, having no env field, writes env: null, silently
wiping the value.

Expected behavior

The stdio tool server form exposes an environment variables field that
round-trips env through create/edit/save, like the existing Headers
field does for HTTP servers.

Fix available

I implemented this on my fork, branch feat/stdio-mcp-env
(commit 22d96e7):

Fork: https://github.com/paoloviviani/computer/tree/feat/stdio-mcp-env
Diff vs upstream main: https://github.com/paoloviviani/computer/compare/main...feat/stdio-mcp-env

Contents:

cptr/frontend/src/lib/components/Admin/ToolServers.svelte: new
formEnv state + JSON textarea on the stdio form (mirrors the Headers
field UX), JSON-object validation with a dedicated toast, env included
in the create/update payload so saves no longer null it out.
All 10 locale files: toolServers.env / toolServers.envHint /
toolServers.envInvalid.
No backend changes needed — the wire format and spawn path already
accept env.

Verified: Prettier clean, vite build succeeds, svelte-check shows no
new diagnostics over the existing baseline, and an end-to-end verify
against @infomaniak/mcp-server-mail with MAIL_TOKEN entered through
the new field succeeds (20 tools listed).

(I could not open a pull request from the fork, so opening this issue
instead — happy to adjust or rebase if a maintainer wants to pick the
branch up, or to open the PR differently if preferred.)

#64 — MCP stdio support (backend half this complements)
#62 — silent MCP failures; making stderr visible in the verify response
would have made this much easier to diagnose

Originally created by @paoloviviani on GitHub (Jul 29, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/201 ## Description Stdio MCP tool servers typically need environment variables for authentication (e.g. `MAIL_TOKEN` for `@infomaniak/mcp-server-mail`, `GITHUB_TOKEN` for the GitHub MCP server). The backend already supports a per-server `env` dict end-to-end (`CreateToolServerRequest.env`, `update_tool_server`, `MCPClient.connect_stdio(..., env, cwd)`), but the Admin → Tool Servers dialog only renders Command / Arguments / Working Directory for `mcp_stdio` servers — there is no way to enter env vars from the UI. ## Environment - CPTR version: 0.9.15, running as a user systemd service - Host: Linux (Ubuntu, headless) - MCP server: `npx -y @infomaniak/mcp-server-mail` (needs `MAIL_TOKEN`) ## Steps to reproduce 1. Admin → Tool Servers → Add Server, type **MCP (Stdio)**. 2. Fill in: id `ikmail`, command `npx`, arguments `-y @infomaniak/mcp-server-mail`. Note there is no env field. 3. Save, then **Verify** → generic HTTP 400 (“Bad Request”). The server's own stderr (`Please set MAIL_TOKEN environment variable`) never reaches the log or the response, so the failure is opaque. ### Workarounds that do NOT work - **Setting the variable on the cptr process itself** (`Environment=MAIL_TOKEN=...` in the systemd unit): the MCP Python SDK deliberately restricts the environment a stdio child inherits to `HOME LOGNAME PATH SHELL TERM USER` plus whatever is in `server.env` (see `mcp/client/stdio/__init__.py`, `get_default_environment()` / `env={**get_default_environment(), **server.env}`). cptr's own process env is discarded, so the child never sees it. - **Writing `env` directly into the config store**: works until you open the server again in the UI and hit Save — the form always submits the full record and, having no env field, writes `env: null`, silently wiping the value. ## Expected behavior The stdio tool server form exposes an environment variables field that round-trips `env` through create/edit/save, like the existing Headers field does for HTTP servers. ## Fix available I implemented this on my fork, branch **`feat/stdio-mcp-env`** (commit `22d96e7`): - Fork: https://github.com/paoloviviani/computer/tree/feat/stdio-mcp-env - Diff vs upstream main: https://github.com/paoloviviani/computer/compare/main...feat/stdio-mcp-env Contents: - `cptr/frontend/src/lib/components/Admin/ToolServers.svelte`: new `formEnv` state + JSON textarea on the stdio form (mirrors the Headers field UX), JSON-object validation with a dedicated toast, `env` included in the create/update payload so saves no longer null it out. - All 10 locale files: `toolServers.env` / `toolServers.envHint` / `toolServers.envInvalid`. - No backend changes needed — the wire format and spawn path already accept `env`. Verified: Prettier clean, `vite build` succeeds, `svelte-check` shows no new diagnostics over the existing baseline, and an end-to-end verify against `@infomaniak/mcp-server-mail` with `MAIL_TOKEN` entered through the new field succeeds (20 tools listed). (I could not open a pull request from the fork, so opening this issue instead — happy to adjust or rebase if a maintainer wants to pick the branch up, or to open the PR differently if preferred.) ## Related - #64 — MCP stdio support (backend half this complements) - #62 — silent MCP failures; making stderr visible in the verify response would have made this much easier to diagnose

bsakaguchi closed this issue

2026-10-18 14:03:07 +00:00

bsakaguchi commented

2026-10-18 14:03:08 +00:00

Author

Owner

@owui-terminator[bot] commented on GitHub (Jul 29, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

🟣 #64 MCP STDIO Support
This is the foundational MCP stdio support issue and directly overlaps with the stdio tool-server workflow this bug report extends. The new issue is specifically about completing the stdio UI by adding env var support on top of the existing stdio backend/UI work.
by Classic298
🟣 #62 MCP optional extra not installed in Docker image — MCP tool servers fail silently out of the box
This issue is about MCP tool servers failing silently during Verify, which matches the user-visible symptom described here (generic 400 / opaque failure). While the root cause differs, it is closely related because both concern diagnosing stdio/MCP verify failures and improving usability.
by root-hal9000

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (Jul 29, 2026):  🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#64](https://github.com/open-webui/computer/issues/64) **MCP STDIO Support** *This is the foundational MCP stdio support issue and directly overlaps with the stdio tool-server workflow this bug report extends. The new issue is specifically about completing the stdio UI by adding env var support on top of the existing stdio backend/UI work.* *by Classic298* 2. 🟣 [#62](https://github.com/open-webui/computer/issues/62) **MCP optional extra not installed in Docker image — MCP tool servers fail silently out of the box** *This issue is about MCP tool servers failing silently during Verify, which matches the user-visible symptom described here (generic 400 / opaque failure). While the root cause differs, it is closely related because both concern diagnosing stdio/MCP verify failures and improving usability.* *by root-hal9000* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

bsakaguchi commented

2026-10-18 14:03:08 +00:00

Author

Owner

@tjbck commented on GitHub (Jul 31, 2026):

Addressed!

@tjbck commented on GitHub (Jul 31, 2026): Addressed!

No labels

enhancement

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/computer#120

No description provided.

Rows
Columns