Repository navigation
[FEATURE]: MCP manager - per-server output panel with clickable local panel URLs #58652
Description
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Many MCP servers ship their own local web UI and print its URL to stdout/stderr on startup
(a config panel, a DB browser, a graph UI). OpenCode logs that stream undifferentiated, so the
only way a user ever sees the URL is by scrolling the global MCP log with several servers'
lines interleaved.
Real case from our setup: codebase-memory-mcp runs through a PowerShell wrapper whose only
extra job is to print the panel URL, because nothing else surfaces it:
"codebase-memory-mcp": {
"type": "local",
"command": [
"powershell.exe", "-NoProfile", "-Command",
"[Console]::Error.WriteLine(' Codebase Memory UI:\n http://127.0.0.1:9749'); & codebase-memory-mcp --ui=true --port=9749"
]
}Request: render http://localhost / http://127.0.0.1 URLs found in a server's stdout/stderr -
or declared through an optional links field next to that server's config - as a per-server,
clickable output section in the MCP manager area (/mcps and the desktop/web MCP panel),
filtered per server instead of mixed into the global log. Keeping the last N lines of that
server's own output there would also solve the debug problem raised in #50710, where a failing
server's stderr is truncated before the chained cause.
Why is this needed?
Three cooperating agents and one human share ~30 MCP servers on this machine; four of them
expose local panels. Today those URLs are copy-pasted out of a raw log, and one config carries
a wrapper that exists purely to make its URL visible - a workaround that only works because we
control that config file.
Related issues
- [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 (parent feature request: MCP manager UX)
- mcp: Windows service registers zero MCP servers from global config #50710 (global-config servers invisible to the CLI / Windows service)
Additional context
- opencode v2.1.4, Windows 11, PowerShell; CLI surface and official MCP reference measured/read 2026-10-24.
- Split out of [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 (item 1) following the triage bot's mapping.
Activity
opencode-agent commentedon Oct 24, 2026
Thanks for splitting this out of #58243! You're asking for the MCP manager (
/mcpsin the TUI and the desktop/web MCP panel) to show each local server's own recent stdout/stderr, filtered to that server. Anyhttp://localhost/http://127.0.0.1URLs in that output, or declared in an optionallinksfield in the server config, would be clickable. That way you don't have to dig local panel URLs out of the global log or print them from a wrapper script. Maintainers will consider it.At the moment a local MCP server's stderr goes only to the debug log. A short tail is kept only to explain an unexpected exit. Plugins can't read that output or add to the MCP manager, so a plugin can't do this today.
Related issues:
arin8513 commentedon Oct 24, 2026
Clarifying the user-facing intent of this request, because that is the part that matters in practice.
The point is not only that the panel URL appears somewhere log-like - it is that a user who runs an MCP server sees that server's own panel link inside the manager surface and can click it, in the same places a user already manages servers: the TUI manager and the desktop/web MCP panel (
/mcpsincluded). Clicking it should open the panel the way any other link in the app opens - no copy-pasting out of a log stream, and no wrapper hack like the one in the config example.Concretely, per server:
This is item 1 of #58243, split out per the triage bot's suggestion; the same wording ("the user sees it and clicks it") applies to the desktop and web clients, not only a terminal log pane.
arin8513 commentedon Oct 29, 2026
Surface proposal: an
Outputlauncher beside Review / Terminal / Open fileFollowing the duplicate note on #60248, here is the one thing that issue added on top of this request - carried here so the discussion stays in one place.
The data stays exactly as this issue describes it
Per-server stdout/stderr tail, every
http://localhost/http://127.0.0.1URL in it rendered as a clickable link, and an optionallinksfield next to that server's config for servers that print nothing. Nothing here changes that ask.The open question is WHERE it lives
This issue places the output in the MCP manager area (
/mcps, desktop/web MCP panel). We would like to propose the alternative - and let a maintainer choose:A fourth launcher in the session side region, beside the three existing ones - Review, Terminal, Open file - named
Output(Ctrl+Alt+Oin the v2 web UI).The
Outputtab would show one collapsible section per MCP server:localhost/127.0.0.1URL in that output, as a clickable link that opens in the OS default browserWhy this surface: the three existing launchers are where a user already looks while working inside a session, and a panel URL is a session-time thing - you want it next to the terminal you are already reading, not behind a settings entry. The MCP manager area stays the place to configure servers;
Outputis the place to watch them.Offer to implement
We are happy to implement this as a PR against
anomalyco/opencode, followingCONTRIBUTING.mdand the existing side-panel patterns, with tests. Two decisions we need before starting:Outputlauncher in the session side region, or per-server output inside the existing/mcpsarea?Related: #58243 (closed umbrella), #50710 (a failing server's stderr truncated before the chained cause), #58653 / #58654 (sibling asks, which stay separate).
arin8513 commentedon Oct 29, 2026
@Tarquinen - a nudge on the two decisions in the comment above, since this is now the only thread for this ask (the duplicate #60248 is closed and its surface proposal was carried here).
Short version: the data is this issue's original ask; the open questions are where it lives and whether we should build it.
We would rather not sit on a decision, so our plan is to work on it ourselves and open a PR against
anomalyco/opencode: theOutputside-region launcher, followingCONTRIBUTING.mdand the existing panel patterns, with tests.Outputlauncher in the session side region acceptable, or would you rather keep this inside/mcps?One honest note on what is buildable outside your tree today: a GUI plugin (
./gui-experimental) can add a tab to the session side region and open links withctx.system.openExternal- that part we already run locally. What a plugin cannot do is read a local server's stdout/stderr or contribute to the MCP manager, which is exactly the part that needs this change. So the PR would be the real fix; the plugin is only a stand-in.If you would rather not take it, say so and we will keep it as a local plugin and stop nudging.
neriousy commentedon Nov 12, 2026
Thanks for the detailed proposal. This isn't something we plan to build, so closing to keep the tracker focused.