MCP: `disabled: true` does not prevent HTTP connection attempts at startup

Summary

HTTP-type MCP servers configured with disabled: true in .mcp.json still make network connection attempts at Claude Code startup. This contradicts the expected behavior where a disabled server should not load until explicitly enabled via /mcp.

Expected behavior

A server marked disabled: true should not attempt any network activity until toggled on.

Actual behavior

On startup, Claude Code appears to ping HTTP MCP endpoints (likely to cache tool schemas for the /mcp toggle UI) even when disabled: true is set. This causes:

• Unwanted outbound connections to external services
• Authentication prompts or errors for servers requiring OAuth/tokens
• Potential credential exposure for servers using secret headers

Stdio-based servers (command-based) correctly do not spawn a process when disabled — the issue is isolated to type: "http" servers.

Reproduction

// .mcp.json
{
  "mcpServers": {
    "example-http-server": {
      "disabled": true,
      "type": "http",
      "url": "https://some-mcp-server.example.com/mcp"
    }
  }
}

Start Claude Code. Observe network traffic or server-side logs — a connection attempt is made to https://some-mcp-server.example.com/mcp despite disabled: true.

Impact

Users managing multiple MCP integrations (some always-on, some on-demand) rely on disabled: true as the mechanism to keep servers in their config but truly inactive. The current behavior forces a choice between:

1. Accepting unwanted connections (and potential auth noise), or
2. Removing the server from config entirely (losing the ability to toggle via /mcp)

Environment

• Platform: macOS (darwin 25.3.0)
• Shell: zsh

Suggested fix

Respect disabled: true as a hard gate: no schema discovery, no health check, no network activity of any kind until the user explicitly enables the server.