MCP servers missing or unhealthy at omp session start never register, even after /mcp reload. Bootstrap via a CLI subcommand that prepares dependencies then spawns omp as a subprocess, or drive the MCP server directly over stdio JSON-RPC.
Observed while building a Lighthouse audit workflow in the omp harness (2026-07-13): MCP servers added to .omp/mcp.json mid-session do not join the live session tool registry, even after /mcp reload. A server that is configured at startup but fails its startup path (chrome-devtools-mcp pointed at a browserUrl no Chrome answers) also never registers.
Two working patterns. First: a bootstrap CLI subcommand (ff perf audit) that starts headless Chrome on a known debug port, temporarily rewrites the MCP entry to point at it, then spawns omp as a subprocess with an inline --append-system-prompt manifest; cleanup (byte-for-byte config restore, Chrome kill) runs after the session exits. Include an OMPCODE/CLAUDECODE recursion guard: in tool mode just ensure Chrome and print the manifest, exporting the port via env so in-session tools attach. Second: if the session already lacks the tools, drive the MCP server directly over stdio JSON-RPC (initialize, notifications/initialized, tools/call) for full tool access without the registry.