[Feature]: Guided/inline MCP server configuration UI (discussion)

### Problem or use case

Orca's current MCP support (Settings → MCP Configs) is inspect-and-open only: it detects existing config files (workspace `.mcp.json`, Cursor's config, Claude's config), shows which servers are defined and their transport (stdio/http) and status, but the only "write" action is creating an empty starter `.mcp.json` that you then hand-edit as raw JSON. Adding, removing, or toggling a specific MCP server — or configuring one from scratch — still means leaving Settings, knowing which config file format your target agent actually reads, and hand-writing JSON in a terminal or editor.

### Proposed solution

I'd like to ask whether extending this toward a more guided, in-app flow fits Orca's direction — before anyone (including me) proposes an implementation.

Two references for what I mean, not a spec:

1. Another tool I use (OpenDesign) has an MCP settings page that, per selected agent CLI, generates a ready-to-copy command for wiring up its MCP server. Still copy-paste-to-terminal, but the exact command is generated for you instead of hand-assembled. (I don't have a current screenshot of this one handy — happy to add it if useful.)

2. Orca's own "Orchestration" skill pane already goes further than that: a status card (install status, per-agent coverage badges), Install/Re-check buttons, and a "Copy install command" affordance for the equivalent CLI command, without leaving Settings or opening an external terminal.


A future guided flow could reduce shell and raw-JSON work along these lines, subject to an explicit target-selection, editing, and execution-safety model — not a commitment to a specific implementation.

I know this raises real questions I don't have answers to, and I'd rather ask than assume:
- **Target ambiguity**: `McpConfigSection` already reads from multiple possible config files/formats (workspace, Cursor, Claude). A write UI would need the user to explicitly pick which file/agent/scope they're editing — auto-picking one would be surprising. This includes locality, not just format: a server config may be local-client, workspace, or tied to a remote/WSL execution host, and the UI must not imply that editing one location configures another.
- **"Enable/disable" isn't universal**: different CLIs represent a disabled server differently (or not at all), so a v1 might need to scope structural editing to whichever formats actually support it, rather than assuming a single toggle model works everywhere.
- **Inline execution is a bigger deal here than for skills**: the Orchestration pane runs one fixed command Orca itself defines. An MCP server's `command`/`args`/`env` is arbitrary and can carry secrets — inline "press Enter to run" would need a preview, an explicit confirmation step, secret masking, and clarity about which runtime it executes on (local/WSL/remote), unlike the skill case.
- **Editing contract**: agent CLIs already write these config files themselves. A structural editor would need to preserve unknown fields/formatting and not race a concurrent external write.

Given that, I think the more useful first step might not be "build the whole thing" but agreeing on scope. Concretely: would a v1 that only (a) generates/copies a per-agent CLI command for a chosen server definition, versus (b) form-based structural editing limited to one config target, versus (c) confirmed inline execution in Settings — be the right place to start, or does this not fit how Orca wants to own MCP config at all?

My own suggested starting point is **(a)** — generate-and-copy a per-agent command for an explicitly selected target. It gives immediate value without making Orca a config-file editor or arbitrary-command executor. Non-goals for that v1: writing config files, enabling/disabling servers, executing server commands, or handling secrets in-app. (b) and (c) would be reasonable later steps once (a)'s target-selection model is validated, but I don't think they're necessary for a first version.

### Alternatives or additional context

If even (a) doesn't fit Orca's direction for MCP config ownership, the current read-only inspect-and-open behavior is a reasonable place to stay — I'd rather get that answer than have this sit unaddressed.

This is a discussion issue, not a PR — I'd like maintainer direction on ownership/scope before anyone builds this.

Start by reviewing the existing McpConfigSection and the Orchestration skill pane to understand the current inspect-and-open and command-copying flows. Before changing code, use the issue's alternatives to seek maintainer agreement on target selection and whether v1 should generate commands, edit one config target, or execute commands. Done means an agreed scope and ownership model, not an implementation.

Written by the indexing model from the issue text.