[FEATURE] MCP Tool Filtering: Allow Selective Enable/Disable of Individual Tools from Servers

Other: GitHub Copilot's Configure Tools Interface

Here's a screenshot showing GitHub Copilot's implementation of selective MCP tool filtering:

<img width="741" height="454" alt="Image" src="https://github.com/user-attachments/assets/e1a76417-15cc-4848-8927-8e0271505b14" />

This screenshot shows:

1. "Configure Tools" interface with tool selection capabilities
2. Individual tool checkboxes - users can enable/disable specific tools
3. Server grouping - tools organized by MCP server (visible: "MCP Server: fetch", "MCP Server: filesystem")
4. Performance warning - "191 tools are enabled. You may experience degraded tool calling above 128 tools"
5. Granular control - Individual filesystem tools like create_directory, read_multiple_files, etc. can be toggled independently

The 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:

• ✅ Client-side filtering works effectively
• ✅ Performance considerations are built-in (128-tool warning)
• ✅ Server grouping improves organization
• ✅ Individual tool granularity provides precise control
• ✅ No impact on underlying MCP protocol or servers

This evidence supports the feasibility and user value of implementing similar functionality in Claude Code.

+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

This will be an excellent improvement and align with Claude Desktop MCP tools toggles.

@BrianInAz for now you can use the permissions setting 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 denied error. 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 filesystem MCP tools is redundant. Claude Code has built-in files management, amongst other tools, you can simply deny the Edit tool 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.json configuration file I linked above demonstrates how to avoid using MCP tools that require an Anthropic API key, like mcp__claude__WebFetch and mcp__claude__WebSearch. I have a Max 5X subscription and using directly the built-in WebFetch and WebSearch bypasses the API key requirement.

+1, mcp tools is taking up too much context

+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.

+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.

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.

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!

<img width="622" height="380" alt="Image" src="https://github.com/user-attachments/assets/d05cb72a-5543-4e45-a630-2c46f346012d" />

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

I forgot to mention that I developed a proxy MCP to solve this exact problem: https://github.com/respawn-app/tool-filter-mcp

That MCP solves the issue for me, let me know if it works for you guys!

Also this seems to be a duplicate of https://github.com/anthropics/claude-code/issues/6759

+1, I come from VSCode I before I have a lot of MCP, today, I need to uninstall/install depends on thetask, is anoying
Please take this issue!

+1 to this feature.

For now I have resorted to use Claude code without MCP servers and rely on installing CLI tools, Claude is really good at using them

+1 for this from me too! We are resorting to forking MCP tools just so we can delete some of the tools to make it fit out specific task! This would save so much trouble!

+1 for this! It would be awesome if you guys do it ❤️

+1

@sash forking seems too aggressive. Does https://github.com/respawn-app/tool-filter-mcp work for you?

+1 for me as well

Guys, please don't spam the topic, you can like the original post for +1s.

@sash forking seems too aggressive. Does https://github.com/respawn-app/tool-filter-mcp work for you?

It would work for SSE MCPs but I use some that only support input/output - does the proxy work for those as well?

+1 for me as well

@sash it works for streamable HTTP and SSE, for stdio there's a ticket. Do you need this for stdio? which MCP?

+1 for Azure Devops and Atlassian MCPs

+1 for me as well

+1 for this

voting here as well!

+1 this is a mayor blocker for effective workflows.

+1 voting for ti

+1

+1

+1

+1

+1

+1

+1

+1
I just found that my MCPs taking around 100k tokens... And I need only a few tools from them.

+1

(With 41% of the session context already consumed,) I expected the AI to be more proactive in guiding optimal usage—for example, offering meaningful advice on context management and overuse rather than just basic prompts about agents and git work copies.

https://www.anthropic.com/engineering/advanced-tool-use
Anthropic has rolled out new features for dynamically searching for suitable tools and lazy-loading MCP tools, but it looks like Claude Code doesn’t support them yet. It's in beta and implemented via an API request body.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 some company-managed MCP servers are hard or impossible to replace with Skill with CLI or API scripts. And giving up 30% of the context window just to load 3 tools out of the 27 available… not great :-(

Agreed this is an issue.

+1

Hey all, I was also facing this issue in Cline and I wrote this small node package to solve the exact issue of tool filtering. This package prevents unwanted tools from being added to the Claude context rather just permission based. You can install the node package here:
https://www.npmjs.com/package/mcpwrapped

