Feature Request: MCP Profiles for Rapid Context-Aware Tool Switching

Refiled from #24000, which was auto-closed for inactivity and locked without any team engagement.

Problem

MCP configuration is currently all-or-nothing: configure an MCP server and it becomes available everywhere (Claude Code, Cowork, all projects). This creates three operational pain points:

1. Context waste from unintended MCPs: Developers configure MCPs for Cowork workflows (e.g., Slack for knowledge work) and those tools now consume 10-15% of Claude Code's context budget—even when Code doesn't need them. There's no way to disable them without removing them entirely.

1. No scoped tool management: disallowedTools flag doesn't work for MCP servers (#12863). Project-level exclusion doesn't work (#8321). Developers must manually edit .claude.json between sessions or maintain separate machine profiles—friction that breaks rapid task switching.

1. Behavioral drift: Without tool scoping, Claude Code may autonomously search/use MCPs it wasn't intended to access. Example: mentioning a person's name while working on a GitHub issue triggers Slack searches—unexpected autonomous behavior that requires explicit negative instructions to prevent.

Solution: MCP Profiles

Implement bundled MCP profiles that can be loaded, switched, and hotloaded per context:

{
  "mcp": {
    "profiles": {
      "coding": {
        "description": "Claude Code defaults",
        "mcpServers": {
          "github": { "..." : "..." },
          "context7": { "..." : "..." }
        }
      },
      "knowledge-work": {
        "description": "Cowork defaults",
        "mcpServers": {
          "slack": { "..." : "..." },
          "notion": { "..." : "..." },
          "github": { "..." : "..." }
        }
      },
      "web-automation": {
        "mcpServers": {
          "playwright": { "..." : "..." },
          "web-fetch": { "..." : "..." }
        }
      },
      "empty": {
        "description": "No MCPs",
        "mcpServers": {}
      }
    },
    "defaults": {
      "code": "coding",
      "cowork": "knowledge-work",
      "project": "coding"
    }
  }
}

Scoping Options

• Tool-level: cowork profiles only, code profiles only, shared
• Session-level: Load profile at startup via flag: claude --mcp-profile coding
• Project-level: .mcp.json or .claude/settings.json specifies profile override
• Runtime hotloading: /mcp-profile switch knowledge-work to reload MCPs mid-session
• Default fallback: Allow null or empty profile to load nothing

Benefits

1. Context preservation: Developers keep only needed MCPs in context per tool/session
2. Rapid switching: Bundle management, not individual MCP toggling. Switching profiles takes one command
3. Predictable behavior: Claude Code only has access to MCPs explicitly in its profile; no autonomous searches outside scope
4. Team alignment: Profiles can be committed to .claude/profiles/ and shared across team
5. Backward compatible: Default behavior preloads all MCPs if no profile specified

Implementation Notes

• Profiles should be loadable from:
• User level: ~/.claude/mcp-profiles.json
• Project level: .claude/mcp-profiles.json
• System level: /etc/claude/mcp-profiles.json
• Profile inheritance: Project profiles override user profiles; explicit flags override both
• Hotloading should trigger context recalculation (show /context output after switch)

Real-world Use Case

Platform engineer working on infrastructure:

• "coding" profile: GitHub, context7, Netbox (IaC tooling for Terraform/Kubernetes work)
• "knowledge-work" profile: Slack, Notion, Linear (knowledge synthesis, incident response)
• "empty" profile: When pair debugging with sensitive credentials in terminal

Today: Loses 10% context to Slack MCPs in Code sessions. Must manually edit config to exclude them. Behavior is unpredictable.

With profiles: claude --mcp-profile coding in morning, claude --mcp-profile knowledge-work for incident review. MCPs load/unload atomically. Behavior is explicit.

Note on Existing Issues

This feature request subsumes:

• #7328: MCP tool filtering (granular)
• #7289: Disabling MCP in specific contexts
• #8321: Project-level MCP exclusion

Profiles solve the bundle-scoping problem with less API surface area and more user control.