[FEATURE]: MCP observability surface — process-level status, lifecycle endpoints, and a TUI panel #53065

• I have verified this feature hasn't been suggested before — searched open issues/PRs for mcp status, mcp process, mcp dashboard, mcp monitor, mcp restart: prior work is all behavior fixes (e.g. fix(mcp): reconnect dropped servers with backoff #52943, fix(mcp): reclaim discovery-only connections #53046, fix(mcp): release MCP servers for abandoned directories #52946), no observability-surface proposal found.

Summary

MCP lifecycle issues keep piling up as individual bugs — #51249, #50363, #52965, #52410, #46253, #47727 (process leaks/duplication), #50725 (mcp list reports failed while the API reports connected), #52237, #52564 (silent failure/no retry visibility), #51140 (startup warning spam). The common root they share is not any single code path: there is no observability surface for MCP state. You cannot see which servers hold live processes, why a server is failed, or what a disconnect left behind — so every lifecycle bug is found by symptom, never diagnosed in place.

Current state (verified on dev)

• GET /mcp returns only the connection-status enum per server (connected / failed / disabled / needs_auth / ...).
• No process-level facts are exposed: no pid, uptime, transport type, child-process count, or last error.
• The service already has connect / disconnect / status, but connect/disconnect have no HTTP endpoints — they are unreachable for tooling.
• ToolsChanged events exist, so an event stream surface has an existing pattern to follow.

Proposal

Phase 1 — richer status + lifecycle endpoints (API-only, independently mergeable):

• Extend the status payload with per-server facts the service already holds or can cheaply add: transport type, pid (stdio), uptime, last error/time, tool count.
• Expose POST /mcp/:name/connect and POST /mcp/:name/disconnect (thin wrappers over the existing service methods).

Phase 2 — TUI surface: an /mcp panel listing servers with the above facts and the connect/disconnect/reconnect actions, so mcp list and the API can never disagree again (#50725).

Phase 3 (optional): a status event stream (reusing the ToolsChanged pattern) for external dashboards.

Related context: I posted a lifecycle-boundary analysis on #51249 (unbounded InstanceStore map + no idle eviction + no session-end disposal). This proposal is deliberately orthogonal to the behavior fixes in flight (#52943, #53046, #52946) — those change what the code does; this makes the state visible while they land. Fixes without observability means the next regression is found by symptom again.

Happy to implement Phase 1 as a first PR.

Open questions

1. Should the lifecycle endpoints be restricted (e.g. disconnect only, no config mutations)?
2. Process facts scope: is pid/uptime/last-error enough for v1, or is memory/CPU worth the plumbing?
3. TUI: standalone /mcp command vs. a tab inside an existing surface?