Selective MCP Tool Activation for Project-Specific Contexts

I agree that it would be great to support a settings level overriding another settings level for list settings (vs. the default of merging them together). Ideally users can choose at the higher settings level whether or not to merge. cc @rboyce-ant @bogini

I agree with this. I rarely want MCP enabled for a whole session, since I use most of the tools infrequently. If I want to use MCP I have to accept that I'm wasting tokens and hurting performance because of noise in my context that I may not even use in that session

It would be a huge improvement if we could enable/disable MCP from within a Claude session with a slash command. That way we can easily turn them on or off when needed without needing to quit and restart Claude.

Even better, my ideal scenario would be if we could give Claude the ability to itself run its slash commands. That way, I could create a custom slash command e.g. \code_review which instructs Claude to first run \mcp add ... to enable the MCP, then calls a specific code review MCP tool, and disables it again afterwards.

This has the added benefit of preventing collisions between tool names from different MCPs, which causes Claude to occasionally confuse the arguments between the two.

There is a similar comment here regarding the consumption of context by unneeded tool descriptions. This is an interesting problem. Allowing human operators to toggle servers and server components (tools, resources, etc.) easily is probably a useful quick solution. On the other hand, it somewhat works against the discovery and automaton provided by Claude. This could merit discussion at the protocol level, perhaps enriching the server instruction field, so that a minimum of context is sacrificed to tooling, but leaves the LLM able to interrogate further if desired. 🤔

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.

Additional Case: Server-Side Tool Exclusion Ignored

I'm experiencing this issue with Serena MCP using server-side excluded_tools configuration.

Configuration

In .serena/project.yml, I have explicitly excluded 16 tools:

excluded_tools:
  # Duplicates with Claude Code native tools
  - read_file           # Claude Code: Read
  - create_text_file    # Claude Code: Write
  - execute_shell_command  # Claude Code: Bash   
  - list_dir            # Claude Code: Glob/Bash(ls)
  - find_file           # Claude Code: Glob

  # Meta-tools (low value)
  - think_about_collected_information
  - think_about_task_adherence
  - think_about_whether_you_are_done

  # Administrative (rarely used)
  - prepare_for_new_conversation
  - initial_instructions
  - switch_modes
  - get_current_config
  - check_onboarding_performed
  - onboarding
  - delete_memory
  - edit_memory

Expected Behavior

- Only 13 active tools loaded into context (~8k tokens)
- Excluded tools should not consume context tokens

Actual Behavior

- All 29 Serena tools loaded into context (22.2k tokens)
- /context command shows all excluded tools consuming tokens:
MCP tools · /mcp
└ mcp__serena__read_file: 834 tokens        ← EXCLUDED but in context!
└ mcp__serena__create_text_file: 648 tokens ← EXCLUDED but in context!
└ mcp__serena__execute_shell_command: 859   ← EXCLUDED but in context!
... (all 29 tools = 22.2k tokens total)

Verification

Server-side filtering IS working - excluded tools return errors when called:
Error: Tool 'read_file' is not active. Active tools: ['activate_project', 'find_referencing_symbols', 'find_symbol', ...]

Impact

- ~14k tokens wasted (22.2k actual vs 8k expected)
- This confirms the issue extends beyond project-level exclusion to MCP server-side tool filtering being completely ignored for context optimization

Environment

- Claude Code: v2.0.x (latest)
- MCP Server: Serena (oraios/serena)
- OS: macOS (Darwin 24.6.0)
- Model: claude-sonnet-4-5-20250929[1m]

This is particularly problematic because server-side tool filtering is the documented way to optimize MCP context usage, but Claude Code is not respecting these configurations.

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

This issue was closed incorrectly despite recent human comments. This behavior of the bot is reported at https://github.com/anthropics/claude-code/issues/16497. Please upvote that issue, so maybe it gets noticed.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.