[FEATURE]: MCP manager - a schema-aware MCP config editor surface #58654

Activity

1. opencode-agent commented on Oct 24, 2026

   

   opencode-agentBot

   on Oct 24, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for splitting this out of #58243! In short, you're asking for an MCP config editor in the TUI and/or desktop/web. It would add, remove and edit local and remote servers with the right fields for each type and validate them against the official schema, accepting both mcp.servers and the deprecated flat form. It would show which config file each server comes from (global or project) and the merged result, and write secrets through the placeholder/credential flow. Maintainers will consider it.

   Related issues you may want to follow:

   • [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: the parent request
   • [FEATURE]: MCP config - prompt for unresolved placeholder values and store the secrets outside the config #58653: placeholder prompts and secret storage, which this editor would write through
   • [FEATURE]: MCP manager - per-server output panel with clickable local panel URLs #58652: the per-server output panel, the other split-out item
   • feat(cli): add MCP server removal #56086 / [FEATURE]: MCP remove command #49812: CLI support for removing MCP servers
   • [FEATURE]: Desktop MCP panel is unmanageable with 20+ servers — add collapse / grouping / internal scroll / bulk enable #51305: managing many servers in the desktop MCP panel
   • feat(app): add an Extensions side tab and split the Context tab into sections #57898: proposed Extensions side tab in the app
   • [Feature Request]: Desktop app needs GUI for managing plugins and LSP servers, plus visible load-failure errors #41037: desktop GUI for managing plugins and LSP servers
   • fix(tui): warn when CLI config is invalid #56335: warning when the config is invalid
   • mcp: Windows service registers zero MCP servers from global config #50710: global-config servers not registered by the Windows service
   • v2 web/desktop: MCP permission prompt shows only *, not the tool name #51519: the MCP permission prompt shows only *
2. Dante-dan commented on Oct 24, 2026

   

   Dante-dan

   on Oct 24, 2026

   Contributor

   More actions

   For a first phase, I'd suggest a TUI MCP editor with a source-aware merged server list, rather than spreading the same new editing flow across several UI surfaces at once.

   The list would show the effective global/project entry and its originating config document; overridden entries remain inspectable. Add/edit/remove would target an explicitly selected writable source, with a preview when removing a project override would expose a global entry. A read-only source would be shown as such rather than rewritten elsewhere silently.

   The form would use the current schema's local/remote discriminated fields and validate before save. Requested fields absent from that schema would need a separate schema decision, not an editor-only promise. Existing legacy entries would remain readable with a migration warning/preview; opening the editor would not automatically migrate them. JSONC writes would change only the selected server node, preserving comments and unrelated fields; detect external edits before committing an atomic write and report errors without corrupting the file.

   Credentials would stay as references and use the approved #58653 secret flow; until that contract is approved, the editor should not introduce plaintext secret entry/storage as a shortcut. Connection toggling and permission grants remain separate from editing server definitions.

   Current source gives this a concrete boundary: mcp.servers contains the local/remote union. Local command is an argv array and the environment field is environment (rather than separate args / env fields); timeout is structured. The existing normalizer handles legacy flat input, while new saves should use the current schema. I would reuse that validation/normalization contract instead of maintaining a separate editor schema.

   Planned acceptance checks: global/project precedence and provenance; local/remote/disabled entries; invalid-field errors; legacy migration preview; JSONC comment/unrelated-field round-trip; external-edit conflict; unwritable source; secret redaction. The list must distinguish saved config from a connection failure so a failed server remains editable.

   Would you approve TUI-only as the first surface, with desktop/web following separately after this editing and secret-reference contract is agreed? This is a design proposal from source inspection; no editor implementation or validation result is claimed.