The repo is here:
https://github.com/VitoLin/mcpwrapped

It is very easy to use and just requires installing the node package and a small config change:

Example:

  "mcp-playwright": {
    "disabled": true,
    "timeout": 10,
    "type": "stdio",
    "command": "npx",
    "args": [
      "-y",
      "@executeautomation/playwright-mcp-server"
    ]
  }

After:

npm i -g mcpwrapped 

config

  "playwright-wrapped": {
    "disabled": false,
    "timeout": 10,
    "type": "stdio",
    "command": "mcpwrapped",
    "args": [
      "npx",
      "-y",
      "@executeautomation/playwright-mcp-server",
      "--visible_tools=playwright_navigate,playwright_get_visible_html,playwright_console_logs,playwright_click"
    ]
  }

This was also my first node package so feel free to add any pull request for bug fixes or improvements!

It's also possible with https://github.com/geelen/mcp-remote and --ignore-tool, but having the native capability would be better

you can add the follwing to your ~/.claude/settings.json file:

  "permissions": {
    "deny": [
      "mcp__clickup__clickup_search",
      "mcp__clickup__clickup_get_workspace_hierarchy",
      "mcp__clickup__clickup_get_task_comments",

to disable certail tools

you can also do this on a per project basis

That doesn’t solve the actual problem.You can deny access but the tool definitions remain in the context window and the agent will still try to use them and waste context window and token costs.The context window burden is the biggest pain of MCP. Configuring which tools are available in the context window is essential.MCP providers will get smarter, the technology is brand new and everyone is learning. But right now, this feature is available on other platforms and would be an amazing addition to Claude Code (which is otherwise leaps and bounds ahead in the AI coding realm).Sent via carrier pigeon...On Dec 19, 2025, at 01:43, Christopher Beard @.> wrote:Non-Certinia Sender*chrisbeardy left a comment (anthropics/claude-code#7328)
you can also do this on a per project basis

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

An alternative approach is to ask Claude Code to convert an MCP server (if open source) into a skill (preferably using the "Skill Creator" skill).
This way it consumes a very minimum context, and only when you ask to use a skill, it would consume more context to read the SKILL.md

you can add the follwing to your ~/.claude/settings.json file: `` "permissions": { "deny": [ "mcp__clickup__clickup_search", "mcp__clickup__clickup_get_workspace_hierarchy", "mcp__clickup__clickup_get_task_comments", `` to disable certail tools

I'll echo what @pallencertinia said here https://github.com/anthropics/claude-code/issues/7328#issuecomment-3675914055.

Adding those to the permission deny list doesn't remove the tool descriptions / token usage from the context window. It just stops the tool call from going through if/when Claude does try to use it.

> you can add the follwing to your ~/.claude/settings.json file: > `` > "permissions": { > "deny": [ > "mcp__clickup__clickup_search", > "mcp__clickup__clickup_get_workspace_hierarchy", > "mcp__clickup__clickup_get_task_comments", > `` > > > > > > > > > > > > to disable certail tools I'll echo what @pallencertinia said here #7328 (comment). Adding those to the permission deny list doesn't remove the tool descriptions / token usage from the context window. It just stops the tool call from going through if/when Claude does try to use it.

I had this comment above for a [npm package](www.npmjs.com/package/mcpwrapped) that does completely filter tools from the context https://github.com/anthropics/claude-code/issues/7328#issuecomment-3658907183

+1 on this one. Atlassian alone is 25k tokens for 28 tools and most of those are unused. Loading this for every claude code interaction is a huge context window waste.

@pallencertinia @JesseObrien this is not entirely True, if you add it to your file then renable the mcp server, manually disable and enable it then it will not load it into context. From these two screenshots you can see not all my clickup tools get added to context, with all enabled I have over 30k tokens in MCP tools. I have noticed that I sometimes I do have to disable and renable every time I reboot my PC. I consider this a workaround and would still love Anthropic to sort a better solution.

<img width="614" height="677" alt="Image" src="https://github.com/user-attachments/assets/62e73816-d4f1-49ae-86ea-6f2fb3509d92" />

<img width="817" height="449" alt="Image" src="https://github.com/user-attachments/assets/8e1ee359-944f-4659-992b-0b7adb3e907e" />

+1

+1

+1

' + 1

+1

+1

+1

This is exactly why I built PlexMCP - a gateway that sits in front of all your MCP servers. Instead of Claude loading 50+ tools from each server, you configure which tools to expose through a single endpoint. One API key, one connection, you control what gets surfaced. GitHub: Here Hosted: Here Happy to help if you want to try it.

@TheMailmans Hi, I didn't understand how your tool can help with this issue.

+1

+1

+1

+1

Since this problem is not getting addressed I'm now considering to drop all MCPs and use CLI + skills instead.

+1

+1

+1 on this — want to highlight a specific angle that's slightly different from the context window concern but very related:

When Claude Code runs as an MCP server inside Claude for Desktop, every single MCP tool call triggers a permission prompt — including completely read-only, zero-risk tools like Read, Grep, Glob, WebSearch, and WebFetch. There's no way to permanently allowlist these.

In the Claude Code CLI, these tools are already auto-allowed by default (no permission prompt), which makes sense — they can't modify anything. But when the same tools are invoked via MCP in Claude Desktop, the permission model treats them identically to destructive operations.

The ask: Allow users to configure per-tool (or per-tool-category) auto-approval for MCP servers in Claude Desktop, so that read-only tools don't require clicking "Allow" on every single invocation. Even just a "read-only tools are always allowed" toggle would be a huge quality-of-life improvement.

This is the single biggest friction point in my Claude Desktop + Claude Code MCP workflow right now.

+1 - across 48 sessions, 62% of my MCP tools loaded into context had zero usage. In my usage of the Atlassian MCP, only 3 of 22 tools account for virtually all calls. An allowedTools config in the MCP server definition would cut ~7k wasted tokens per conversation. Would also help with #5706 (token refresh) since fewer tools means fewer auth surfaces to manage.

+1

+1

+1

this is live from September?.. Wow! Anthropic, you R full of surprises...

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/git

There'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.

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

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.

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 /doctor command 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/credits
• contacts_get_contacts, contacts_get_contact_info — view contacts
• templates_get_email_templates, templates_get_email_template — view templates
• senders_get_senders — check sender config
• domains_get_domains, domains_get_domain_configuration — DKIM/SPF status
• email_campaign_management_get_email_campaigns — list campaigns
• lists_get_lists — mailing lists
• campaign_analytics_get_account_sending_statistics — account stats
• transac_templates_send_transactional_email — send transactional emails
• webhooks_management_get_webhooks, webhooks_management_get_webhook — view webhooks

That's ~8K tokens instead of ~93K — a 91% reduction if tool filtering existed.

What I tried

1. includeTools in MCP config — does not exist (despite some AI assistants claiming it does)
2. permissions.deny rules — blocks execution but does NOT remove tools from context, so no token savings
3. mcp2cli — CLI wrapper for on-demand MCP access. Works for --list but tool calls hang/timeout due to per-invocation reconnect overhead (filed issue)
4. ToolSearch (deferred loading) — helps but tool names still appear in <available-deferred-tools> every turn

Current 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:

• Config-level filtering (includeTools/excludeTools in .mcp.json or ~/.claude.json) — my preference for automation
• UI checkboxes — great for interactive setup

The key requirement: filtered-out tools must be removed from context entirely, not just blocked from execution. Otherwise there's no token savings.

Environment

• Claude Code 2.1.71
• macOS 26.3.1 (Apple M4 Pro, 24GB)
• Brevo MCP: HTTP transport, https://mcp.brevo.com/v1/brevo/mcp/

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):

~~~json
// settings.json
{
"permissions": {
"deny": [
"mcp__github__create_repository",
"mcp__github__delete_file",
"mcp__slack__*"
]
}
}
~~~

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 mcpServers frontmatter field — [docs here](<https://docs.anthropic.com/en/docs/claude-code/sub-agents#scope-mcp-servers-to-a-subagent>).

---

What's not implemented: a per-server allowedTools allowlist directly in .mcp.json, or a /mcp UI 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.

@bcherny Amazing!! Thank you so much!

What's not implemented: a per-server allowedTools allowlist directly in .mcp.json, or a /mcp UI toggle like Claude Desktop has. If those specific UX improvements are still wanted on top of the above, let us know

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.

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/*.md files with the right mcpServers frontmatter. The main agent's context stays clean — zero MCP schema tokens.

Two modes:

• Interactive sessions: generates native .claude/agents/ files so the Agent tool picks up MCPs automatically
• CLI/scripts (claude -p): a transparent wrapper injects --mcp-config into subagent calls

Profiles support per-profile model override, isolateMcp for 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.

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.