[FEATURE]: MCP manager UX - per-server output links (web panel URLs), placeholder prompts with secure secret storage, a full config editor, and richer ask/mention inputs #58243

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

OpenCode v2 (2.1.2) already has a solid MCP layer (opencode mcp auth/list/logout, OAuth auto-flow, {env:VAR} interpolation, per-server toggles), but six daily-use gaps remain. One theme: MCP servers are first-class config citizens in every way except the surfaces a human actually touches - the manager area, the permission UI, and the inputs an agent-driven session asks the user through.

1. Per-server output panel with clickable web links

Many MCP servers ship their own local web UI (a config / DB / browser panel on http://127.0.0.1:<port>). Today the only way a user sees that URL is inside the server's raw stderr stream, which OpenCode logs undifferentiated.

Real example from our setup - codebase-memory-mcp runs through a PowerShell wrapper whose ONLY extra job is printing the panel URL:

"codebase-memory-mcp": {
  "type": "stdio",
  "command": "powershell.exe",
  "args": [
    "-NoProfile", "-Command",
    "[Console]::Error.WriteLine(' Codebase Memory UI:\\n http://127.0.0.1:9749'); & codebase-memory-mcp --ui=true --port=9749"
  ]
}

Request: when OpenCode sees http://localhost / http://127.0.0.1 URLs in an MCP server's stdout/stderr (or when a user-declared links field sitting next to that server's config is present), render them as a per-server, clickable output section in the MCP manager area - filtered per server, not mixed into the global log.

2. Auto-detect config placeholder variables and prompt for them (with secure storage)

Config values today can only interpolate {env:VAR} from the process environment. That fails for anything typed interactively, and it has sharp edges we hit for real:

• Unresolved {env:VAR} silently becomes an empty string instead of an error (config: unresolved {env:VAR} silently becomes an empty string (remote MCP fails with an opaque 401) #53784, closed duplicate) - the server then fails upstream with a confusing 401 that looks like a bad token, when actually the value never existed.
• {env:...} in a remote server's headers was reported not expanded at all (mcp: {env:...} in remote server headers not expanded (401 unauthorized) #56125, closed not planned) even though headers is the most common place a PAT rides - worth closing the inconsistency in one direction or the other.
• The config lane offers no interactive input surface at all, so a keyed remote server either holds its secret in plaintext JSON in the config or cannot be configured portably.

Request: at config parse/adopt time, scan mcp entries for placeholder-style variables; when one is not resolvable from the environment, prompt the user ONCE (named prompt per variable: e.g. "PENPOT_TOKEN - personal access token for penpot"). Store the answers OUTSIDE the plaintext config:

• secrets in the OS keyring, or at minimum a dedicated credentials file under ~/.local/share/opencode/ protected like the OAuth token store (mcp-auth.json) already is;
• and while at it, close the two open secret-leak reports: engine logs must not contain resolved secrets (mcp: server error text can write config secrets into the local engine log #53051) and /api/config must not return resolved credentials (api: /api/model, /api/config and /api/provider/{id} return resolved provider credentials #53465).

3. A full MCP config editor in the UI

opencode mcp list shows connection state and the manager can toggle servers, and the CLI has a one-shot opencode mcp add; but there is no surface to view, edit, validate or manage entries - that is still raw-JSON editing in one of several config locations. Request: an MCP config editor surface (TUI panel and/or web/desktop) that can add/remove/edit entries with the right shape per type (local: command/args/env; remote: url/headers/oauth), validates against the official schema (the non-deprecated mcp.servers.<name> shape; the deprecated flat mcp.<name> still accepted), and writes back through the placeholder-prompts + keystore flows from (2). While in there: the v2 web/desktop MCP permission prompt shows only * for the asked tool (#51519, still open) - surfacing the actual server/tool name would make least-privilege grants possible to express in the UI at all.

Our last stretch of real use (2026-10-20 -> 2026-10-23, Windows, several cooperating agents + one human) made the need concrete: the global config is JSONC (JSON with comments) but there is no schema-aware surface, so validating a hand edit meant stripping comments in a throwaway script and re-parsing; the deprecated flat mcp.<name> vs current mcp.servers.<name> split was discoverable only by reading the ~2.6k-line official schema (opencode.ai/config.json); a mis-edited Authorization header failed at connect time with HTTP 400 Authorization header is badly formatted; an OAuth toggle change drove the client into the auto-DCR flow, which dead-ends with Incompatible auth server: does not support dynamic client registration when the authorization server advertises no registration endpoint; and keyed remote vendors end up holding literal tokens in plaintext because there is nowhere else to put them (item 2). An editor surface that validates the entry shape + placeholders + auth mode BEFORE writing would have short-circuited every one of those.

4. The clarify-question answer input needs input parity with the main input

When an agent asks the user a question (the ask/clarify tool), the answer box is a weaker input than the main chat input:

• Newlines: the main input inserts a newline with Ctrl+Enter; the answer box does not, so multi-line answers ("paste the whole log line") get mangled.
• File mentions: the main input supports @-tagging files; the answer box does not, so answering with a file becomes copy-paste work.

Request: give the answer box the same input component - Ctrl+Enter newline and @ file tagging.

5. #-mention in the main input to tag a tool / an MCP server / one MCP tool

The inverse of the @ mention: typing # in the main input should offer the agent-visible tool space:

• a specific tool (#read),
• a whole MCP server (#context7 = all of its tools),
• one tool of one server (#context7.resolve-library-id).

The mention should reach the agent as a scoped directive (e.g. an extra field on the user message: "the user pinned these tools for this request"), not just a UI chip the runtime consumed silently. Use cases: force a specific tool for a step ("now use #chrome-devtools.take_screenshot"), or pin a task to a server's toolbox in sessions where 200+ tools are in scope and name-similarity makes the agent pick wrong or waffle.

6. CLI/config-manager consistency and failure diagnosability

All measured on v2.1.2: a correctly shaped config-lane entry (mcp.servers.<name> in the global config), and one failing stdio server:

• opencode mcp list does not list config-file (global) servers at all, only workspace-registry ones - while the running session discovers and serves that same server fine, so server discovery is session-level but missing at CLI level; the CLI even advertises mcp add --global for writing global entries it cannot then display or authenticate.
• opencode mcp auth <name> for that server answers MCP server not found (and bare mcp auth list answers MCP server not found: list), even though auth/logout/list are the natural lifecycle commands over a central OAuth token store.
• mcp debug <name>, documented in official install guides (github/github-mcp-server's OpenCode guide says "run opencode mcp debug github to see the exact connectivity and auth diagnostics" - github.com/github/github-mcp-server/blob/main/docs/installation-guides/install-opencode.md), does not exist in the binary (Unknown subcommand, re-verified 2026-10-23; mcp --help lists only list/add/auth/logout) - when a server misbehaves, no diagnostic route is left.
• When a stdio server fails, mcp list truncates that server's stderr right after the first exception block, cutting off the chained original exception (Python prints it last) - the user sees only the mislabeled wrapper error, never the real cause.
• A server that times out during mcp list keeps running: timed-out spawns stayed alive under the live service after the run, so the next probe hit the same hang again.

Request: make the mcp CLI subcommands config-file-aware (or explicitly scope-labelled), ship the documented debug subcommand, and keep a failing server's trailing stderr visible (e.g. the last N lines, chained cause intact) and its timed-out spawn reaped.

Why is this needed?

Three cooperating agents and one human share MCP registries on this machine (VS Code + OpenCode harnesses over a shared .mcp.json; keyed servers bind environment slots). In one week every gap above was hit for real:

• a placeholder silently resolved to an empty string and produced a 401 that looked like a bad token;
• one server had to be hand-moved from a workspace registry into the global config by JSON editing because no UI surface manages MCP entries;
• per-server web-panel URLs had to be hand-wrapped into stderr just to become visible;
• the configuration pain: a JSONC config validated only by stripping comments through throwaway parsers, a connect-time HTTP 400 Authorization header is badly formatted from one hand edit, the OAuth auto-flow dead-ending at Incompatible auth server: does not support dynamic client registration, and plaintext tokens parked in the config for lack of a keystore surface;
• multi-line answers to agent questions broke on the answer box;
• a correctly configured global-config server was invisible to the CLI (opencode mcp list omitted it, opencode mcp auth answered MCP server not found), while the running session discovered it fine.

The building blocks already exist (the OAuth token store with its protected mcp-auth.json, {env:} interpolation, the manager toggles) - this unifies them into the UX they already imply.

Related issues

• mcp: {env:...} in remote server headers not expanded (401 unauthorized) #56125 - {env:...} in remote server headers not expanded (closed, not planned)
• config: unresolved {env:VAR} silently becomes an empty string (remote MCP fails with an opaque 401) #53784 - unresolved {env:VAR} silently becomes an empty string (closed, duplicate)
• mcp: server error text can write config secrets into the local engine log #53051 - config secrets leak into the local engine log
• api: /api/model, /api/config and /api/provider/{id} return resolved provider credentials #53465 - /api/config returns resolved credentials
• [FEATURE]: trigger MCP authentication from the ACP client #55048 - trigger MCP auth flow from an ACP client
• [FEATURE]: MCP OAuth paste-code fallback for headless/SSH sessions #54495 - OAuth fallback for pasting an auth code
• v2 web/desktop: MCP permission prompt shows only *, not the tool name #51519 - v2 web/desktop: MCP permission prompt shows only *, not the tool name (open; item 3 covers it)

Additional context

• opencode v2.1.2, Windows 11, PowerShell.
• Config keys verified against the official schema (https://opencode.ai/config.json, fetched 2026-10-22) and the MCP docs (https://opencode.ai/docs/mcp-servers/, fetched 2026-10-22).