Repository navigation
[FEATURE] MCP Tool Filtering: Allow Selective Enable/Disable of Individual Tools from Servers #7328
Description
Preflight Checklist
- I have searched existing requests and this feature hasn't been requested yet
- This is a single feature request (not multiple features)
Problem Statement
MCP servers expose all available tools through the tools/list endpoint, and Claude Code currently loads all tools from configured servers without any client-side filtering mechanism. This creates several issues:
- Performance degradation: Large MCP servers (like the filesystem server with 20+ tools) can overwhelm the interface and potentially impact performance
- Unnecessary complexity: Users often only need a subset of tools but must work with all exposed tools
- Security/control concerns: No way to restrict access to potentially sensitive tools on a per-project basis
For example, I'm using the @modelcontextprotocol/server-filesystem which exposes many tools, but I only need 3 specific ones: read_multiple_files, search_files, and create_directory. Currently, I have to work with all 20+ tools, which clutters the interface and may impact performance.
Proposed Solution
Implement a client-side tool filtering system similar to GitHub Copilot's "Configure Tools" interface. This would allow users to:
- View all available tools from each configured MCP server
- Selectively enable/disable individual tools via checkboxes or similar UI
- Create tool groups/sets for easier management of related tools
- Set per-project configurations that can be shared via repository settings
- Apply performance warnings when too many tools are selected (similar to GitHub's 128-tool limit)
The interface should display:
- Server name and status
- Individual tools with descriptions
- Enable/disable toggles for each tool
- Performance warnings when approaching limits
Alternative Solutions
Workarounds I've considered:
- Creating custom minimal MCP servers: Would work but requires significant development effort for each use case
- Using different MCP servers: Limited options, and most comprehensive servers (like filesystem) have the same issue
- Modifying server configurations: Not always possible, especially with packaged servers like
@modelcontextprotocol/server-filesystem
Other tools' approaches:
- GitHub Copilot has solved this with their Configure Tools interface (see evidence below)
- VS Code extensions often provide granular feature selection
- IDE plugin systems typically allow selective activation of features
Priority
Medium - Significant impact on productivity
This directly affects daily workflow efficiency and tool usability, especially for users working with multiple or comprehensive MCP servers.
Feature Category
MCP server integration
Use Case Example
Scenario: Frontend Developer using Filesystem MCP Server
- I configure the
@modelcontextprotocol/server-filesystemin my~/.claude.json - Currently: Claude Code loads all 20+ filesystem tools (read_file, write_file, list_directory, etc.)
- With this feature: I could access "Configure Tools" and:
- Keep only:
read_multiple_files,search_files,create_directory - Disable: write operations, file management, metadata tools I don't need
- Keep only:
- Result: Cleaner interface, focused toolset, potentially better performance
Step-by-step workflow:
- Open Claude Code with MCP servers configured
- Navigate to "Configure Tools" (similar to agent mode tools)
- See "MCP Server: filesystem" section with all available tools listed
- Uncheck unwanted tools, keeping only essential ones
- Save configuration (optionally per-project)
- Claude Code now only shows/uses selected tools
Additional Context
Evidence from GitHub Copilot:
GitHub Copilot has successfully implemented this exact feature. Their documentation states:
"Toolsets make it easier to group related MCP tools together and quickly enable or disable them"
"If you have more than 128 tools selected, you need to reduce the number of tools by deselecting some tools in the tools picker"
GitHub's official documentation (https://docs.github.com/en/copilot/how-tos/context/model-context-protocol/extending-copilot-chat-with-mcp) demonstrates this capability working in production.
Technical considerations:
- This is a client-side feature - no changes needed to MCP protocol or servers
- Can be implemented as UI layer filtering on top of existing
tools/listresponses - Should support both global and per-project configurations
- Could integrate with existing Claude Code settings system
Performance benefits:
- Reduced cognitive load in tool selection interfaces
- Potentially faster tool loading with fewer active tools
- Better organization for power users with multiple MCP servers
Enterprise/security benefits:
- Project-specific tool restrictions
- Ability to disable potentially sensitive tools in shared repositories
- Better control over which capabilities are available in different contexts
This feature would bring Claude Code's MCP integration to parity with GitHub Copilot while addressing real user needs for better tool management and performance.
Activity
BrianInAz commentedon Sep 9, 2025
Other: GitHub Copilot's Configure Tools Interface
Here's a screenshot showing GitHub Copilot's implementation of selective MCP tool filtering:
This screenshot shows:
create_directory,read_multiple_files, etc. can be toggled independentlyThe concept is not only feasible but already successfully implemented by MS in Copilot. The interface provides exactly the functionality requested: selective tool filtering at the client level without requiring changes to MCP servers or the protocol itself.
Key takeaways from Copilot's implementation:
This evidence supports the feasibility and user value of implementing similar functionality in Claude Code.
jamienewcomb commentedon Sep 12, 2025
+1 for this, thanks for raising. We have created a remote mcp server which connects all our tools together (we have loads of tools). It’s fine for most code editors as people can unselect the tools they don’t need and they can also do this with AI assistants (Claude AI etc) but as stated Claude Code doesn’t have this option and in our cases, the MCP is consuming far too much of the context window
fmunteanu commentedon Sep 15, 2025
This will be an excellent improvement and align with Claude Desktop MCP tools toggles.
@BrianInAz for now you can use the
permissionssetting to achieve your desired outcome, see https://github.com/axivo/claude/blob/main/.claude/settings.json Claude Code configuration.The denied tools will not be executed, but they will still be available into Claude Code and Claude will try to execute them, getting a
Permission to use mcp_tool_name has beed deniederror. The proper implementation is to make the tools unavailable in Claude Code, like is done in Claude Desktop.Edit: since you use Claude Code, using
filesystemMCP tools is redundant. Claude Code has built-in files management, amongst other tools, you can simply deny theEdittool for example. I personally prefer to use Claude Code binary as MCP server, because it makes all tools available in both Claude Code and Claude Desktop:{ "mcpServers": { "claude": { "command": "claude", "args": [ "mcp", "serve" ] } } }The
settings.jsonconfiguration file I linked above demonstrates how to avoid using MCP tools that require an Anthropic API key, likemcp__claude__WebFetchandmcp__claude__WebSearch. I have a Max 5X subscription and using directly the built-inWebFetchandWebSearchbypasses the API key requirement.fallonou1999 commentedon Sep 18, 2025
+1, mcp tools is taking up too much context
Brandtweary commentedon Sep 19, 2025
+1 Most MCP servers these days don't offer tool filtering on their end yet, this would be a massive boon to the community and provide a centralized interface. It would make it easier for MCP server developers to provide comprehensive toolsets without worrying about overwhelming users.
v4nja commentedon Sep 23, 2025
+1 we need this asap. mcp servers are useful, but take too much context.
claude performance often degrades after 100k tokens, yet just a couple of mcp servers with all tools loaded can take 50k tokens leaving very little useful context.
filtering individual mcp tools is available in other coding tools so why is it not in claude code? anthropic invented mcp yet the flagship coding product has inadequate support.
Nek-12 commentedon Sep 24, 2025
Same here, some MCP servers like plane, sentry, and atlassian are needed, but expose hundreds of tools of which 80% are not needed. This takes up 50+k tokens of context, instantly decreasing quality by a significant margin. The only way to avoid that is to get rid of the MCP completely.
jayarjo commentedon Sep 26, 2025
I'd probably add that this should be on per agent/subagent basis - so one should be able to enable/disable certain tools in both - main session and sub-agents. for example in main session I do not require any github MCP tools at all (and that particular MCP is huge), but I'd still like to have them for my project milestone designing subagent.
MCP tools just sitting there and occupying huge chunk of context is so ineffective in general!
chleosl commentedon Oct 5, 2025
Agree. This was an available feature in claude.ai domain, and still weird to see it had not implemented in the Claude Code domain, where the context shortage is much more scarce; and addition to that, the Claude Code holds and utilizes "MUCH" more tools. +1
68 remaining items
brianoestberg commentedon Feb 23, 2026
+1
jeremyatvideoamp commentedon Feb 23, 2026
+1
marcin-szymanski-beefee commentedon Feb 24, 2026
+1
Vasiliy-Bondarenko commentedon Feb 28, 2026
this is live from September?.. Wow! Anthropic, you R full of surprises...
Dave-London commentedon Mar 7, 2026
For what it's worth, if the tool filtering concern is partly about MCP servers that expose too many tools — Pare already supports server-side tool filtering via environment variables:
# Only expose status, log, diff from the git server PARE_GIT_TOOLS=status,log,diff npx @paretools/gitThere's also a universal filter (
PARE_TOOLS=git:status,npm:install,test:run) that works across all servers. This lets you restrict which tools are registered before they ever reach the client — no client-side changes needed.Pare is a set of 28 MCP server packages (240 tools) wrapping common dev CLIs with structured JSON output. The filtering was added specifically because users with multiple servers were concerned about tool count overwhelming context.
block-town commentedon Mar 8, 2026
If you're looking for a way to do this today without waiting for native support — I built an MCP gateway that effectively gives you this by consolidating all tools behind 3-4 dispatch endpoints.
Claude calls
gw("account", "tool_name", {params})and the gateway routes it to the right upstream server. You only see the dispatch tools in your context, not the hundreds of underlying ones.89% context reduction in my setup (644 → 7 tool schemas). Works with any MCP server.
https://github.com/block-town/mcp-gateway
KrzysztofMadejski commentedon Mar 9, 2026
I've tried a workaround with
ENABLE_TOOL_SEARCH=true, but it doesn't seem to help much — once I use any tool from an MCP server, all tools from that server get loaded anyway. Selective tool loading would still be very valuable.jojoprison commentedon Mar 9, 2026
Real-world case: Brevo MCP — 142 tools, ~93K tokens, only 14 needed
Adding a concrete data point from production usage.
The problem
Brevo MCP (email marketing / CRM platform) exposes 142 tools covering contacts, email campaigns, SMS, WhatsApp, CRM deals, webhooks, templates, analytics, and more.
In my Claude Code setup (v2.1.71, 15+ MCP servers), Brevo alone consumes ~92,854 tokens — nearly 50% of the entire MCP context budget (~188K total). The
/doctorcommand confirms this is the single largest context consumer.What I actually need
Out of 142 tools, I use 14 in practice:
accounts_get_account— check plan/creditscontacts_get_contacts,contacts_get_contact_info— view contactstemplates_get_email_templates,templates_get_email_template— view templatessenders_get_senders— check sender configdomains_get_domains,domains_get_domain_configuration— DKIM/SPF statusemail_campaign_management_get_email_campaigns— list campaignslists_get_lists— mailing listscampaign_analytics_get_account_sending_statistics— account statstransac_templates_send_transactional_email— send transactional emailswebhooks_management_get_webhooks,webhooks_management_get_webhook— view webhooksThat's ~8K tokens instead of ~93K — a 91% reduction if tool filtering existed.
What I tried
includeToolsin MCP config — does not exist (despite some AI assistants claiming it does)permissions.denyrules — blocks execution but does NOT remove tools from context, so no token savings--listbut tool calls hang/timeout due to per-invocation reconnect overhead (filed issue)<available-deferred-tools>every turnCurrent workaround
None. Either keep all 142 tools (~93K tokens) or disconnect Brevo entirely and lose access.
What would solve this
Either of these approaches from this issue would work:
includeTools/excludeToolsin.mcp.jsonor~/.claude.json) — my preference for automationThe key requirement: filtered-out tools must be removed from context entirely, not just blocked from execution. Otherwise there's no token savings.
Environment
https://mcp.brevo.com/v1/brevo/mcp/bcherny commentedon Mar 11, 2026
Two updates that should address the main use cases here:
1. MCP tools are now lazy-loaded by default. When MCP tool descriptions would exceed ~10% of the context window, they're deferred and discovered on demand via tool search instead of being loaded upfront. This means you can leave large MCP servers (GitHub, Playwright, etc.) configured without their tool schemas eating into every conversation's context. The context-bloat motivation for manually filtering individual tools is largely gone.
2. Per-tool filtering is available via permission deny rules (since v2.0.68):
Or via CLI:
claude --disallowedTools "mcp__github__push_files"Denied tools are fully hidden from the model — they won't appear in the tool list and can't be invoked. The
mcp__server__*wildcard also works if you want to deny an entire server.If you additionally want MCP tools that are only available to specific subagents (not the main conversation at all), see the
mcpServersfrontmatter field — docs here.What's not implemented: a per-server
allowedToolsallowlist directly in.mcp.json, or a/mcpUI toggle like Claude Desktop has. If those specific UX improvements are still wanted on top of the above, let us know — otherwise we'll close this.jesseobrien commentedon Mar 12, 2026
@bcherny Amazing!! Thank you so much!
Vasiliy-Bondarenko commentedon Mar 13, 2026
yes, still wanted.
model often does not know it can use a tool and instructions are in tool description - so tool search just hides them totally and model does not search.
and reject list does not work very well when mcp has many tools and/or those tools are added from time to time. and how do you even see reject list for 100+ tools? it's real pain in the ass to create and maintain.
dev-boz commentedon Mar 16, 2026
I built a workaround for this: sub-mcp
It takes a different approach — instead of filtering tools within the main session, it moves MCP servers entirely out of the main context and into subagents. You define profiles in a YAML config (e.g. "docs" = Context7, "github" = GitHub MCP), and sub-mcp generates
.claude/agents/*.mdfiles with the rightmcpServersfrontmatter. The main agent's context stays clean — zero MCP schema tokens.Two modes:
.claude/agents/files so the Agent tool picks up MCPs automaticallyclaude -p): a transparent wrapper injects--mcp-configinto subagent callsProfiles support per-profile model override,
isolateMcpfor strict isolation, env var substitution (secrets never persisted to disk), and a bypass escape hatch.Not a replacement for native tool filtering, but it works today.
github-actions commentedon Mar 23, 2026
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.