[FEATURE] Persistent user-level MCP configurations (enable/disable)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/10447
2. https://github.com/anthropics/claude-code/issues/6309
3. https://github.com/anthropics/claude-code/issues/4256

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Hey, this should already be working. Did you add it to the user scope?

Hey, this should already be working. Did you add it to the user scope?

Thanks Ollie. Yes, most of my servers are user scope.

I don't see any fields for persistent enable/disable decisions that apply to ALL projects. Am I missing something embarrassingly obvious?

For clarity, I'm not saying there's a persistence issue for MCP settings on a single project (e.g., I'm aware that enable/disable decisions for user scope MCP servers are persistently captured in ~/.Claude.json for each PROJECT). I just haven't found a way to avoid having to disable MCP servers using @ command at the beginning of a NEW project, where all MCP servers are enabled by default.

If it doesn't already exist, I'm suggesting an additional layer of "template" settings at a user level that apply to any new project (e.g., project should have MCP enable/disable configs baked into it on first start), but which is overridden by any subsequent changes to MCP enable/disable settings made in the TUI.

I've built a modular plugin architecture with separate plugins for different concerns (general, web-dev, project-mgmt), and the inability to set global MCP defaults creates significant friction.

Measured Token Impact

Here's the actual token consumption from my setup:

With all MCP servers enabled:

• Total MCP tools: 62.8k tokens (31.4% of 200k context window)
• GitHub MCP: ~30k tokens (15%)
• Linear MCP: ~18k tokens (9%)
• Playwright MCP: ~13k tokens (6.5%)
• Context7 MCP: ~1.7k tokens (0.8%)

After disabling web-dev and project-mgmt plugins:

• Total MCP tools: 31.7k tokens (15.8%)
• Savings: 31k tokens (15.6% of context window)

Even with just Context7 and GitHub enabled (my "general" plugin), I'm still consuming 31.7k tokens - and this is per-project overhead.

Current Workflow Problem

What I have to do now (tedious):

# Every time I open a new project:
/mcp  # Disable GitHub
/mcp  # Disable Context7
# Repeat for every new project...

What I want to do (efficient):

# Once: Set global defaults
claude mcp set-default plugin:general:github disabled
claude mcp set-default plugin:general:context7 disabled

# Per-project: Enable only where needed
cd ~/my-github-project
claude mcp enable plugin:general:github

Plugin Architecture

I've organized MCP servers into domain-specific plugins:

• general@personal - Core tools (Context7, GitHub)
• web-dev@personal - Browser automation (Playwright)
• project-mgmt@personal - Issue tracking (Linear)

This modular approach only works well if I can:

1. Have MCP servers disabled by default globally
2. Enable specific plugins/servers per-project as needed
3. Not have to repeat this configuration for every new project

Why This Matters

The current "enabled by default" behavior forces this choice:

• Option A: Accept 30%+ context overhead in every project (wasteful)
• Option B: Manually disable in every new project (tedious)

Neither is acceptable for a good developer experience.

Proposed Solution Alignment

The proposed solution in this issue (user-level MCP config in ~/.claude.json) would perfectly solve this:

{
  "mcpServerDefaults": {
    "plugin:general:github": "disabled",
    "plugin:general:context7": "disabled"
  }
}

Then new projects inherit these defaults, and I can selectively enable per-project with /mcp enable.

Use Case

I primarily work on dotfile management (chezmoi), data analysis (Python/Jupyter), and occasional web projects. I only need:

• GitHub MCP: When working on repositories that use GitHub (not all projects)
• Context7 MCP: When I need to look up documentation (sporadic)
• Playwright MCP: Only for web scraping/testing projects (~10% of my work)
• Linear MCP: Only when managing project tracking

Having all of these enabled by default in every project wastes ~30% of my context window on tools I'm not using.

---

+1 for this feature request! Happy to provide more data or help test if needed.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

@ollie-anthropic any thoughts on this? Would allow a lot of user creativity around proxy mcp servers, which could free up context.

Bump on this since I am also seeing the same behavior on new projects. Disable them in new projects, then enable ones i want for that specific project using /mcp

+1 for this feature. Currently have 10 MCP servers configured globally and need to manually disable them in each new project. A mcpServerDefaults or similar global disable option would save significant context tokens and improve workflow.

Current workaround is tedious: /mcp disable for each server in every new project session.

You can write wrapper scripts and the use the --mcp-config flag to switch
in different collections of MCPs

I'm moving to using their new skills feature to save on context but allow
access to all capabilities now rather than juggling MCPs

On Thu, 25 Dec 2025 at 13:39, Nas&Nora @.***> wrote:

NasAndNora left a comment (anthropics/claude-code#11085) <https://github.com/anthropics/claude-code/issues/11085#issuecomment-3691452477> +1 for this feature. Currently have 10 MCP servers configured globally and need to manually disable them in each new project. A mcpServerDefaults or similar global disable option would save significant context tokens and improve workflow. Current workaround is tedious: /mcp disable for each server in every new project session. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/11085#issuecomment-3691452477>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAU6PP2UQ5DZS374CKI7234DPSH3AVCNFSM6AAAAACLIOQJ36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOJRGQ2TENBXG4> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

+1 need this

@bcherny while you and Claude are crushing PRs 🙏

+1

+1 mcp installation will not scale without this

I'm hitting this same problem. For me, all I want is user-level MCPs to default to disabled. So per project, I have to explicitly enable the ones I want (rather than at the moment, I have to manually disable most of them).

Or if the mcpServers section in my user-level .claude.json had an "enabled" field per MCP server - so I can say for new projects, the default state for this MCP server is disabled.

+1 on this. My use case: I have several MCP servers configured globally (Grafana, Playwright, Obsidian, Context7, etc.) but only a subset are relevant to any given project. I'd like to install them centrally in ~/.claude.json with a disabled: true default, then selectively enable per-project.

Currently the only options are:

• Accept the context overhead of all MCPs loading everywhere (wasteful)
• Manually /mcp disable in every new project (tedious)
• Skip global config entirely and duplicate .mcp.json across projects (defeats the purpose of central management)

A mcpServerDefaults or honoring disabled: true as the initial state for new projects would solve this cleanly.

@materemias I'm in a similar situation. So I've enabled all MCPs everywhere and I turned ON "tool search" with:

export ENABLE_TOOL_SEARCH=true

(source)

It prevents polluting context with all the MCP definitions, while not having to manually switch them on or off all the time.

I still would love user-level toggles :)

This is annoying for Claude Teams subscriptions, as soon as the company configures a tool at organization level, you have to disable it for every single project.

@ollie-anthropic

The gap

No way to persistently enable/disable MCP servers through TUI or CLI:

1. TUI "Disable" is session-only — disconnects the server but doesn't persist
2. No CLI command — claude mcp disable doesn't exist
3. Manual config editing — users must discover and edit JSON files

---

Proposed UX

TUI should distinguish session vs persistent:

For connected servers:

my-server · ✔ connected
Source: user

  1. Disconnect (this session)
  2. Disable (globally)
  3. Disable (this project)
  4. Remove server

For disabled servers:

my-server · ○ disabled (globally)
Source: user

  1. Connect (this session)
  2. Enable (globally)
  3. Enable (this project)
  4. Remove server

CLI should mirror TUI:

# Session only
claude mcp disconnect my-server
claude mcp connect my-server

# Persistent
claude mcp disable my-server [--global|--project|--local]
claude mcp enable my-server [--global|--project|--local]

Status should indicate scope:

my-server      · ✔ connected
other-server   · ○ disabled (global)
dev-tools      · ○ disabled (project)

---

Suggested data model

Plugins already have a clean pattern — per-item boolean state:

{
  "enabledPlugins": {
    "playwright@claude-plugins-official": false,
    "code-review@claude-plugins-official": true
  }
}

MCP servers should work the same way:

{
  "enabledMcpServers": {
    "teams": false,
    "jira": true
  }
}

Why this is better than deniedMcpServers:

| | deniedMcpServers (current) | enabledMcpServers (proposed) |
|---|---|---|
| Model | Blacklist array | Per-server state |
| Scope override | Arrays merge — child can't undo parent denies | Boolean override — child sets true, done |
| Reasoning | "Is this server in any deny list?" | "What's the state at this scope?" |
| Precedent | None | Matches enabledPlugins |

The blacklist approach requires workarounds (allowlists, merge modes, null semantics) to handle "enable at child scope what parent disabled." Per-server state handles this naturally.

---

Current workaround

deniedMcpServers exists and works for adding denies, but can't override parent scope:

// ~/.claude/settings.json
{ "deniedMcpServers": [{ "serverName": "teams" }] }

Verified limitation: arrays merge across scopes. If user scope denies a server, project/local scope cannot re-enable it.

Reference: Settings docs

---

Summary

1. Wire TUI/CLI to persistent config (the UX gap)
2. Use per-server state instead of blacklist arrays (the data model gap)

The enabledPlugins pattern already exists — apply it to MCP servers.

This feature is overdue!

Cross-reference: #37793 tracks the subagent-spawn variant of this. Subagents don't honor ToolSearch deferral even when the parent does, so they fail with Prompt is too long at far lower MCP counts than expected. On a 10-MCP / ~274-tool setup, Explore hits 213,431 tokens at spawn before executing a turn. Resolving #11085's persistent-disable UX would help users mitigate #37793 without per-project edits, but the structural fix is at the subagent-spawn layer.