Problem
Plugins (especially knowledge-work-plugins) bundle multiple MCP servers, but there's no way to selectively disable individual MCP servers within an enabled plugin. It's all-or-nothing at the plugin level.
This creates two problems:
1. Massive MCP server duplication across plugins
When multiple knowledge-work plugins are enabled, the same MCP servers load multiple times. For example, with just engineering, design, and data enabled:
| MCP Server |
Declared In |
slack |
engineering, design |
atlassian |
engineering, design, data |
notion |
engineering, design |
gmail |
engineering, design |
google-calendar |
engineering, design |
asana |
engineering, design |
linear |
engineering, design |
The slack MCP server alone is declared in 12+ knowledge-work plugins.
2. Unnecessary context window consumption
Each MCP server injects tool definitions into the deferred tools list, consuming context space on every turn — even if the user never calls those tools. Users who want a plugin's skills/agents but not all of its MCP servers have no way to reduce this overhead.
3. Disabling MCP servers doesn't persist
Users report disabling MCP servers during a session, only to have them reactivate on the next session because the plugin re-injects them from its .mcp.json manifest.
Proposed Solution
Add per-MCP-server toggles within plugins. For example, in settings.json:
{
"enabledPlugins": {
"engineering@knowledge-work-plugins": {
"enabled": true,
"disabledMcpServers": ["pagerduty", "datadog", "slack"]
}
}
}
Or alternatively, a global MCP server blocklist:
{
"disabledMcpServers": ["pagerduty", "datadog", "intercom", "hex"]
}
Additional considerations
- Deduplication: When multiple plugins declare the same MCP server (e.g.,
slack), only one instance should load. Currently each plugin loads its own copy.
- Hooks are insufficient: A
PreToolUse hook can block MCP tool execution, but the tool definitions still load into context, so the context overhead remains.
Environment
- Claude Code CLI (macOS)
- Multiple knowledge-work-plugins + standalone plugins enabled simultaneously
🤖 Generated with Claude Code
Problem
Plugins (especially knowledge-work-plugins) bundle multiple MCP servers, but there's no way to selectively disable individual MCP servers within an enabled plugin. It's all-or-nothing at the plugin level.
This creates two problems:
1. Massive MCP server duplication across plugins
When multiple knowledge-work plugins are enabled, the same MCP servers load multiple times. For example, with just
engineering,design, anddataenabled:slackatlassiannotiongmailgoogle-calendarasanalinearThe
slackMCP server alone is declared in 12+ knowledge-work plugins.2. Unnecessary context window consumption
Each MCP server injects tool definitions into the deferred tools list, consuming context space on every turn — even if the user never calls those tools. Users who want a plugin's skills/agents but not all of its MCP servers have no way to reduce this overhead.
3. Disabling MCP servers doesn't persist
Users report disabling MCP servers during a session, only to have them reactivate on the next session because the plugin re-injects them from its
.mcp.jsonmanifest.Proposed Solution
Add per-MCP-server toggles within plugins. For example, in
settings.json:{ "enabledPlugins": { "engineering@knowledge-work-plugins": { "enabled": true, "disabledMcpServers": ["pagerduty", "datadog", "slack"] } } }Or alternatively, a global MCP server blocklist:
{ "disabledMcpServers": ["pagerduty", "datadog", "intercom", "hex"] }Additional considerations
slack), only one instance should load. Currently each plugin loads its own copy.PreToolUsehook can block MCP tool execution, but the tool definitions still load into context, so the context overhead remains.Environment
🤖 Generated with Claude Code