Feature Request: Lazy loading flag for MCP servers in .mcp.json

Summary

Add a lazy (or autoStart: false) flag to MCP server definitions in .mcp.json so servers can be registered but not started at session startup. Servers marked as lazy would appear in /mcp as disabled and only connect when explicitly enabled by the user.

Problem

All MCP servers defined in .mcp.json and listed in enabledMcpjsonServers are loaded on every session start, in every project. There is no way to make servers available but disabled by default per project.

This causes several issues:

1. Unnecessary startup cost — servers initialize even when the current task doesn't need them
2. Context window waste — tool definitions consume tokens in every session
3. No per-project control — users who want servers available on-demand must either enable them globally (always on) or use disabledMcpjsonServers in settings.json (completely hidden from /mcp)

There is currently no middle ground: servers are either always connected or entirely invisible.

Proposed Solution

Add a lazy flag to server config in .mcp.json:

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["-y", "kubernetes-mcp-server", "--read-only"],
      "lazy": true
    }
  }
}

Servers with lazy: true would:

• Not connect at session startup
• Appear in /mcp as disabled/available
• Start when the user explicitly enables them via /mcp
• Persist the enabled/disabled state per project (same as current /mcp toggle behavior)

Use Case

I have a number of MCP servers configured globally. Most projects only need 1-2 of them, but all 6 load on every session. I want them available in /mcp so I can enable the relevant ones per project, without paying the startup and context cost for all of them every time.

Today there is no way to achieve "visible in /mcp but disabled by default." The disabledMcpjsonServers setting in settings.json completely hides servers from /mcp, and editing ~/.claude.json per-project state externally gets overwritten by Claude Code's MCP initialization on startup.

Related

Continuation of #18497 (closed as stale) and #20467 (marked as duplicate).