Feature request: per-server lazy/deferred MCP connection in .mcp.json (with measured cost data)

Related closed issues (all closed as duplicate/not-planned, so filing fresh with data in case the cost profile below is useful signal): #38365, #31198, #26666, #18497, #20467, #13700, #13805.

Summary

Every configured MCP server connects synchronously at session start, blocking the first turn from dispatching until the slowest one finishes. We just root-caused and fixed our own worst offenders (details below), and the before/after numbers confirm the mechanism precisely: total launch-to-first-turn-dispatch time tracks the slowest server's connect time, with zero way to exclude a server from that critical path short of removing it from config.

What we measured

Internal project, ~25 configured MCP servers across project + user scope (.mcp.json + user-level config).

Before any fix (4 runs, via --debug log analysis): Enter-press -> first-turn API dispatch min 10.77s / median 16.3s / max 22.10s. In every run the API request fired within 0.3-1.4s of the LAST slow server's "Successfully connected" line -- i.e. this is a genuinely blocking dependency, not overlapping/perceived latency.

Root cause, not a Claude Code bug: our worst two offenders were both self-inflicted --

1. A homegrown stdio MCP server (Python) that did up to two cold az (Azure CLI) subprocess calls before it could answer any MCP request, with no cache surviving across process launches (a fresh process spawns on every claude launch and never respawns for that session's life, so any purely in-memory cache is worthless). Fixed with an on-disk cross-process cache. Server connect time: 9-13s -> 187ms.
2. Two servers configured as npx -y <package> in .mcp.json. npx -y's own per-invocation package resolution costs 3-7s even with the package fully cached (--offline made no measurable difference, ruling out network) -- confirmed via isolated timing of the identical resolved command with vs without npx in the loop. Fixed by installing the packages once and pointing the config at the resolved binary directly.

After both fixes, same measurement (CLI's own time_to_request_ms field in --print --output-format json mode, 3 fresh sessions): 1387ms / 1471ms / 1351ms. ~11-16x improvement.

The gap this leaves

The fix above required us to individually root-cause and patch every slow server -- effective, but doesn't scale as server count grows, and isn't available at all for third-party/vendor MCP servers we don't control (we still have several npx -y vendor servers and one entirely dead upstream connector burning multi-second timeouts every session with no way to defer or skip them without losing the tool for the whole session).

A per-server lazy: true flag in .mcp.json -- deferring the actual connect handshake to first tool-search/invocation rather than session start, as proposed in the closed issues above -- would let a slow or occasionally-used server stay configured and available without being on the mandatory critical path of every single session launch, regardless of whether the slowness is fixable on our end.

Happy to share the full before/after --debug log methodology if it's useful for reproducing or validating a fix.