Zero-restart first install: MCP launcher should speak MCP itself and hot-add tools via tools/list_changed

[noisy]

Problem

On a FIRST install the plugin's MCP server is connected at session start, before the container exists. The stdio launcher (mcp_exec.sh) waits patiently, but the CLIENT gives up after its own ~30 s startup timeout and marks the server failed — waiting longer server-side is pointless. The user must reconnect (/mcp → reconnect) or restart once. #12 removed the reload for the container-restarts case; this removes it for first install.

Direction

Make the launcher a minimal MCP shim instead of a dumb waiter:

1. Answer initialize IMMEDIATELY itself (canned response, capabilities advertising tools.listChanged), so the client-side timeout never fires.
2. Serve an empty tools/list while the container is absent.
3. Poll for the container in the background; once it answers, spawn the real noisy-coding-mcp inside it, replay the client's initialize, and from then on transparently forward the stream.
4. Emit notifications/tools/list_changed at switchover — Claude Code picks up the speak/announce tools live, mid-session, no reconnect.

stdio MCP is newline-delimited JSON-RPC, so this is technically writable even in POSIX sh (canned strings + a forwarding loop), but fragile — evaluate whether a tiny embedded python heredoc via the container (chicken-and-egg: not available before the container...) or a carefully tested sh script is the right vehicle. Client support for tools/list_changed should be verified first.

Acceptance

Fresh machine, session already open, plugin installed, container started minutes later by /noisy-coding:setup: the speak tool appears in the SAME session with no reconnect and no restart.

Interim mitigation (shipped)

commands/setup.md now tells the agent to suggest /mcp → noisy-coding → reconnect instead of a full restart.

🤖 Generated with Claude Code