Disabled MCP servers still start processes and show incorrect status indicators

[hannesrudolph]

Disabled MCP servers still start processes and show incorrect status indicators

App Version

Latest (based on current codebase analysis)

API Provider

Not Applicable / Other

Model Used

N/A

🔁 Steps to Reproduce

1. Open VSCode with Roo Code extension
2. Navigate to .roo/mcp.json configuration file
3. Add multiple MCP servers with some having "disabled": true
4. Observe that:
   • Disabled servers still attempt to start processes
   • UI shows incorrect status indicators (may show as connected/error instead of disabled)
   • The entire configuration (including disabled servers) is passed to the modelcontextprotocol library
5. Additionally, when toggling a server's disabled state:
   • Duplicate server instances are created (especially noticeable with Docker-based servers)
   • The old connection is not properly cleaned up

💥 Outcome Summary

Current Behavior:

• The complete mcp.json configuration file, including disabled servers, is sent to the modelcontextprotocol library when initializing MCP connections
• Disabled servers may show misleading visual states (connected/error) instead of a clear disabled indicator
• UI does not properly differentiate between disabled servers and servers with connection errors
• NEW: Toggling a server's disabled state creates duplicate connections instead of properly disconnecting/reconnecting

Expected Behavior:

• Only enabled servers should be included in the configuration passed to the modelcontextprotocol library
• Disabled servers should have distinct visual representation (grey/muted status indicator)
• UI should not show error messages or retry buttons for disabled servers
• The full configuration (with disabled servers) should be maintained in the user-editable mcp.json file
• NEW: Toggling disabled state should cleanly disconnect/reconnect servers without creating duplicates

📄 Relevant Logs or Errors

No specific error messages - this is a configuration management and UI feedback issue.

---

🛠️ Contributing & Technical Analysis

✅ I'm interested in providing technical analysis
✅ I understand this needs approval before implementation begins

Root Cause / Implementation Target

The issue has three main components:

1. Backend - Initial Load: The current implementation reads the entire mcp.json configuration and passes it to the modelcontextprotocol library without filtering out disabled servers
2. Backend - State Toggle: When toggling disabled state, the file watcher triggers updateServerConnections() which reconnects servers without checking if they should be disabled, creating duplicates
3. Frontend: The UI does not properly handle the visual state of disabled servers, potentially showing them as connected or in error state

Affected Components

• Backend Files:

  • src/services/mcp/McpHub.ts: Configuration reading and server initialization
  • Configuration handling in initializeMcpServers(), updateServerConnections(), and handleConfigFileChange()
  • NEW: toggleServerDisabled() method and its interaction with file watchers

• Frontend Files:

  • webview-ui/src/components/mcp/McpView.tsx: Visual status display and UI state management
  • Specifically the getStatusColor() function and conditional rendering logic

Current Implementation Analysis

Backend:

1. The getServers() method (line 408) correctly filters out disabled servers for the UI
2. The connectToServer() method (line 555) does NOT check for disabled state before connecting
3. CRITICAL: updateServerConnections() (line 938) validates configurations including the disabled property but never checks it before calling connectToServer() at:
   • Line 979: For new servers
   • Line 988: For existing servers with changed configs
4. NEW: When toggleServerDisabled() updates the config file, it triggers a file watcher that calls updateServerConnections(), which sees the config change and attempts to reconnect without checking disabled state

Frontend:

1. Status color logic doesn't account for disabled state
2. Error messages and retry buttons are shown for all non-connected servers, including disabled ones
3. No visual distinction between a disabled server and a server with connection issues

Proposed Implementation

Backend - Fix the Core Issue

The primary fix is simple but critical - add disabled state checks in updateServerConnections():

// Line 979 - New server case
if (!currentConnection) {
    try {
        this.setupFileWatcher(name, validatedConfig, source)
        if (!validatedConfig.disabled) {  // ADD THIS CHECK
            await this.connectToServer(name, validatedConfig, source)
        }
    } catch (error) {
        this.showErrorMessage(`Failed to connect to new MCP server ${name}`, error)
    }
}

// Line 988 - Existing server with changed config
else if (!deepEqual(JSON.parse(currentConnection.server.config), config)) {
    try {
        this.setupFileWatcher(name, validatedConfig, source)
        await this.deleteConnection(name, source)
        if (!validatedConfig.disabled) {  // ADD THIS CHECK
            await this.connectToServer(name, validatedConfig, source)
        }
    } catch (error) {
        this.showErrorMessage(`Failed to reconnect MCP server ${name}`, error)
    }
}

This single fix addresses both issues:

• Prevents disabled servers from being loaded on startup
• Prevents duplicate connections when toggling disabled state

Frontend - Visual State Management

1. Status Color System:

   • Add disabled state check in getStatusColor() to return grey color (var(--vscode-descriptionForeground))
   • Ensure disabled servers always show grey regardless of underlying connection state

2. Conditional UI Rendering:

   • Connected & Enabled: Full UI with tabs (Tools, Resources, Instructions, Errors) and network timeout configuration
   • Disconnected & Enabled: Error display with retry button
   • Disabled: Minimal UI with grey status, no error messages or retry buttons

3. Visual Components to Update:

   • Status indicators using VSCode theme variables:
     • Connected: var(--vscode-testing-iconPassed) (green)
     • Error: var(--vscode-testing-iconFailed) (red)
     • Disabled: var(--vscode-descriptionForeground) (grey)
   • Error display styling with proper word wrapping
   • Retry button with proper disabled states

UI/UX Considerations

• Theme Integration: All colors use VSCode theme variables for consistency
• Accessibility: Clear visual distinction between states using color coding
• User Feedback: Disabled servers should be immediately recognizable without confusion with error states

Acceptance Criteria

Given I have MCP servers configured with some disabled
When the configuration is loaded
Then only enabled servers should be passed to the modelcontextprotocol library
And disabled servers should show grey status indicators
But the mcp.json file should maintain all servers for user management

Given I have a disabled MCP server
When I view it in the UI
Then it should show a grey status indicator
And no error messages or retry buttons should be displayed
And the server should not attempt to start any processes

Given I toggle a server's disabled state
When the configuration is reloaded
Then the filtered configuration should reflect the change
And the UI should update to show the appropriate visual state
And only currently enabled servers should be sent to the MCP library
And no duplicate server instances should be created

Given I disable an active MCP server
When the file watcher triggers the configuration update
Then the existing connection should be properly closed
And no new connection should be created
And the UI should reflect the disabled state

---

Note: This issue addresses both the backend configuration filtering to prevent disabled servers from being processed, the prevention of duplicate connections when toggling state, and the frontend visual feedback to ensure users have clear indication of server states. The fix ensures disabled servers don't consume resources and don't confuse users with misleading status indicators or create duplicate processes.