enhancement: Add mode-specific MCP server profiles

[taltas]

Implement mode-specific MCP server profiles enabling users to assign different MCP servers to different modes through a multiselect UI in the Modes tab. Added modeToProfile mapping to MCP configuration with server filtering based on active mode. Includes backend filtering logic in McpHub, UI components in ModesView, message handlers for state management, comprehensive tests (41 new tests), and documentation. Backward compatible - modes without profiles use all servers.

Related GitHub Issue

Closes: #9014

Description

Implemented mode-specific MCP server profiles through a modeToProfile mapping in MCP configuration. Key implementation details:

• Backend: Extended McpHub with setActiveMode(), getModeToProfileMapping(), and updateModeToProfileMapping() methods. The getServers() method now filters servers based on the active mode's profile. Config loading merges global and project mappings (project takes precedence).
• UI: Added multiselect chip-based interface in ModesView for assigning servers to modes. Shows "All servers available" when no servers selected (backward compatible behavior).
• State Management: Added message handlers in webviewMessageHandler and integrated mode switching with MCP filtering in ClineProvider.
• Validation: Server names in mapping are validated against available servers with warnings logged for invalid references.

Reviewers: Pay attention to the server filtering logic in McpHub.getServers() and ensure the backward compatibility path (modes without profiles use all servers) works correctly.

Test Procedure

Automated Testing:

1. Run backend tests: cd src && npx vitest run services/mcp/__tests__/McpHub.spec.ts (24 new tests)
2. Run UI tests: cd webview-ui && npx vitest run src/components/modes/__tests__/ModesView.spec.tsx (18 new tests)
3. Verify TypeScript compilation: cd src && npx tsc --noEmit and cd webview-ui && npx tsc --noEmit

Manual Testing:

1. Open Roo-Code settings and navigate to the Modes tab
2. Select a mode and scroll to the "MCP Servers" section
3. Click on server chips to toggle selection (selected = blue background, unselected = border only)
4. Switch between modes and verify each mode remembers its server selection
5. Leave a mode with no servers selected and verify it shows "All servers available"
6. Start a task with a mode that has specific servers assigned and verify only those servers are available in the MCP tools list
7. Check config files (~/.roo-code/settings/mcp_settings.json or .roo/mcp.json) to verify modeToProfile mapping is persisted

Backward Compatibility:

• Existing configurations without modeToProfile should work unchanged (all servers available to all modes)
• All 41 new tests pass alongside existing tests

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

This is the UI, a multi-select searchable dropdown would be more favourable, but this is fine for a first iteration to be released.

Video demo-ing the feature, showing that it can have different mcps available in different modes.
https://github.com/user-attachments/assets/5137cbca-207c-489c-9b7e-919829949491

Documentation Updates

Does this PR necessitate updates to user-facing documentation?

• No documentation updates are required.
• Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).

Docs will need to updated for the custom modes here.

Get in Touch

---

Important

Introduces mode-specific MCP server profiles with UI and backend support for assigning servers to modes, ensuring backward compatibility and comprehensive testing.

• Behavior:
  • Adds modeToProfile mapping in McpHub to assign MCP servers to modes.
  • getServers() in McpHub filters servers based on active mode.
  • UI in ModesView.tsx for server selection per mode.
  • Backward compatible: modes without profiles use all servers.
• Backend:
  • McpHub methods setActiveMode(), getModeToProfileMapping(), updateModeToProfileMapping() handle mode-specific server logic.
  • Validates server names in mapping against available servers.
• UI:
  • ModesView.tsx includes multiselect UI for server assignment.
  • Handles mode switching and updates server selection accordingly.
• Testing:
  • 41 new tests added across backend and UI to ensure functionality.
• Misc:
  • Updates to ExtensionMessage.ts and WebviewMessage.ts to support new message types for mode-to-profile mapping.

^{This description was created by for 7f7bf4d. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Rooviewer   See task on Roo Cloud

Reviewed the latest changes (1e18199). This commit restores three test describe blocks that were accidentally removed. No new issues found.

• Missing setActiveMode() call in createTaskWithHistoryItem() - Fixed by adding setActiveMode() call in performPreparationTasks() which is now called for all task creation paths

Previous reviews

• cd06eaf: Review #1
• 5251803: Review #2
• 7f7bf4d: Review #3

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[roomote]

This correctly sets the active mode when the user explicitly switches modes, but the same call is missing in createTaskWithHistoryItem(). When a task is resumed from history, the mode is restored via updateGlobalState("mode", historyItem.mode) around line 880, but mcpHub.setActiveMode() is never called. This means MCP server filtering won't work for resumed tasks because activeMode remains undefined in McpHub. Consider adding similar logic after the mode restoration in createTaskWithHistoryItem().

_{Fix it with Roo Code or mention @roomote and request a fix.}