[FEATURE] defaultDisabled field for MCP servers in plugin manifests

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a plugin with MCP servers is installed, all its servers are automatically enabled in every session across all environments (CLI, VS Code, Cursor, etc.). For plugins that require OAuth (e.g., Cloud Run servers using mcp-remote), this causes an immediate flood of authentication prompts in every project — including IDEs like Cursor where the user may not even intend to use those servers.

The user must manually disable the MCPs in each environment where the MCP server is not needed in order to prevent repeated authentication prompts. This process is very tedious.

Related: #11085 (persistent user-level enable/disable) and #17921 (disabled field in .mcp.json). Those cover user-side toggling; this requests author-side control so plugin authors can ship servers that are installed but not enabled until the user explicitly opts in via /mcp.

Proposed Solution

Add a defaultDisabled boolean field to individual MCP server entries in plugin.json and
marketplace plugin entries:

  {
    "mcpServers": {
      "my-server": {
        "command": "npx",
        "args": ["-y", "mcp-remote", "https://example.run.app/mcp"],
        "defaultDisabled": true
      }
    }
  }

• defaultDisabled: true → server is installed but disabled until user enables via /mcp
• defaultDisabled: false or omitted → current behavior (auto-enabled)

Alternative Solutions

• Users manually disable servers after install — doesn't scale, not persistent across projects
• Use hooks to auto-disable — fragile and not officially supported

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

My organization distributes MCP server plugins, with each requiring Oauth. Most users have many Cursor/VS Code and Claude Code sessions running at the same time. After installing these custom plugins, the users are flooded with authorization prompts.

Many users must run into this same issue.

Additional Context

_No response_