Claude Code Plugin Ecosystem: MCP Integration Issues and Recommendations

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code Plugin Ecosystem: MCP Integration Issues and Recommendations

The Claude Code plugin marketplace is a powerful feature, but current MCP (Model Context Protocol) integration has architectural limitations that create friction for users managing both user-scope and plugin-scope MCPs. This feedback outlines specific issues encountered, their impact, and potential solutions.

Problem Statement

1. MCP Duplication and Namespace Collisions

Current Behavior:

• When a user has a user-scope MCP configured (e.g., "Atlassian")
• And installs a plugin that includes the same MCP via .mcp.json
• Both MCPs run simultaneously with different identifiers:
• User-scope: Atlassian
• Plugin-scope: plugin:{pluginname}:atlassian

Issue:
Claude Code becomes confused about which MCP instance to route commands to, leading to:

• Unpredictable behavior
• Failed commands due to incorrect routing
• Resource waste (multiple instances of the same MCP)
• User confusion about which MCP is active

Real-World Impact:
Users must manually disable one MCP to avoid conflicts, which:

• Defeats the "install and go" plugin experience
• Requires understanding of internal MCP architecture
• Creates maintenance overhead when enabling/disabling plugins

2. User-Specific Configuration in Shareable Plugins

Current Limitation:
Many MCPs require user-specific configuration:

• API keys and authentication tokens
• Environment variables
• User-specific endpoints or account identifiers

Issue:
There's no clear pattern for how plugins should handle MCPs that need user credentials:

• Embedding credentials in plugins is a security risk
• Plugins can't be truly "shareable" if they require manual configuration
• No standardized way to prompt users for required credentials
• No secure credential storage system integrated with plugin MCPs

Example Scenarios:

• GitHub MCP needs personal access token
• Atlassian MCP needs organization URL and API token
• AWS MCP needs credentials and region configuration

3. MCP Dependency Management

Current Gap:
No dependency resolution system exists for MCPs across plugins:

• Multiple plugins may require the same MCP
• Each plugin potentially spins up its own instance
• No sharing or deduplication of MCP instances
• No way to declare "I need MCP X with capability Y"

Consequence:

• Inefficient resource usage (multiple identical MCP processes)
• Potential port conflicts
• Inconsistent state if different instances cache different data
• Complex troubleshooting when issues arise

Impact Assessment

User Experience

• Friction in adoption: Users hesitant to install plugins that might conflict
• Manual workarounds required: Constant enabling/disabling of MCPs
• Broken workflows: Commands fail unexpectedly due to routing confusion
• Configuration complexity: Users need deep system knowledge to manage conflicts

Plugin Ecosystem Health

• Limits plugin utility: Plugins can't reliably use common MCPs
• Discourages plugin development: Developers unsure how to handle shared MCPs
• Fragmentation: Each plugin may implement different workarounds
• Adoption barrier: Enterprise users concerned about auth token management

Proposed Solution

Recommended Solutions

Short-Term (Quick Wins)

1. MCP Priority/Resolution System

• Implement clear precedence: user-scope > plugin-scope
• When conflict detected, automatically prefer user-configured MCP
• Log which MCP is being used for transparency

1. Conflict Detection and Warnings

• On plugin install, detect if MCP already exists
• Prompt user: "Use existing Atlassian MCP or plugin's version?"
• Provide clear guidance on implications of each choice

1. Documentation and Best Practices

• Document expected behavior when MCPs overlap
• Provide plugin development guidelines for MCP usage
• User documentation on managing MCP conflicts

Medium-Term (Architectural Improvements)

1. MCP Dependency Declaration

``json
{
"mcp_dependencies": {
"atlassian": {
"version": ">=1.0.0",
"prefer_existing": true,
"required_capabilities": ["issue_management", "confluence"]
}
}
}
``

• Plugins declare MCP needs rather than bundling
• System resolves dependencies intelligently
• Reuses existing MCPs when compatible

1. Credential Management System

• Secure keystore for user credentials
• Plugins request access to specific credential types
• User grants permissions once, works across plugins
• Credentials never stored in plugin code

1. MCP Instance Sharing

• Single instance of each MCP runs when possible
• Multiple consumers can share one MCP process
• Proper scoping for multi-tenant scenarios

Long-Term (Ecosystem Maturity)

1. MCP Registry and Versioning

• Central registry of available MCPs
• Semantic versioning for compatibility
• Dependency resolution like npm/pip/cargo
• Automatic updates and security patches

1. Plugin Manifest Enhancement

``json
{
"requires": {
"mcps": {
"atlassian": {
"min_version": "1.2.0",
"env_vars": ["ATLASSIAN_URL", "ATLASSIAN_TOKEN"],
"optional": false
}
}
},
"configuration_prompts": [
{
"key": "ATLASSIAN_TOKEN",
"type": "secret",
"description": "Atlassian API token",
"validation": "^[A-Za-z0-9]+$"
}
]
}
``

1. Smart MCP Routing

• Context-aware routing based on command intent
• User preferences for MCP selection
• Fallback mechanisms if primary MCP unavailable

Comparison to Existing Solutions

Other ecosystems have solved similar problems:

• npm/yarn: Package deduplication, peer dependencies
• Docker Compose: Service dependency and reuse
• VS Code Extensions: Extension dependencies and activation
• Kubernetes: ConfigMaps and Secrets for configuration

Claude Code can learn from these patterns while adapting to MCP-specific needs.

Proposed Priority

1. P0 (Critical): Conflict detection and user warnings
2. P1 (High): Dependency declaration and existing MCP reuse
3. P1 (High): Secure credential management for plugin MCPs
4. P2 (Medium): MCP instance sharing and deduplication
5. P3 (Nice-to-have): Full registry and versioning system

Test Scenarios to Validate Solutions

1. User has Atlassian MCP configured → installs plugin needing Atlassian → system reuses existing
2. Plugin needs GitHub MCP with token → first run prompts for credential → stores securely → subsequent runs work automatically
3. Three plugins need same MCP → only one instance runs
4. User upgrades MCP version → plugins continue working or warn about incompatibility
5. User disables plugin → plugin's exclusive MCPs are cleaned up

Conclusion

The Claude Code plugin ecosystem has enormous potential, but MCP integration needs architectural refinement to reach maturity. The issues outlined are solvable with well-established patterns from other package management systems, adapted for the unique context of MCPs and AI tooling.

This feedback is based on real-world usage and the specific pain points encountered. Addressing these concerns will significantly improve the developer and user experience, enabling the plugin ecosystem to flourish.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

_No response_

Additional Context

_No response_